That didn't quite do it. Rebooted 10.5.5.5/6 <http://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 <mailto: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
