Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Date: Fri, 29 Jan 2016 16:11:59 +0000 (GMT)
From: Nux! <nux@li.nux.ro>
To: users@cloudstack.apache.org
Message-ID: <750374758.33121.1454083919161.JavaMail.zimbra@li.nux.ro>
In-Reply-To: 
 <CAArKcSrnst0x3S=tXAbs0AO5NgammN53oPOeB_SggAwT8By7Sw@mail.gmail.com>
References: 
 <CAArKcSpP6ueyv1qi5HKo9rO039dhr6gp21oYR6C0add8RUwR0w@mail.gmail.com>
 <2138930282.32161.1454030729749.JavaMail.zimbra@li.nux.ro>
 <CAArKcSo7EAAws2Ywj0=Ns2zj9_gVmFNqqgT1dcXormcBZ3dj9g@mail.gmail.com>
 <CAArKcSrnst0x3S=tXAbs0AO5NgammN53oPOeB_SggAwT8By7Sw@mail.gmail.com>
Subject: Re: cloudstack-agent 4.5 problem with cloudbr bridges
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: cloudstack-agent 4.5 problem with cloudbr bridges
Thread-Index: pLNYEVQK6VPw6WygMQvxkVkPKOG5Cw==

No problem. Which solution did you go for?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Sebastian Gomez" <tiochan@gmail.com>
> To: users@cloudstack.apache.org
> Sent: Friday, 29 January, 2016 10:43:07
> Subject: Re: cloudstack-agent 4.5 problem with cloudbr bridges

> It worked for me!
>=20
> Oh my God, I spent lot of time trying to solve it.. Thank a lot!
>=20
>=20
>=20
>=20
>=20
> El vie., 29 ene. 2016 a las 9:44, Sebastian Gomez (<tiochan@gmail.com>)
> escribi=C3=B3:
>=20
>> Thank you Lucian, I will try it and let you know if worked for me.
>>
>>
>>
>> El vie., 29 ene. 2016 a las 2:25, Nux! (<nux@li.nux.ro>) escribi=C3=B3:
>>
>>> Hello Sebastian,
>>>
>>> Cloudstack creates a new bridge because it's standard behaviour if you
>>> mention a VLAN number when you add the public network details.
>>>
>>> I believe you can just skip mentioning the VLAN id when you add the
>>> public network, in which case it will just use the bridge you created
>>> manually (cloudbr1) - I have never done this but there's a good chance =
it
>>> will work.
>>>
>>> What I would do in your shoes is just add bond0 (ie no VLAN) to cloudbr=
1
>>> and let Cloudstack build the interfaces automatically as required (bond=
0.83
>>> and the respective bridge). This would be closer to recommended practic=
e.
>>>
>>>
>>> HTH
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> ----- Original Message -----
>>> > From: "Sebastian Gomez" <tiochan@gmail.com>
>>> > To: users@cloudstack.apache.org
>>> > Sent: Thursday, 28 January, 2016 12:51:08
>>> > Subject: cloudstack-agent 4.5 problem with cloudbr bridges
>>>
>>> > Hi all,
>>> >
>>> > I have been working with cloudstack and vmware for more than 3 years,
>>> and
>>> > now I would like to test it with KVM, but I have problems with the
>>> bridges
>>> > names.
>>> >
>>> > Summarizing, when I add the KVM host on cloudstack, the cloudstack ag=
ent
>>> > creates a new bridge a part of the cloudbr0 and cloudbr1 and gets an
>>> error
>>> > trying to add the interface associated with the public network VLAN.
>>> >
>>> > Extended:
>>> >
>>> > I followed many how-tos, each different, and none of them took me to
>>> solve
>>> > the problem.
>>> >
>>> > I want to configure the KVM and I have these networks:
>>> >
>>> > 172.16.1.0/24 for management traffic, VLAN 554
>>> > 10.4.0.0/24 for public traffic, VLAN 83
>>> > 10.254.0.0/24 for Guest NW, VLANs [555 - 569]
>>> >
>>> > Storage NFS is defined under management NW (172.16.1.0/24).
>>> >
>>> > The KVM host have 2 physical interfaces, configured as a bonding -rr
>>> (the
>>> > switch is configured to allow bonding). This is the interface bond0.
>>> >
>>> > Over it I created:
>>> > - bond0.554 is a virtual interface, configured with the management VL=
AN
>>> > (554)
>>> > - bond0.83 is a virtual interface, configured with the public VLAN (8=
3)
>>> >
>>> > And over them, 2 bridges as Cloudstack docs says:
>>> > - cloudbr0 is going to host management traffic and
>>> > - cloudbr1 is going to host public and guest traffic.
>>> >
>>> > Results in:
>>> > [root@gary1 network-scripts]# brctl show
>>> > bridge name     bridge id               STP enabled     interfaces
>>> > br0             8000.180373f5a953       no              bond0.197
>>> > cloudbr0                8000.180373f5a953       no
>>> bond0.554
>>> > cloudbr1                8000.180373f5a953       no              bond0=
.83
>>> >
>>> > The routes are:
>>> > [root@gary1 network-scripts]# route -n
>>> > Kernel IP routing table
>>> > Destination     Gateway         Genmask         Flags Metric Ref    U=
se
>>> > Iface
>>> > 147.83.197.0    0.0.0.0         255.255.255.0   U     0      0       =
 0
>>> br0
>>> > 10.4.82.0       0.0.0.0         255.255.255.0   U     0      0       =
 0
>>> > cloudbr1
>>> > 172.16.1.0      0.0.0.0         255.255.255.0   U     0      0       =
 0
>>> > cloudbr0
>>> > 192.168.122.0   0.0.0.0         255.255.255.0   U     0      0       =
 0
>>> > virbr0
>>> > 0.0.0.0         147.83.197.1    0.0.0.0         UG    0      0       =
 0
>>> br0
>>> >
>>> > And I can ping other elements into each network.
>>> >
>>> > Now, with the agent fresh installed (free of configurations), I add t=
he
>>> > host on cloudstack (4.5.2), and the process stop with an error inform=
ing
>>> > that the iface "bond0.83" can't be attached to a new bridge that it
>>> created
>>> > "brbond0-83".
>>> >
>>> > I can see on the host that there is a new bridge called "brbond0-83",
>>> > associated with NO interfaces:
>>> >
>>> > [root@gary1 network-scripts]# brctl show
>>> > bridge name     bridge id               STP enabled     interfaces
>>> > br0             8000.180373f5a953       no              bond0.197
>>> > brbond0-83              8000.000000000000       no
>>> > cloud0          8000.fe00a9fe00b5       no
>>> > cloudbr0                8000.180373f5a953       no
>>> bond0.554
>>> > cloudbr1                8000.180373f5a953       no              bond0=
.83
>>> > virbr0          8000.525400244916       yes             virbr0-nic
>>> >
>>> > Now, I manually detach bond0.83 from cloudbr1 and attach it to the ne=
w
>>> > created bridge (brbond0-83), and the process continues.
>>> >
>>> > The problem is that if I restart the server, the agent cannot re-atta=
ch
>>> the
>>> > iface again, I have to do it by hand (not good). Also, if I configure
>>> the
>>> > system not to attach bond0.83 to the bridge, it generates an error ab=
out
>>> > that the network is not found...
>>> >
>>> > On the cloudstack management service, I defined two physical networks=
:
>>> >
>>> > Physical network                Traffic types       KVM Traffic label
>>> > cloudbr0-CS-MGMT            Management      cloudbr0
>>> > cloudbr1-CS-PUB-GUEST   Public, Guest     cloudbr1
>>> >
>>> >
>>> >
>>> >
>>> > My question is:
>>> >
>>> > Why cloudstack creates a new bridge?
>>> >
>>> >
>>> >
>>> > Thanks in advanced.
>>>