← Back to team overview

openstack team mailing list archive

Re: Rebooted, now can't ping my guest

 

That didn't quite do it.  Rebooted 10.5.5.5/6 and they did not get IPs.
Brought one up manually and could not ping anything else.  I note that I'm
missing the "tag" statement on those recreated interfaces in "ovs-vsctl
show", so I deleted the interfaces and reran the statements you gave with
"tag=1" appended.  Now, my manually configured 10.5.5.5 COULD ping my
working 10.5.5.7, and I could ssh between the two.  However, 10.5.5.5 still
can not get a DHCP address or (with hardcoded IP) reach 10.5.5.1 on the
network node, whereas 10.5.5.7 can.  Here's how things look now:

root@os-compute-01:~# ovs-dpctl show br-int
system@br-int:
        lookups: hit:236399 missed:45742 lost:0
        flows: 1
        port 0: br-int (internal)
        port 2: qvo7dcd14b3-70
        port 9: qvo0b459c65-a0
        port 10: qvo4f36c3ea-5c
        port 11: qvo62721ee8-08
        port 12: qvocf833d2a-9e
        port 13: patch-tun (patch: peer=patch-int)
root@os-compute-01:~# ovs-vsctl show
3a52a17f-9846-4b32-b309-b49faf91bfc4
    Bridge br-int
        Port br-int
            Interface br-int
                type: internal
        Port "qvo0b459c65-a0"
            tag: 1
            Interface "qvo0b459c65-a0"
        Port "qvo62721ee8-08"
            tag: 1
            Interface "qvo62721ee8-08"
        Port "qvo4f36c3ea-5c"
            tag: 1
            Interface "qvo4f36c3ea-5c"
        Port "qvocf833d2a-9e"
            tag: 1
            Interface "qvocf833d2a-9e"
        Port "qvo7dcd14b3-70"
            tag: 1
            Interface "qvo7dcd14b3-70"
        Port patch-tun
            Interface patch-tun
                type: patch
                options: {peer=patch-int}
    Bridge br-tun
        Port patch-int
            Interface patch-int
                type: patch
                options: {peer=patch-tun}
        Port br-tun
            Interface br-tun
                type: internal
        Port "gre-1"
            Interface "gre-1"
                type: gre
                options: {in_key=flow, out_key=flow, remote_ip="10.10.10.1"}
    ovs_version: "1.4.0+build0"
root@os-compute-01:~# brctl show
bridge name     bridge id               STP enabled     interfaces
br-int          0000.222603554b47       no              qvo0b459c65-a0
                                                        qvo4f36c3ea-5c
                                                        qvo62721ee8-08
                                                        qvo7dcd14b3-70
                                                        qvocf833d2a-9e
br-tun          0000.3abeb87cdb47       no
qbr0b459c65-a0          8000.3af05347af11       no
qvb0b459c65-a0
                                                        vnet2
qbr4f36c3ea-5c          8000.e6a5faf9a181       no
qvb4f36c3ea-5c
                                                        vnet1
qbr62721ee8-08          8000.8af675d45ed7       no
qvb62721ee8-08
                                                        vnet0
qbr7dcd14b3-70          8000.aabc605c1b2c       no
qvb7dcd14b3-70
                                                        vnet4
qbrcf833d2a-9e          8000.36e77dfc6018       no
qvbcf833d2a-9e
                                                        vnet3
root@os-compute-01:~#


On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza <sylvain.bauza@xxxxxxxxxxxx>wrote:

>  You get it. This is the bug I mentioned related to compute nodes. Folks,
> anyone knowing the bug tracking numbre, btw ?
>
> 'ovs-dpctl show' shows you that only qvo7dcd14b3-70 is bridged to br-int
> (and mapped to vnet4, which I guess is the vnet device for the correct VM).
>
> Could you please try :
> sudo ovs-vsctl add-port br-int qvo0b459c65-a0
> sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c
> sudo ovs-vsctl add-port br-int qvo62721ee8-08
> sudo ovs-vsctl add-port br-int qvocf833d2a-9e
> sudo service quantum-plugin-openvswitch-agent restart
>
> and check that your VMs get network back ?
>
> -Sylvain
>

Follow ups

References