[Openstack] CentOS Network Create problem

Georgios Dimitrakakis giorgis at acmac.uoc.gr
Wed Jan 15 09:11:45 UTC 2014


 Can someone answer me the following question...

 If I want to have floating IPs should the br100 have static IP (and 
 which? I mean should it be from the floating IP range???) or not??

 What should the configuration for the br100 be if I want floating IPs?

 Best,

 G.

 On Mon, 13 Jan 2014 12:52:05 +0200, Thanassis Parathyras wrote:
> Hi George,
>
> there a lot of deployment options for OpenStack and Networking 
> services.
> First i need to clarify that OpenStack can be run in many different
> ways. That is running OpenStack services in different machines
> according to someone's needs.
> This means that controller and compute nodes can have several setups
> depending each deployment case.
> In your case a controller and a compute node are described in the
> manual as in the following link
> 
> http://docs.openstack.org/trunk/install-guide/install/yum/content/ch_overview.html#overview-architecture
> and nova-network is used in a multi-host setup.
> Multi-host setup for the networking means that every computing host
> will deploy a nova-network service, avoiding SPOF in comparison with 
> a
> single node setup.
> Further, take a note that in a single node setup you could collocate
> nova-network in the "controller"node.
> All these trying to explain you some of the many different setups.
>
> Now, for your case br100 should be on compute node only. This can be
> done either by running the command in controller or in compute,
> usually controller is used because nova-clients live there.
>
> Hope i didn't grow your confusion :)
> Thanassis
>
> Thanassis Parathyras
> StackMasters - The European OpenStack Integration Company
> www.stackmasters.eu
>
> On 13/1/2014 12:54 πμ, Georgios Dimitrakakis wrote:
>>
>> Thank you all for your suggestions!
>>
>> I was (and still am) confused since the manual says that the 
>> nova-network create command should be run on the controller node. That 
>> is obviously failing because no br100 is defined. So do I have to put 
>> br100 on the controller as well or should I just create the network on 
>> the compute node?
>> What are the differences in these setups?
>>
>> Best,
>>
>> G.
>>
>> On Thu, 09 Jan 2014 10:05:54 -0600, Dimitri Maziuk wrote:
>>> On 1/9/2014 4:11 AM, Georgios Dimitrakakis wrote:
>>>> Hello again!
>>>>
>>>> No the br100 was not created automatically unfortunately! There is 
>>>> also
>>>> this bug report: 
>>>> https://bugs.launchpad.net/openstack-manuals/+bug/1241331
>>>
>>> I'm not 100% sure but I think in my case it did get created
>>> automatically when I tried to fire up the cirros instance the 2nd 
>>> time
>>> around... However, I may have created the bridge manually at some
>>> point while fighting with it, I forget.
>>>
>>>
>>> 
>>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Virtualization/sect-Virtualization-Network_Configuration-Bridged_networking_with_libvirt.html
>>>
>>>
>>> (from "disable network manager" down to "restart networking or 
>>> reboot")
>>>
>>> Also check that vhost_net module is loaded (lsmod).
>>>
>>>> Since it wasn't created automatically I am asking if it has to be 
>>>> on
>>>> both nodes (controller + compute) in order for the network to work
>>>> correctly? Furthermore, I would like to know how should it be 
>>>> bridged in
>>>> order to achieve floating (public) IPs?
>>>
>>> Compute only: this is the interface VMs use to talk to the world.
>>> Floating IPs are a separate story really -- but if I uderstand the
>>> question correctly, your br100 should be bridged to the subnet 
>>> where
>>> your floating IPs are.
>>>
>>> I.e. if your eth0 is on 1.2.3.0/24 and your eth1 is on 10.0.0.0/24,
>>> and you want floating IPs in 1.2.3.0/24 range, then you want to 
>>> bridge
>>> br100 to eth0.
>>>
>>> Dima
>>>
>>>
>>> _______________________________________________
>>> Mailing list: 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>> Post to : openstack at lists.openstack.org
>>> Unsubscribe : 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>





More information about the Openstack mailing list