<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 4, 2013 at 3:18 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>Is the network node also acting as a
Compute node ?<br></div></div></blockquote><div><br></div><div>No, I am running three separate nodes-- network, compute and controller.<br></div><div> </div><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>
The issue you were mentioning was related to the tap virtual
device (for DHCP leases) : if the network node goes down, then the
DHCP lease is expiring on the vm without being reack, and then
your instance is loosing its IP address.<br>
By recreating the bridges upon reboot on the network node, the tap
interface will be back up. On the VMs, only a DHCP request is
enough, not a reboot (or even a compute node reboot).<br>
<br>
I know there is also a second bug related to virtio bridges on the
compute nodes. This is still a bit unclear to me, but upon compute
node reboot, virtio bridges are also not reattached, only new
instances created afterwards.<br>
<br>
Could you please run 'ovs-dpctl show br-int' (provided br-int is
the right bridge), 'ovs-vsctl show' and 'brctl show' ?<br></div></div></blockquote><div><br></div><div>This is on the compute node, where I assume the issue is. For the record, I have five vms running here-- four created before rebuilding the networking, and one after. Only the one after is working.<br>
</div><div><br><span style="font-family:courier new,monospace">root@os-compute-01:/var/log# ovs-dpctl show br-int<br>system@br-int:<br> lookups: hit:235944 missed:33169 lost:0<br> flows: 0<br> port 0: br-int (internal)<br>
port 1: patch-tun (patch: peer=patch-int)<br> port 2: qvo7dcd14b3-70<br>root@os-compute-01:/var/log# ovs-vsctl show<br>3a52a17f-9846-4b32-b309-b49faf91bfc4<br> Bridge br-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>
Port patch-int<br> Interface patch-int<br> type: patch<br> options: {peer=patch-tun}<br> Bridge br-int<br> Port br-int<br> Interface br-int<br> type: internal<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>
ovs_version: "1.4.0+build0"<br>root@os-compute-01:/var/log# brctl show<br>bridge name bridge id STP enabled interfaces<br>br-int 0000.222603554b47 no qvo7dcd14b3-70<br>
br-tun 0000.36c126165e42 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:/var/log# </span><br>
<br></div><div>Thank you for the assistance! Lot of new stuff here I'm trying to come up to speed on.<br><br></div><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>
<br>
Le 01/03/2013 21:28, The King in Yellow a écrit :<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Mar 1, 2013 at 10:11 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>There is a known bug for the network bridges, when
rebooting : <br>
<a href="https://bugs.launchpad.net/quantum/+bug/1091605" target="_blank">https://bugs.launchpad.net/quantum/+bug/1091605</a><br>
<br>
Try to delete/recreate your br-int/br-ex and then
restart openvswitch_plugin/l3/dhcp agents, it should
fix the issue.</div>
</div>
</blockquote>
<div><br>
</div>
<div>Thanks! Now, I can create a new instance, and that
works. My previous instances don't work, however. What
do I need to do to get them reattached?<br>
<br>
<br>
<span style="font-family:courier new,monospace">root@os-network:/var/log/quantum#
ping 10.5.5.6<br>
PING 10.5.5.6 (10.5.5.6) 56(84) bytes of data.<br>
^C<br>
--- 10.5.5.6 ping statistics ---<br>
2 packets transmitted, 0 received, 100% packet loss,
time 1008ms<br>
<br>
root@os-network:/var/log/quantum# ping 10.5.5.7<br>
PING 10.5.5.7 (10.5.5.7) 56(84) bytes of data.<br>
64 bytes from <a href="http://10.5.5.7" target="_blank">10.5.5.7</a>: icmp_req=1 ttl=64
time=2.13 ms<br>
64 bytes from <a href="http://10.5.5.7" target="_blank">10.5.5.7</a>: icmp_req=2 ttl=64
time=1.69 ms<br>
64 bytes from <a href="http://10.5.5.7" target="_blank">10.5.5.7</a>: icmp_req=3 ttl=64
time=1.93 ms<br>
64 bytes from <a href="http://10.5.5.7" target="_blank">10.5.5.7</a>: icmp_req=4 ttl=64
time=1.01 ms<br>
^C<br>
--- 10.5.5.7 ping statistics ---<br>
4 packets transmitted, 4 received, 0% packet loss, time
3003ms<br>
rtt min/avg/max/mdev = 1.013/1.692/2.132/0.424 ms<br>
root@os-network:/var/log/quantum# </span><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br><br></div></div>