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.teres...@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.teres...@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.teres...@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
