cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: FW: CS 4.1.0 - this will help a number of people who struggle with Advanced Networking
Date Thu, 01 Aug 2013 17:28:44 GMT
I'm short on time, but here's the KVM advanced networking config we
use for testing. If someone wants to write a doc based around it that
would be nice.

Start out KVM host with two networks, eth0, eth1. eth0 is intended for
public traffic, eth0 will be guest vlans and management vlan. then
create a bridge interface for each:

[root@devcloud-kvm ~]# brctl show
bridge name bridge id STP enabled interfaces
cloud0 8000.000000000000 no
br0 8000.5254004eff4f no eth0
br1 8000.52540052b15e no eth1

br0  Link encap:Ethernet  HWaddr 52:54:00:4E:FF:4F
          inet addr:172.17.10.10  Bcast:172.17.10.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe4e:ff4f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:127 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5846 (5.7 KiB)  TX bytes:4345 (4.2 KiB)

br1  Link encap:Ethernet  HWaddr 52:54:00:52:B1:5E
          inet addr:192.168.100.10  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe52:b15e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:343 errors:0 dropped:0 overruns:0 frame:0
          TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:24227 (23.6 KiB)  TX bytes:29108 (28.4 KiB)

eth0      Link encap:Ethernet  HWaddr 52:54:00:4E:FF:4F
          inet6 addr: fe80::5054:ff:fe4e:ff4f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:157 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12276 (11.9 KiB)  TX bytes:4897 (4.7 KiB)

eth1      Link encap:Ethernet  HWaddr 52:54:00:52:B1:5E
          inet6 addr: fe80::5054:ff:fe52:b15e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:377 errors:0 dropped:0 overruns:0 frame:0
          TX packets:163 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:34044 (33.2 KiB)  TX bytes:29748 (29.0 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:863 errors:0 dropped:0 overruns:0 frame:0
          TX packets:863 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:120247 (117.4 KiB)  TX bytes:120247 (117.4 KiB)

Ok, now kvm host is ready. Just define the kvm traffic label for
Management traffic to be 'br0', for guest to be 'br0', and for public
to be 'br1'. Cloudstack will create any necessary bridges or vlans.
You can leave the vlan option empty if you don't want it to create a
vlan (say for management). I can perhaps go into more detail later.

On Wed, Jul 31, 2013 at 12:33 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
> Yes, that's correct. I think we need to update the documentation. The
> user simply needs to create a bridge where 'public' traffic will work,
> and then set that bridge name as the traffic label for public traffic.
> Then it will create the vlan device and the bridge necessary for
> public based on the physical ethernet device of that bridge.
>
> Note, in this example, it is only looking for cloudVirBr for
> compatibility, if there are existing cloudVirBr bridges then the agent
> will continue to create cloudVirBr bridges, otherwise, it will create
> breth bridges, which allow the same vlan number on different physical
> interfaces.
>
> We can easily create some concrete examples for this... such as the
> one represented in devcloud-kvm by
> tools/devcloud-kvm/devcloud-kvm-advanced.cfg
>
> On Wed, Jul 31, 2013 at 12:06 PM, Edison Su <Edison.su@citrix.com> wrote:
>> The KVM installation guide at http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Installation_Guide/hypervisor-kvm-install-flow.html
, is unnecessary complicated and inaccurate.
>> For example, we don't need to configure vlan on kvm host by users themselves, cloudstack-agent
will create vlans automatically.
>> All users need to do is to create bridges(if the default bridge created by cloudstack-agent
is not enough), then add these bridge names from cloudstack mgt server UI during the zone
creation.
>>
>> -----Original Message-----
>> From: Noel Kendall [mailto:noeldkendall@hotmail.com]
>> Sent: Wednesday, July 31, 2013 9:49 AM
>> To: users@cloudstack.apache.org
>> Subject: CS 4.1.0 - this will help a number of people who struggle with Advanced
Networking
>>
>> The documentation for installation in a KVM environment is utterly misleading.
>> The documentation reads as though one can set up the bridge for the public network
with any name one chooses, the default being cloudbr0.
>> You cannot use just any old name. That simply will not work.
>> Let's suppose I have a public network that I isolate on VLAN 5, which is interfaced
on ethernet adapter eth4. I will need to define an adapter eth4.5 with VLAN set to yes.
>> So far, so good.
>> Next, for the bridge...
>> By enabling debugging output in the log, I was able to see that the code looks for
a bridge with the name cloudVirBr5 for my public network.
>> I had tried several different approaches, none would work if I did not name my bridge
cloudVirBr5, and set my traffic label on the network configurationto the same.
>> I have seen numerous posts in the mailing lists, blog entries, you name it, representing
frustrations of throngs of users trying to validate a CS setup.
>> The documentation is utterly wrong and misleading.
>> Summary:
>> does not work:traffic label: cloudbr0 with eth4.5 pointing to cloudbr0 - code still
tries to create a breth4.5 and enlist eth4.5 to it but cannot because it is already enlisted
to cloudbr0.
>> Good luck everyone with advanced networking with VLAN isolation on CentOS KVM hosts.
>>

Mime
View raw message