You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Edison Su <Ed...@citrix.com> on 2013/07/31 20:06:32 UTC
FW: CS 4.1.0 - this will help a number of people who struggle with
Advanced Networking
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.
RE: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Jessica Tomechak <Je...@citrix.com>.
There are 10 open Doc bugs against the KVM docs. Whoever does rewrite this chapter might want to consult those items for ideas.
If your issues aren't included there, please do file an additional bug with your valuable input!
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20component%20in%20(doc%2C%20Doc)%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20%22Ready%20To%20Review%22)%20AND%20text%20~%20%22kvm%22
Jessica T.
________________________________________
From: Nordgren, Bryce L -FS [bnordgren@fs.fed.us]
Sent: Wednesday, July 31, 2013 1:22 PM
To: users@cloudstack.apache.org
Subject: RE: FW: CS 4.1.0 - this will help a number of people who struggle with Advanced Networking
+1
Working 1/2 time for about two weeks now, trying to install on a two-box test environment. Let me test something that works! I vote for describing a super simple test case:
+ two boxes
+ two networks
+ minimize impact on public network (no VLAN requirements; no private IPs on public network hardware, etc.)
I'm using the StackIQ Rocks+Cloud distribution. (RHEL/CentOS 6.4; Cloudstack 4.0.2)
Bryce
-----Original Message-----
From: Philip Andrews [mailto:pandrews@Thunderhead.com]
Sent: Wednesday, July 31, 2013 1:14 PM
To: users@cloudstack.apache.org; rwheeler@artifact-software.com
Subject: Re: FW: CS 4.1.0 - this will help a number of people who struggle with Advanced Networking
Here too, we've been working through a cloudstack install on a 3 box test environment for almost a week with 95% of the issues being networking due to poor documentation. I'd be happy to follow some new procedures and provide feedback.
Also running CentOS 6.4 on all boxes.
-Phil
On 07/31/2013 03:00 PM, Ron Wheeler wrote:
> If you need an ignorant person with a lot of CentOS system admin
> experience to walk through the procedure with the authors, let me know.
> I have a bare CentOS 6.4 ready to be made into something that runs
> CloudStack and supports a CentOS VM. If that works, I can rustle up
> another piece of hardware with a bare CentOS to add to the confusion.
>
> Ron
>
> On 31/07/2013 2:33 PM, Marcus Sorensen 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 <Ed...@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.
>>>
>>>
Philip Andrews
Senior Linux Engineer
T +1 603-625-2280
F +1 603-641-2280
M
mailto:pandrews@Thunderhead.com
Thunderhead.com is the trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Catalyst House 720 Centennial Court, Centennial Park, Elstree, Herts. WD6 3SY.
----------------------------------------------------------------------
The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
----------------------------------------------------------------------
-----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.
>>>
>
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Ron Wheeler <rw...@artifact-software.com>.
Sounds like a good basic config.
I am behind a firewall so I need a little corner of modernity that does
not require changes to and does not touche the public IP and does not
affect existing production web applications running on existing hardware.
Once this works, I should be able to add more hardware and move
production applications into the private cloud and hook them up to the
greater universe.
My boxes have a single NIC but I could spring for another one if that
turned out to be the best configuration to get up and running in an hour.
Ron
On 31/07/2013 4:22 PM, Nordgren, Bryce L -FS wrote:
> +1
>
> Working 1/2 time for about two weeks now, trying to install on a two-box test environment. Let me test something that works! I vote for describing a super simple test case:
>
> + two boxes
> + two networks
> + minimize impact on public network (no VLAN requirements; no private IPs on public network hardware, etc.)
>
> I'm using the StackIQ Rocks+Cloud distribution. (RHEL/CentOS 6.4; Cloudstack 4.0.2)
>
> Bryce
>
> -----Original Message-----
> From: Philip Andrews [mailto:pandrews@Thunderhead.com]
> Sent: Wednesday, July 31, 2013 1:14 PM
> To: users@cloudstack.apache.org; rwheeler@artifact-software.com
> Subject: Re: FW: CS 4.1.0 - this will help a number of people who struggle with Advanced Networking
>
> Here too, we've been working through a cloudstack install on a 3 box test environment for almost a week with 95% of the issues being networking due to poor documentation. I'd be happy to follow some new procedures and provide feedback.
>
> Also running CentOS 6.4 on all boxes.
>
> -Phil
>
> On 07/31/2013 03:00 PM, Ron Wheeler wrote:
>> If you need an ignorant person with a lot of CentOS system admin
>> experience to walk through the procedure with the authors, let me know.
>> I have a bare CentOS 6.4 ready to be made into something that runs
>> CloudStack and supports a CentOS VM. If that works, I can rustle up
>> another piece of hardware with a bare CentOS to add to the confusion.
>>
>> Ron
>>
>> On 31/07/2013 2:33 PM, Marcus Sorensen 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 <Ed...@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.
>>>>
>>>>
> Philip Andrews
> Senior Linux Engineer
>
> T +1 603-625-2280
> F +1 603-641-2280
> M
> mailto:pandrews@Thunderhead.com
>
> Thunderhead.com is the trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Catalyst House 720 Centennial Court, Centennial Park, Elstree, Herts. WD6 3SY.
> ----------------------------------------------------------------------
> The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
> ----------------------------------------------------------------------
>
>
> -----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.
>>>>
>
>
>
>
>
> This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
RE: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by "Nordgren, Bryce L -FS" <bn...@fs.fed.us>.
+1
Working 1/2 time for about two weeks now, trying to install on a two-box test environment. Let me test something that works! I vote for describing a super simple test case:
+ two boxes
+ two networks
+ minimize impact on public network (no VLAN requirements; no private IPs on public network hardware, etc.)
I'm using the StackIQ Rocks+Cloud distribution. (RHEL/CentOS 6.4; Cloudstack 4.0.2)
Bryce
-----Original Message-----
From: Philip Andrews [mailto:pandrews@Thunderhead.com]
Sent: Wednesday, July 31, 2013 1:14 PM
To: users@cloudstack.apache.org; rwheeler@artifact-software.com
Subject: Re: FW: CS 4.1.0 - this will help a number of people who struggle with Advanced Networking
Here too, we've been working through a cloudstack install on a 3 box test environment for almost a week with 95% of the issues being networking due to poor documentation. I'd be happy to follow some new procedures and provide feedback.
Also running CentOS 6.4 on all boxes.
-Phil
On 07/31/2013 03:00 PM, Ron Wheeler wrote:
> If you need an ignorant person with a lot of CentOS system admin
> experience to walk through the procedure with the authors, let me know.
> I have a bare CentOS 6.4 ready to be made into something that runs
> CloudStack and supports a CentOS VM. If that works, I can rustle up
> another piece of hardware with a bare CentOS to add to the confusion.
>
> Ron
>
> On 31/07/2013 2:33 PM, Marcus Sorensen 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 <Ed...@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.
>>>
>>>
Philip Andrews
Senior Linux Engineer
T +1 603-625-2280
F +1 603-641-2280
M
mailto:pandrews@Thunderhead.com
Thunderhead.com is the trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Catalyst House 720 Centennial Court, Centennial Park, Elstree, Herts. WD6 3SY.
----------------------------------------------------------------------
The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
----------------------------------------------------------------------
-----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.
>>>
>
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Philip Andrews <pa...@Thunderhead.com>.
Here too, we've been working through a cloudstack install on a 3 box
test environment for almost a week with 95% of the issues being
networking due to poor documentation. I'd be happy to follow some new
procedures and provide feedback.
Also running CentOS 6.4 on all boxes.
-Phil
On 07/31/2013 03:00 PM, Ron Wheeler wrote:
> If you need an ignorant person with a lot of CentOS system admin
> experience to walk through the procedure with the authors, let me know.
> I have a bare CentOS 6.4 ready to be made into something that runs
> CloudStack and supports a CentOS VM. If that works, I can rustle up
> another piece of hardware with a bare CentOS to add to the confusion.
>
> Ron
>
> On 31/07/2013 2:33 PM, Marcus Sorensen 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 <Ed...@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.
>>>
>>>
Philip Andrews
Senior Linux Engineer
T +1 603-625-2280
F +1 603-641-2280
M
mailto:pandrews@Thunderhead.com
Thunderhead.com is the trading name of Thunderhead Limited which is registered in England under No. 4303041 whose registered office is at Catalyst House 720 Centennial Court, Centennial Park, Elstree, Herts. WD6 3SY.
----------------------------------------------------------------------
The contents of this e-mail are intended for the named addressee only. It contains confidential information. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
----------------------------------------------------------------------
-----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.
>>>
>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Ron Wheeler <rw...@artifact-software.com>.
If you need an ignorant person with a lot of CentOS system admin
experience to walk through the procedure with the authors, let me know.
I have a bare CentOS 6.4 ready to be made into something that runs
CloudStack and supports a CentOS VM. If that works, I can rustle up
another piece of hardware with a bare CentOS to add to the confusion.
Ron
On 31/07/2013 2:33 PM, Marcus Sorensen 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 <Ed...@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.
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
Here's a simple (not recommended) one-nic setup:
http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-one-nic.rtf
And a simple two-nic setup:
http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-two-nic.rtf
Hasty docs put together on the road...
On Thu, Aug 1, 2013 at 11:28 AM, Marcus Sorensen <sh...@gmail.com> wrote:
> 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 <sh...@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 <Ed...@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.
>>>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
Here's a simple (not recommended) one-nic setup:
http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-one-nic.rtf
And a simple two-nic setup:
http://marcus.mlsorensen.com/cloudstack-extras/cs-4.1-kvm-networking-two-nic.rtf
Hasty docs put together on the road...
On Thu, Aug 1, 2013 at 11:28 AM, Marcus Sorensen <sh...@gmail.com> wrote:
> 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 <sh...@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 <Ed...@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.
>>>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <sh...@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 <Ed...@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.
>>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <sh...@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 <Ed...@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.
>>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <Ed...@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.
>
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Ron Wheeler <rw...@artifact-software.com>.
This is a great step forward.
Does anyone have an installation manual that is correct?
When will there be a version of Cloudstack with a manual that actually
works?
I have given up on Cloudstack for now but will give it another shot when
it works.
I hope that someone at least walks through the procedure once before
releasing a new version.
It is very disheartening to spend hours executing procedures and then
redoing it when it does not work trying to find where one went wrong.
There are no verification steps in the process to help understand where
you got off the track.
IMHO the manual is too complex in trying to support too many options.
There should be a simple track through for each of the main hypervisor
choices. It would also be helpful to include some diagrams and
descriptions of what the proposed installation is supposed to look like
at key points. "At the end of these steps, you will have a KVM
hypervisor that is attached to your firewall as x.x.x.x on eth0.xxxx and
VLANs on xxx.xxx......"
Trying to guess what one is making by reading the recipe is a bit
frustrating.
Ron
On 31/07/2013 2:06 PM, Edison Su 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.
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: FW: CS 4.1.0 - this will help a number of people who struggle
with Advanced Networking
Posted by Marcus Sorensen <sh...@gmail.com>.
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 <Ed...@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.
>