You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Sebastian Gomez <ti...@gmail.com> on 2016/01/28 13:51:08 UTC

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 agent
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 VLAN
(554)
- bond0.83 is a virtual interface, configured with the public VLAN (83)

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    Use
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 the
host on cloudstack (4.5.2), and the process stop with an error informing
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 new
created bridge (brbond0-83), and the process continues.

The problem is that if I restart the server, the agent cannot re-attach 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 about
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.

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Nux! <nu...@li.nux.ro>.
Good, we needn't all make the same mistakes. :-D

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Sebastian Gomez" <ti...@gmail.com>
> To: users@cloudstack.apache.org
> Sent: Saturday, 30 January, 2016 23:30:43
> Subject: Re: cloudstack-agent 4.5 problem with cloudbr bridges

> On the KVM host, I left the network configuration as was, on cloudbr1, with
> the bond0.83 attached on it.
> 
> On cloudstack:
> - I removed the host.
> - I changed the public network configuration on cloudstack, deleting the
> current and re-creating it without setting the VLAN.
> 
> On the host:
> - I uninstalled the agent and removed the cloudstack configuration,
> - installed the cloudstack-agent again
> 
> On cloudstack:
> - I added the host and... I was added without problems.
> 
> The host maintained clean the network configuration.
> All ran perfectly.
> 
> Honestly, your clue about not setting the VLAN on cloudstack public network
> saved me many hours and some headaches.
> 
> 
> 
> 
> 
> 
> El vie., 29 ene. 2016 a las 17:12, Nux! (<nu...@li.nux.ro>) escribió:
> 
>> 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" <ti...@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!
>> >
>> > Oh my God, I spent lot of time trying to solve it.. Thank a lot!
>> >
>> >
>> >
>> >
>> >
>> > El vie., 29 ene. 2016 a las 9:44, Sebastian Gomez (<ti...@gmail.com>)
>> > escribió:
>> >
>> >> 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! (<nu...@li.nux.ro>) escribió:
>> >>
>> >>> 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
>> cloudbr1
>> >>> and let Cloudstack build the interfaces automatically as required
>> (bond0.83
>> >>> and the respective bridge). This would be closer to recommended
>> practice.
>> >>>
>> >>>
>> >>> HTH
>> >>> Lucian
>> >>>
>> >>> --
>> >>> Sent from the Delta quadrant using Borg technology!
>> >>>
>> >>> Nux!
>> >>> www.nux.ro
>> >>>
>> >>> ----- Original Message -----
>> >>> > From: "Sebastian Gomez" <ti...@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
>> agent
>> >>> > 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
>> VLAN
>> >>> > (554)
>> >>> > - bond0.83 is a virtual interface, configured with the public VLAN
>> (83)
>> >>> >
>> >>> > 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
>> Use
>> >>> > 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
>> the
>> >>> > host on cloudstack (4.5.2), and the process stop with an error
>> informing
>> >>> > 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
>> new
>> >>> > created bridge (brbond0-83), and the process continues.
>> >>> >
>> >>> > The problem is that if I restart the server, the agent cannot
>> re-attach
>> >>> 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
>> about
>> >>> > 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.
>> >>>

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Sebastian Gomez <ti...@gmail.com>.
On the KVM host, I left the network configuration as was, on cloudbr1, with
the bond0.83 attached on it.

On cloudstack:
- I removed the host.
- I changed the public network configuration on cloudstack, deleting the
current and re-creating it without setting the VLAN.

On the host:
- I uninstalled the agent and removed the cloudstack configuration,
- installed the cloudstack-agent again

On cloudstack:
- I added the host and... I was added without problems.

The host maintained clean the network configuration.
All ran perfectly.

Honestly, your clue about not setting the VLAN on cloudstack public network
saved me many hours and some headaches.






El vie., 29 ene. 2016 a las 17:12, Nux! (<nu...@li.nux.ro>) escribió:

> 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" <ti...@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!
> >
> > Oh my God, I spent lot of time trying to solve it.. Thank a lot!
> >
> >
> >
> >
> >
> > El vie., 29 ene. 2016 a las 9:44, Sebastian Gomez (<ti...@gmail.com>)
> > escribió:
> >
> >> 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! (<nu...@li.nux.ro>) escribió:
> >>
> >>> 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
> cloudbr1
> >>> and let Cloudstack build the interfaces automatically as required
> (bond0.83
> >>> and the respective bridge). This would be closer to recommended
> practice.
> >>>
> >>>
> >>> HTH
> >>> Lucian
> >>>
> >>> --
> >>> Sent from the Delta quadrant using Borg technology!
> >>>
> >>> Nux!
> >>> www.nux.ro
> >>>
> >>> ----- Original Message -----
> >>> > From: "Sebastian Gomez" <ti...@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
> agent
> >>> > 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
> VLAN
> >>> > (554)
> >>> > - bond0.83 is a virtual interface, configured with the public VLAN
> (83)
> >>> >
> >>> > 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
> Use
> >>> > 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
> the
> >>> > host on cloudstack (4.5.2), and the process stop with an error
> informing
> >>> > 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
> new
> >>> > created bridge (brbond0-83), and the process continues.
> >>> >
> >>> > The problem is that if I restart the server, the agent cannot
> re-attach
> >>> 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
> about
> >>> > 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.
> >>>
>

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Nux! <nu...@li.nux.ro>.
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" <ti...@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!
> 
> Oh my God, I spent lot of time trying to solve it.. Thank a lot!
> 
> 
> 
> 
> 
> El vie., 29 ene. 2016 a las 9:44, Sebastian Gomez (<ti...@gmail.com>)
> escribió:
> 
>> 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! (<nu...@li.nux.ro>) escribió:
>>
>>> 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 cloudbr1
>>> and let Cloudstack build the interfaces automatically as required (bond0.83
>>> and the respective bridge). This would be closer to recommended practice.
>>>
>>>
>>> HTH
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> ----- Original Message -----
>>> > From: "Sebastian Gomez" <ti...@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 agent
>>> > 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 VLAN
>>> > (554)
>>> > - bond0.83 is a virtual interface, configured with the public VLAN (83)
>>> >
>>> > 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    Use
>>> > 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 the
>>> > host on cloudstack (4.5.2), and the process stop with an error informing
>>> > 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 new
>>> > created bridge (brbond0-83), and the process continues.
>>> >
>>> > The problem is that if I restart the server, the agent cannot re-attach
>>> 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 about
>>> > 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.
>>>

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Sebastian Gomez <ti...@gmail.com>.
It worked for me!

Oh my God, I spent lot of time trying to solve it.. Thank a lot!





El vie., 29 ene. 2016 a las 9:44, Sebastian Gomez (<ti...@gmail.com>)
escribió:

> 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! (<nu...@li.nux.ro>) escribió:
>
>> 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 cloudbr1
>> and let Cloudstack build the interfaces automatically as required (bond0.83
>> and the respective bridge). This would be closer to recommended practice.
>>
>>
>> HTH
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> ----- Original Message -----
>> > From: "Sebastian Gomez" <ti...@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 agent
>> > 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 VLAN
>> > (554)
>> > - bond0.83 is a virtual interface, configured with the public VLAN (83)
>> >
>> > 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    Use
>> > 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 the
>> > host on cloudstack (4.5.2), and the process stop with an error informing
>> > 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 new
>> > created bridge (brbond0-83), and the process continues.
>> >
>> > The problem is that if I restart the server, the agent cannot re-attach
>> 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 about
>> > 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.
>>
>

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Sebastian Gomez <ti...@gmail.com>.
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! (<nu...@li.nux.ro>) escribió:

> 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 cloudbr1
> and let Cloudstack build the interfaces automatically as required (bond0.83
> and the respective bridge). This would be closer to recommended practice.
>
>
> HTH
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> ----- Original Message -----
> > From: "Sebastian Gomez" <ti...@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 agent
> > 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 VLAN
> > (554)
> > - bond0.83 is a virtual interface, configured with the public VLAN (83)
> >
> > 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    Use
> > 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 the
> > host on cloudstack (4.5.2), and the process stop with an error informing
> > 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 new
> > created bridge (brbond0-83), and the process continues.
> >
> > The problem is that if I restart the server, the agent cannot re-attach
> 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 about
> > 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.
>

Re: cloudstack-agent 4.5 problem with cloudbr bridges

Posted by Nux! <nu...@li.nux.ro>.
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 cloudbr1 and let Cloudstack build the interfaces automatically as required (bond0.83 and the respective bridge). This would be closer to recommended practice.


HTH
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

----- Original Message -----
> From: "Sebastian Gomez" <ti...@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 agent
> 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 VLAN
> (554)
> - bond0.83 is a virtual interface, configured with the public VLAN (83)
> 
> 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    Use
> 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 the
> host on cloudstack (4.5.2), and the process stop with an error informing
> 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 new
> created bridge (brbond0-83), and the process continues.
> 
> The problem is that if I restart the server, the agent cannot re-attach 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 about
> 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.