<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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<br>
<br>
<br>
<br>
Le 04/03/2013 15:26, The King in Yellow a écrit :<br>
</div>
<blockquote
cite="mid:CABDznXu=M3CxFsmxfAO52pJO1BBcSBS7sqLHSXhJeDyvX+gipQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>