incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject RE: issue/bug with multiple guest networks?
Date Thu, 20 Sep 2012 02:09:14 GMT
Thanks, I'll fix this. I am assuming that we leave the current method in
place if nicTO.getName fails or some such? Just thinking about when to
default to the getPifs stuff and when to use the name.
On Sep 19, 2012 7:36 PM, "Edison Su" <Edison.su@citrix.com> wrote:

> > -----Original Message-----
> > From: Marcus Sorensen [mailto:shadowsor@gmail.com]
> > Sent: Wednesday, September 19, 2012 5:18 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: issue/bug with multiple guest networks?
> >
> > Cloudstack seems to let you create guest traffic types on multiple
> > physical networks. However, when I try this with KVM I end up always
> > bridging to whatever device is used for guest.network.device.
> >
> > It looks like the issue is in
> > plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVif
> > Driver.java,
> > in the plug function.
> >
> > if (nic.getType() == Networks.TrafficType.Guest) {
> >             if (nic.getBroadcastType() ==
> > Networks.BroadcastDomainType.Vlan
> >                     && !vlanId.equalsIgnoreCase("untagged")) {
> >                 String brName = createVlanBr(vlanId,
> > _pifs.get("private"));
> >
> > that is, if nic is a guest traffic type, create its bridge on
> > "private", which is found by searching for guest.network.device. We
> > are passed the physicalnetwork bridge that we should be using (or at
> > least the KVM traffic label that should be used for the nic, which is
>
>
> Yes, should create bridge based on NicTO.getName(), instead of always on
> "private" network.
>
> > the same thing, no?) in StartCommand, so I'm not getting why it's
> > hardcoded to use the guest.network.device.
>
>
> It's a bug.
>
> >
> > I'll look at fixing this, but as usual I'd like any background on this
> > that I can get, so I don't break it for others.
> >
> > Also, should we not change the cloudVirBr prefix to include a physical
> > network identifier? It sort of seems like there's support for adding
> > vlans as well to each guest traffic on each physical network (e.g.
> > vlan 100-200 on physical network 1, vlan 100-200 on physical network
> > 2, etc), but with the existing naming convention the bridge names will
> > collide. Perhaps there's more to it than that, but it seems like
> > changing the naming would be a first step.
>
> Can change the name schema to br-device-name-vlan-number: e.g brEth00001?
>
> >
> > Feedback?
>

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