cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valery Ciareszka <valery.teres...@gmail.com>
Subject Re: cloudstack 4.1 QinQ vlan behaviour
Date Thu, 11 Jul 2013 10:05:45 GMT
>What is your guest KVM traffic label set to?
It is set to cloudbrguest.

>And tell it to use cloudbrguest-10 as the traffic label, it will go up one
from vlan10 and settle on vlan211 as the physical device.

Yes, that should work(I don't have possibility to test it right now),
thanks for suggestion.

On Wed, Jul 10, 2013 at 5:13 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:

> I created that document, as a suggestion. I never got feedback. The
> way it worked previously was sort of  a happy accident, which was
> 'fixed' when the code changed to accept overlapping vlan numbers on
> multiple physical devices (hence the bridge name change).
>
> However... I believe there is still a way to do what you want with the
> stock code. What is your guest KVM traffic label set to?  Cloudstack
> is looking for the 'parent' physical device of the bridge, so if it
> sees that it's on a vlan, it goes up one more to find the real device.
> It only does this once. So if instead of:
>
> cloudbrguest            8000.90e2ba317614       yes             vlan211
>
> You create:
>
> cloudbrguest-10           8000.90e2ba317614       yes
> vlan211.10
>
> And tell it to use cloudbrguest-10 as the traffic label, it will go up
> one from vlan10 and settle on vlan211 as the physical device. The nice
> thing about the new behavior is that I believe it will work on ANY
> type, not just 'vlan' ones (so you could bond, for instance).
>
> On Wed, Jul 10, 2013 at 2:34 AM, Valery Ciareszka
> <valery.tereshko@gmail.com> wrote:
> > Hi all.
> >
> > I was able to change vlan creation behaviour by source code modification
> >
> (plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java),
> > had to comment several lines of code:
> >
> >  private String getPif(String bridge) {
> >         String pif = matchPifFileInDirectory(bridge);
> > //        File vlanfile = new File("/proc/net/vlan/" + pif);
> >
> > //        if (vlanfile.isFile()) {
> > //                pif = Script.runSimpleBashScript("grep ^Device\\:
> > /proc/net/vlan/"
> > //                                                  + pif + " | awk
> {'print
> > $2'}");
> > //        }
> >
> >         return pif;
> >     }
> >
> > Could someone please comment this new behaviour of vlan creation ? Why
> does
> > it try to create vlan on real physical device, but not on vlan (vlan in
> > vlan) ? There is nothing about this in documentation.
> > I have found Q-in-Q for isolated networks functional spec -
> >
> https://cwiki.apache.org/CLOUDSTACK/q-in-q-for-isolated-networks-functional-spec.html
> > "The admin simply needs to create any 'vlan#' devices, and CloudStack
> uses
> > them as physical devices."
> >
> > That worked for me in CS 4.0.2. But as you can see, current version of
> > cloudstack DOES NOT use 'vlan#' devices as physical devices!!!
> > Is that a bug ?
> >
> >
> >
> > On Tue, Jul 9, 2013 at 12:39 PM, Valery Ciareszka <
> valery.tereshko@gmail.com
> >> wrote:
> >
> >> So, nobody uses q in q and cloudstack 4.1 ?
> >>
> >>
> >> On Mon, Jul 8, 2013 at 3:13 PM, Valery Ciareszka <
> >> valery.tereshko@gmail.com> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I use the following environment: CS 4.1, KVM, Centos 6.4
> >>> (management+node1+node2), OpenIndiana NFS server as primary and
> secondary
> >>> storage
> >>> I have advanced networking in zone. I split management/public/guest
> >>> traffic into different vlans, and use kvm network labels (bridge
> names):
> >>> # cat /etc/cloud/agent/agent.properties |grep device
> >>> guest.network.device=cloudbrguest
> >>> private.network.device=cloudbrmanage
> >>> public.network.device=cloudbrpublic
> >>>
> >>> I have following network configuration:
> >>> eth0+eth1=bond0
> >>> eth2+eth3=bond1
> >>>
> >>> I use  vlan with id=211 on bond1 interface for guest traffic:
> >>> cloudbrguest            8000.90e2ba317614       yes             vlan211
> >>> cloudbrmanage           8000.90e2ba317614       yes
> bond1.210
> >>> cloudbrpublic           8000.90e2ba317614       yes
> bond1.221
> >>> cloudbrstor             8000.0025908814a4       yes             bond0
> >>>
> >>>
> >>> The problem appeared after I have upgraded CS from 4.0.2 to 4.1.
> >>>
> >>> How it works in 4.0.2:
> >>> -bridge interface cloudVirBr#VLANID is created on hypervisor, #VLANID -
> >>> value from 1024 to 4096(is specified when creating zone), i.e.
> >>> cloudVirBr1224
> >>> -vlan interface vlan211.#VLANID is created on hypervisor and is plugged
> >>> into cloudVirBr#VLANID
> >>> I should had permitted 211 vlanid on switchports and all guest traffic
> >>> (vlans 1024-4096) was encapsulated.
> >>>
> >>> How it works in 4.1:
> >>> -bridge interface br#ETHNAME-#VLANID is created on hypervisor, where
> >>> #VLANID - value from 1024 to 4096(is specified when creating zone) and
> >>> #ETHNAME - name of device on top of which vlan will be created
> >>> i.e. brbond1-1224
> >>> -vlan interface bond1.#VLANID is created on hypervisor and is plugged
> >>> into br#ETHNAME-#VLANID
> >>> However, vlan interface is created on top of bond1 interface, while I
> >>> would like it to be created on top of vlan211 (bond1.211)
> >>> Now I should permit 1024-4096 vlanid on switchports, that is not
> >>> convenient.
> >>>
> >>> How do I configure CS 4.1 so that it could work with guest vlans the
> same
> >>> way as it had worked in CS 4.0 ?
> >>>
> >>> --
> >>> Regards,
> >>> Valery
> >>>
> >>> http://protocol.by/slayer
> >>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Valery
> >>
> >> http://protocol.by/slayer
> >>
> >
> >
> >
> > --
> > Regards,
> > Valery
> >
> > http://protocol.by/slayer
>



-- 
Regards,
Valery

http://protocol.by/slayer

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