<div dir="ltr">That didn't quite do it. Rebooted <a href="http://10.5.5.5/6">10.5.5.5/6</a> 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:<br>
<br><span style="font-family:courier new,monospace">root@os-compute-01:~# ovs-dpctl show br-int<br>system@br-int:<br> lookups: hit:236399 missed:45742 lost:0<br> flows: 1<br> port 0: br-int (internal)<br>
port 2: qvo7dcd14b3-70<br> port 9: qvo0b459c65-a0<br> port 10: qvo4f36c3ea-5c<br> port 11: qvo62721ee8-08<br> port 12: qvocf833d2a-9e<br> port 13: patch-tun (patch: peer=patch-int)<br>
root@os-compute-01:~# ovs-vsctl show<br>3a52a17f-9846-4b32-b309-b49faf91bfc4<br> Bridge br-int<br> Port br-int<br> Interface br-int<br> type: internal<br> Port "qvo0b459c65-a0"<br>
tag: 1<br> Interface "qvo0b459c65-a0"<br> Port "qvo62721ee8-08"<br> tag: 1<br> Interface "qvo62721ee8-08"<br> Port "qvo4f36c3ea-5c"<br>
tag: 1<br> Interface "qvo4f36c3ea-5c"<br> Port "qvocf833d2a-9e"<br> tag: 1<br> Interface "qvocf833d2a-9e"<br> Port "qvo7dcd14b3-70"<br>
tag: 1<br> Interface "qvo7dcd14b3-70"<br> Port patch-tun<br> Interface patch-tun<br> type: patch<br> options: {peer=patch-int}<br> Bridge br-tun<br>
Port patch-int<br> Interface patch-int<br> type: patch<br> options: {peer=patch-tun}<br> Port br-tun<br> Interface br-tun<br> type: internal<br>
Port "gre-1"<br> Interface "gre-1"<br> type: gre<br> options: {in_key=flow, out_key=flow, remote_ip="10.10.10.1"}<br> ovs_version: "1.4.0+build0"<br>
root@os-compute-01:~# brctl show<br>bridge name bridge id STP enabled interfaces<br>br-int 0000.222603554b47 no qvo0b459c65-a0<br> qvo4f36c3ea-5c<br>
qvo62721ee8-08<br> qvo7dcd14b3-70<br> qvocf833d2a-9e<br>
br-tun 0000.3abeb87cdb47 no<br>qbr0b459c65-a0 8000.3af05347af11 no qvb0b459c65-a0<br> vnet2<br>qbr4f36c3ea-5c 8000.e6a5faf9a181 no qvb4f36c3ea-5c<br>
vnet1<br>qbr62721ee8-08 8000.8af675d45ed7 no qvb62721ee8-08<br> vnet0<br>qbr7dcd14b3-70 8000.aabc605c1b2c no qvb7dcd14b3-70<br>
vnet4<br>qbrcf833d2a-9e 8000.36e77dfc6018 no qvbcf833d2a-9e<br> vnet3<br>root@os-compute-01:~# </span><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 5, 2013 at 8:02 AM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sylvain.bauza@digimind.com" target="_blank">sylvain.bauza@digimind.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>You get it. This is the bug I mentioned
related to compute nodes. Folks, anyone knowing the bug tracking
numbre, btw ?<br>
<br>
'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).<br>
<br>
Could you please try :<br>
sudo ovs-vsctl add-port br-int qvo0b459c65-a0<br>
sudo ovs-vsctl add-port br-int qvo4f36c3ea-5c<br>
sudo ovs-vsctl add-port br-int qvo62721ee8-08<br>
sudo ovs-vsctl add-port br-int qvocf833d2a-9e<br>
sudo service quantum-plugin-openvswitch-agent restart<br>
<br>
and check that your VMs get network back ?<br>
<br>
-Sylvain</div></div></blockquote></div></div></div>