Open Stack

 Hi again...Long day with OpenStack today...

 It seems that the problem with the br100 interface has been solved 
 partially since I can launch an instance but I am not able to ssh nor 
 ping the machine (although I have configured the security group rules). 
 Therefore, I am attaching a PDF file with the topology so far. Could you 
 please be kind enough and let me know what network should I create 
 (obviously the 10.0.0.0 in the manual is not working) in order to be 
 able to ssh to the VMs?

 Ideally they should obtain directly IPs from the x.x.x.128/25 range!

 Thank you all!

 G.

 On Wed, 15 Jan 2014 13:25:59 +0200, Georgios Dimitrakakis wrote:
> Floating IPs seems to be very difficult  for the moment...so let's
> forget them!!
>
> The good news are that I have managed to boot an instance!
> The bad news are that I am not able to ssh to the CirrOS instance!
>
> What and where should I look?? I am confident that this has to do
> with the br100 not being correctly defined!
>
> Best,
>
> G.
>
> On Wed, 15 Jan 2014 11:11:45 +0200, Georgios Dimitrakakis wrote:
>> 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
>>>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: topology.pdf
Type: application/pdf
Size: 127176 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140115/394868cf/attachment.pdf>