You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Valery Ciareszka <va...@gmail.com> on 2013/07/08 14:13:10 UTC
cloudstack 4.1 QinQ vlan behaviour
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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
>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 <sh...@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
> <va...@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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
>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 <sh...@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
> <va...@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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<va...@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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Marcus Sorensen <sh...@gmail.com>.
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
<va...@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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
So, nobody uses q in q and cloudstack 4.1 ?
On Mon, Jul 8, 2013 at 3:13 PM, Valery Ciareszka
<va...@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
Re: cloudstack 4.1 QinQ vlan behaviour
Posted by Valery Ciareszka <va...@gmail.com>.
So, nobody uses q in q and cloudstack 4.1 ?
On Mon, Jul 8, 2013 at 3:13 PM, Valery Ciareszka
<va...@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