[Openstack] Need help - Compute Node restarted - Ramdom Instances doesn't get and IP anymore

Darragh O'Reilly dara2002-openstack at yahoo.com
Thu Nov 21 10:42:48 UTC 2013


I think this needs to be fixed in the Ubuntu packaging. Neutron-ovs-cleanup needs to run after openvswitch-switch starts and before nova-compute starts. But care needs to be taken for the case where neutron-dhcp-agent and/or neutron-l3-agent also runs on a node with nova-compute. Cleanup should run before these start too. It's easy to do this with the system V init system, but I'm not sure how with upstart.

Re, Darragh.




On Thursday, 21 November 2013, 7:50, Jian Wen <jian.wen at canonical.com> wrote:
 
It is https://bugs.launchpad.net/neutron/+bug/1091605
>
>
>The patch fixes the above bug introduces another bug: 
>https://bugzilla.redhat.com/show_bug.cgi?id=1010941
>
>
>
>
>On Thu, Nov 21, 2013 at 2:18 PM, Jean-Daniel BUSSY <silversurfer972 at gmail.com> wrote:
>
>Nice! Thanks Thiago for the details.
>>Looks like this bug should be reported.
>>
>>
>>Cheers
>>
>>
>>
>>BUSSY Jean-Daniel
>>Cloud Engineer | GREE
>>Mobile: +81 090-3317-1337
>>Email: silversurfer972 at gmail.com
>>
>>
>>
>>On Tue, Nov 19, 2013 at 7:01 PM, Darragh O'Reilly <dara2002-openstack at yahoo.com> wrote:
>>
>>Hi Thiago,
>>>
>>>I did a qucik test with Havana on Ubuntu 12.04 with QEMU, OVS 1.10.2 and the OVS hybrid driver. Started an instance, rebooted the compute node, and the instance goes to status STOPPED. Then ran 'nova start instance-name', and it starts ok, but DHCP does not work.
>>>
>>>In the logs I see OVS starting first and recreating the qvoxxxxxx-xx port and interface from its database. Then nova-compute starts and creates the qbr Linux bridge and qvb interface, but it is not recreating the  qvo port and interface because they already exist.  Everything looks ok, and the DHCP requests are getting to qvo, but they are not getting into br-int.
>>>
>>>It seems the qvo interface needs to be created by Nova (using the ip command) before the OVS port is created with the same name. Otherwise OVS does not seem to enslave the interface.
>>>
>>>I added this upstart script to run cleanup which will delete the ports on br-int before nova-compute and the OVS agent start:
>>>
>>>root at compute1:~# cat /etc/init/neutron-ovs-cleanup.conf
>>>start on starting nova-compute or neutron-plugin-openvswitch-agent
>>>script
>>>  /usr/bin/neutron-ovs-cleanup
>>>end script
>>>
>>>Now nova-compute has to recreate everything, and the instance is getting an IP with DHCP. Maybe you can try this out in your test environment.
>>>
>>>Re, Darragh.
>>>
>>>
>>>
>>>
>>>>Guys,
>>>>
>>>>My Havana (Ubuntu based) Compute Node was restarted and lots of Instances
>>>>does not get an IP anymore.
>>>>
>>>>Tips?!
>>>>
>>>
>>>>It is ramdom, I mean, some instances of this same compute node are normal,
>>>>while others have no IP.
>>>>
>>>
>>>>I really need help here because my client's web site is completely off line
>>>>now...
>>>>
>>>>I'm using Per-Tenant router with private networks + VXLAN.
>>>>
>>>>Tks!
>>>>Thiago
>>>
>>>
>>>_______________________________________________
>>>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
>>
>>
>>
>
>
>
>
>-- 
>
>Cheers,
>Jian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131121/810c2cf7/attachment.html>


More information about the Openstack mailing list