cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud Gaillard <arnaud.gaill...@xtendsys.net>
Subject Re: Cloudstack mixing Vlan and creating a big mess...
Date Tue, 23 Oct 2012 19:22:10 GMT
Hi Alex,

We are running 3.0.2.

We  found a way to fix this by correcting the nics table, however we still
don't understand how some VM can get their network mixed at the creation
time. This bug seems to have affected only a limited subset of the VM we
had created with these guest networks.

Our setup is the following:

eth1/2->bond0->bond0.120->CloudVirBr120 -> Management Network + Guest
Network (same management network for VM in vlan120, so we created a guest
network on vlan120)
eth3/4->bond1->bond1.400->CloudVirBr400 -> Storage Network + Guest Network
(same storage network for guest VM same as above)
eth5>/6->bond2->CloudVirPriv1 -> Pub Network (unused) + Guest Network (here
we create different guest VLAN for segmentation). (There is also another
bug as we cannot create isolated network guest on this network, only shared
network offering are available)
eth7/8-> bond3->CloudVirPriv2 -> Guest (used for specific network routing
at the guest VM level)

The problem is that the Blade center virtual flex we use doesn't like at
all to have traffic from other VLAN on interface where it is not suppose to
appear. The BC switch starts to disable the network on the blade which
combined with the cloudstack HA feature can bring down a cluster very
quickly.

We are going to look into more detail when we will get some time.

Cheers,

AG

On Tue, Oct 23, 2012 at 7:58 PM, Alex Huang <Alex.Huang@citrix.com> wrote:

> Arnaud,
>
> Can you provide more information?
>
> What are the networks and the network  configurations you are deploying
> the VM into?  How did you setup your zone?  Is this 3.x, 4.x, 2.x?
>
> --Alex
>
> > -----Original Message-----
> > From: Arnaud Gaillard [mailto:arnaud.gaillard@xtendsys.net]
> > Sent: Tuesday, October 23, 2012 2:18 AM
> > To: cloudstack-users@incubator.apache.org
> > Subject: Cloudstack mixing Vlan and creating a big mess...
> >
> > Hello,
> >
> > We are currently facing a critical issue.
> >
> > Cloudstack is currently mixing vlan for VM migration or creation bringing
> > down part of our network.
> >
> > We are currently using multiple guest network with different Vlan for
> > segmentation.
> >
> > Here is a quick exemple (extract from the cloud agent log in debug mode):
> >
> >
> "nics":[{"deviceId":0,"networkRateMbps":10000,"defaultNic":true,"ip":"10.1
> >
> 28.8.3","netmask":"255.255.240.0","gateway":"10.128.15.254","mac":"06:7d:4
> >
> 6:00:16:50","dns1":"172.16.11.10","broadcastType":"Vlan","type":"Guest","b
> >
> roadcastUri":"vlan://120","isolationUri":"vlan://811","isSecurityGroupEnable
> > d":false,"name":"cloudVirBrPriv1"}
> >
> {"deviceId":1,"networkRateMbps":10000,"defaultNic":false,"ip":"172.20.2.4",
> >
> "netmask":"255.255.240.0","gateway":"172.20.15.254","mac":"06:1a:a2:00:14:
> > 50","dns1":"172.16.11.10","broadcastType":"Vlan","type":"Guest","broadcas
> >
> tUri":"vlan://811","isolationUri":"vlan://120","isSecurityGroupEnabled":false,
> > "name":"cloudVirBr120"},{"deviceId":2,"networkRateMbps":10000,"defaultN
> >
> ic":false,"ip":"10.192.6.3","netmask":"255.255.248.0","gateway":"10.192.7.25
> >
> 4","mac":"06:07:8e:00:11:52","dns1":"172.16.11.10","broadcastType":"Vlan","
> >
> type":"Guest","broadcastUri":"vlan://400","isolationUri":"vlan://400","isSecu
> > rityGroupEnabled":false,"name":"cloudVirBr400"}]},"wait":0}}]
> > }
> >
> >
> > As you can see broadcastUri and isolationUri are not in the same Vlan.
> The
> > Vlan120 is only present on another physical interface (CloudVirBr120),
> and
> > must not be present on this interface. In order for this to work
> broadcast and
> > isolation must both be in the 811 vlan. The same problem arise from
> > deviceid1 where the mix is inverted....
> >
> >
> > From where does cloudstack get the value for Broadcast and Isolation URI?
> > How can such a mix/mess happend?
> >
> > Thanks for your help!
> >
> > Arnaud
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message