[Openstack] Rebooted, now can't ping my guest

Sylvain Bauza sylvain.bauza at digimind.com
Tue Mar 5 12:53:24 UTC 2013


This is up to your responsability to hit the script, afaik.
I haven't deployed the bugfix, I preferred creating my own script called 
by rc.local by convenience (and also because I found the issue and 
mitigated it before talking to the forum)

Once I'll migrate to 2012.2.3, I'll use this .py instead.

-Sylvain

Le 05/03/2013 13:23, Filipe Manco a écrit :
> I read the bug description 
> (https://bugs.launchpad.net/quantum/+bug/1091605) and the fix 
> (https://review.openstack.org/#/c/18302/). But I don't understand who 
> is the responsible to call the script on the startup.
>
> Should I put it on something like rc.local? Or is quantum plugins' 
> responsibility to run the utility?
>
>
> 2013/3/1 Sylvain Bauza <sylvain.bauza at digimind.com 
> <mailto:sylvain.bauza at digimind.com>>
>
>     There is a known bug for the network bridges, when rebooting :
>     https://bugs.launchpad.net/quantum/+bug/1091605
>
>     Try to delete/recreate your br-int/br-ex and then restart
>     openvswitch_plugin/l3/dhcp agents, it should fix the issue.
>
>     -Sylvain
>
>     Le 01/03/2013 15:04, The King in Yellow a écrit :
>>     In my case, it actually appears that my vms aren't up-- the
>>     instances panel says they are up, but looking at the console, it
>>     appears they aren't getting an IP address.  This is a new instance:
>>
>>     Begin: Running /scripts/init-bottom ... done.
>>     [    2.849416] EXT4-fs (vda1): re-mounted. Opts: (null)
>>     cloud-init start-local running: Thu, 28 Feb 2013 13:29:09 +0000. up 10.41 seconds
>>
>>     no instance data found in start-local
>>
>>     cloud-init-nonet waiting 120 seconds for a network device.
>>
>>     cloud-init-nonet gave up waiting for a network device.
>>
>>     ci-info: lo    : 1 127.0.0.1       255.0.0.0       .
>>
>>     ci-info: eth0  : 1 .               .               fa:16:3e:e0:17:f0
>>
>>     route_info failed
>>
>>     Waiting for network configuration...
>>
>>     It looks like it made an OVS port, though. This is on the compute
>>     node, openvswitch-agent.log:
>>
>>
>>     2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils]
>>     Command: ['sudo', '/usr/bin/quantum-rootwrap',
>>     '/etc/quantum/rootwrap.conf', 'ovs-vsctl', '--timeout=2', 'get',
>>     'Interface', 'qvo4f36c3ea-5c', 'external_ids']
>>     Exit code: 0
>>     Stdout: '{attached-mac="fa:16:3e:e0:17:f0",
>>     iface-id="4f36c3ea-5c49-4625-a830-0c81f27ba139",
>>     iface-status=active,
>>     vm-uuid="239d3051-255e-4213-9511-af0a82fcc744"}\n'
>>     Stderr: ''
>>     2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils] Running
>>     command: sudo /usr/bin/quantum-rootwrap
>>     /etc/quantum/rootwrap.conf ovs-vsctl --timeout=2 get Interface
>>     qvo62721ee8-08 external_ids
>>     2013-02-28 08:34:19    DEBUG [quantum.agent.linux.utils]
>>     :
>>     root at os-compute-01:/var/log/quantum# ovs-vsctl show
>>     3a52a17f-9846-4b32-b309-b49faf91bfc4
>>         Bridge br-int
>>             Port "qvo62721ee8-08"
>>                 tag: 1
>>                 Interface "qvo62721ee8-08"
>>             Port "qvo1ed73bcc-9d"
>>                 tag: 1
>>                 Interface "qvo1ed73bcc-9d"
>>             Port "qvoce0c94a9-ef"
>>                 tag: 1
>>                 Interface "qvoce0c94a9-ef"
>>             Port "qvo135e78dd-8e"
>>                 tag: 4095
>>                 Interface "qvo135e78dd-8e"
>>             Port "qvof37b7a55-a3"
>>                 tag: 1
>>                 Interface "qvof37b7a55-a3"
>>
>>             Port br-int
>>                 Interface br-int
>>                     type: internal
>>             Port patch-tun
>>                 Interface patch-tun
>>                     type: patch
>>                     options: {peer=patch-int}
>>             Port "qvoaed25b41-9c"
>>                 tag: 1
>>                 Interface "qvoaed25b41-9c"
>>             Port "qvo4f36c3ea-5c"
>>                 tag: 1
>>                 Interface "qvo4f36c3ea-5c"
>>         Bridge br-tun
>>
>>             Port patch-int
>>                 Interface patch-int
>>                     type: patch
>>                     options: {peer=patch-tun}
>>             Port "gre-1"
>>                 Interface "gre-1"
>>                     type: gre
>>                     options: {in_key=flow, out_key=flow,
>>     remote_ip="10.10.10.1"}
>>
>>             Port br-tun
>>                 Interface br-tun
>>                     type: internal
>>         ovs_version: "1.4.0+build0"
>>     root at os-compute-01:/var/log/quantum#
>>
>>
>>     I supposed it should be getting address via DHCP from
>>     quantum-dhcp-agent on the network node?  It was running, nothing
>>     regarding this MAC in the logs.  I restarted quantum-dhcp-agent
>>     and rebooted, no change.
>>
>>     In fact, I got two CirrOS vms up, logged on the console and
>>     manually IPed them (10.5.5.10/24 <http://10.5.5.10/24> and
>>     10.5.5.11/24 <http://10.5.5.11/24>), and they can't ping each
>>     other.  I would expect them to, right?  They should both be
>>     connected to OVS switch br-int, right?
>>
>>     Any pointers?
>>
>>
>>
>>     _______________________________________________
>>     Mailing list:https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     Post to     :openstack at lists.launchpad.net  <mailto:openstack at lists.launchpad.net>
>>     Unsubscribe :https://launchpad.net/~openstack  <https://launchpad.net/%7Eopenstack>
>>     More help   :https://help.launchpad.net/ListHelp
>
>
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack at lists.launchpad.net
>     <mailto:openstack at lists.launchpad.net>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
>
>
>
>
> -- 
> Filipe Manco
> about.me/fmanco <http://about.me/fmanco>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130305/357a2054/attachment.html>


More information about the Openstack mailing list