cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "danny webb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-2008) guest network vlan tag chain issue
Date Thu, 11 Apr 2013 15:55:17 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629041#comment-13629041
] 

danny webb commented on CLOUDSTACK-2008:
----------------------------------------

[root@slo-cnkvm005 network-scripts]# cat /etc/cloud/agent/agent.properties 
#Storage
#Thu Apr 11 15:02:23 BST 2013
guest.network.device=cloudbr0
workers=5
private.network.device=cloudbr0
port=8250
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
pod=3
zone=4
guid=81b405d4-1c9b-3b93-b41b-5331afff6305
public.network.device=cloudbr0
cluster=5
local.storage.uuid=488ba4b4-961f-42ac-a8c8-a1a3fcc2ac7b
domr.scripts.dir=scripts/network/domr/kvm
LibvirtComputingResource.id=16
host=172.18.102.5

[root@slo-cnkvm005 network-scripts]# cat /proc/net/vlan/bond0.60
bond0.60  VID: 60	 REORDER_HDR: 1  dev->priv_flags: 2001
         total frames received      1910633
          total bytes received   2601941203
      Broadcast/Multicast Rcvd        10555

      total frames transmitted      1006816
       total bytes transmitted     75539004
            total headroom inc            0
           total encap on xmit            0
Device: bond0
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings: 

there is nothing really of interest in the agent.log......just the normal startup messages:

2013-04-11 15:02:22,215 INFO  [cloud.agent.AgentShell] (main:null) Implementation Version
is 4.0.1.20130201075054
2013-04-11 15:02:22,215 INFO  [cloud.agent.AgentShell] (main:null) agent.properties found
at /etc/cloud/agent/agent.properties
2013-04-11 15:02:22,216 INFO  [cloud.agent.AgentShell] (main:null) Defaulting to using properties
file for storage
2013-04-11 15:02:22,218 INFO  [cloud.agent.AgentShell] (main:null) Defaulting to the constant
time backoff algorithm
2013-04-11 15:02:22,293 INFO  [cloud.agent.Agent] (main:null) id is 
2013-04-11 15:02:22,431 INFO  [resource.virtualnetwork.VirtualRoutingResource] (main:null)
VirtualRoutingResource _scriptDir to use: scripts/network/domr/kvm
2013-04-11 15:02:22,749 INFO  [kvm.resource.LibvirtComputingResource] (main:null) No libvirt.vif.driver
specififed. Defaults to BridgeVifDriver.
2013-04-11 15:02:22,759 INFO  [cloud.agent.Agent] (main:null) Agent [id = new : type = LibvirtComputingResource
: zone = 4 : pod = 3 : workers = 5 : host = 172.18.102.5 : port = 8250
2013-04-11 15:02:22,769 INFO  [utils.nio.NioClient] (Agent-Selector:null) Connecting to 172.18.102.5:8250
2013-04-11 15:02:23,248 INFO  [utils.nio.NioClient] (Agent-Selector:null) SSL: Handshake done
2013-04-11 15:02:23,530 INFO  [cloud.serializer.GsonHelper] (Agent-Handler-1:null) Default
Builder inited.
2013-04-11 15:02:23,611 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) Proccess agent startup
answer, agent id = 16
2013-04-11 15:02:23,611 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) Set agent id 16
2013-04-11 15:02:23,618 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) Startup Response
Received: agent id = 16

                
> guest network vlan tag chain issue
> ----------------------------------
>
>                 Key: CLOUDSTACK-2008
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2008
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller
>    Affects Versions: 4.0.1
>         Environment: centos 6.4
> HP BL460 G1 
>            Reporter: danny webb
>            Priority: Minor
>
> Hi,
> I have setup a cloudstack instance where my "root" eth device is a vlan tagged bond0.60
(as the network I am on has a different default VLAN id than my test vlans).  
> so I am setup like this:
>     bond0.60 / cloudbr0 == management network / ip of box (bond0 == nothing)
>      
>     bond0.60  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>               RX packets:37189 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:34030 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:4476334 (4.2 MiB)  TX bytes:31055747 (29.6 MiB)
>     cloudbr0  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet addr:172.18.102.8  Bcast:172.18.102.255  Mask:255.255.255.0
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>               RX packets:36531 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:32606 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:4435824 (4.2 MiB)  TX bytes:30976056 (29.5 MiB)
>      
> when it went to setup a new guest network (with a vlan id of 80) it created it ontop
of the bond0.60 like:
>      
>     bond0.60.80 Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C  
>               inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
>               UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
>               RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>               TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
>               collisions:0 txqueuelen:0
>               RX bytes:0 (0.0 b)  TX bytes:13777 (13.4 KiB)
>      
>     [root@slo-cnkvm004 ~]# brctl show
>     bridge name     bridge id               STP enabled     interfaces
>     cloud0          8000.000000000000       no             
>     cloudVirBr80            8000.0017a477483c       no              bond0.60.80
>      
> which doesn't seem to work and I am pretty sure is syntactically wrong.  I can't ping
any guests that come up on that network.  When creating new devices it should I believe be
creating them off of the base eth device (ie eth0, or bond0).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message