[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