Yep, there is a nasty bug in setup-vif-rules.
See https://github.com/xen-org/xen-api/pull/953
That 'hardcoded' name is not simply 'not always works', it combines
'xenbr' line with devid (wich is network interface number in domU, not
the bridge number).
So the code is completely broken and works only in case 'xenbr0, devid=0'.
Here proper patch. (If you'll test is with xapi interfaces, please
report results):
diff --git a/scripts/setup-vif-rules b/scripts/setup-vif-rules
index 4ca7230..199b3e1 100755
--- a/scripts/setup-vif-rules
+++ b/scripts/setup-vif-rules
@@ -229,10 +229,15 @@ def create_vswitch_rules(bridge_name, port, config):
# Drop everything else.
add_flow(bridge_name,
"in_port=%s,priority=4000,idle_timeout=0,action=drop
+def get_bridge_name_vswitch(vif_name):
+ '''return bridge vif belong to'''
+ (rc, stdout, stderr) = doexec([vsctl, "iface-to-br", vif_name ])
+ return stdout.readline().strip()
+
def handle_vswitch(vif_type, domid, devid, action):
if (action == "clear") or (action == "filter"):
- bridge_name = "xenbr%s" % devid
vif_name = "%s%s.%s" % (vif_type, domid, devid)
+ bridge_name = get_bridge_name_vswitch(vif_name)
ip_link_set(vif_name, "down")
port = get_vswitch_port(vif_name)
clear_vswitch_rules(bridge_name, port)
30.12.2012 21:19, Tomas Sulo ?????:
Hi,
I think I've found a bug in the setup-vif-rules script. I have
configured locking mode on one VM:
/ locking-mode ( RW): locked
ipv4-allowed (SRW): 192.168.1.13
ipv6-allowed (SRW):/
However I found out that even after I change the IP on the VM it's
still available on the network.
I've checked the logs on the server and I found this for example:
/python: /opt/xensource/libexec/setup-vif-rules[18647] -
['/usr/bin/ovs-ofctl', 'add-flow', 'xenbr0',
'in_port=3,priority=8000,dl_type=0x
0800,nw_proto=0x11,tp_dst=67,dl_src=96:7e:2b:1c:45:81,idle_timeout=0,action=norm
al']/
Notice the xenbr0 interface.
/ovs-ofctl dump-flows xenbr0
ovs-ofctl: xenbr0 is not a bridge or a socket/
xenbr0 doesn't even exist, instead it should be applied to xapi2 in
this case.
The problem seems to be in the handle_vswitch definition in the
setup-vif-rules script:
/def handle_vswitch(vif_type, domid, devid, action):
if (action == "clear") or (action == "filter"):
bridge_name = "xenbr%s" % devid
vif_name = "%s%s.%s" % (vif_type, domid, devid)
ip_link_set(vif_name, "down")
port = get_vswitch_port(vif_name)
clear_vswitch_rules(bridge_name, port)
if action == "filter":
config = get_locking_config(domid, devid)
locking_mode = config["locking_mode"]
if locking_mode == "locked":
create_vswitch_rules(bridge_name, port, config)
if locking_mode in ["locked", "unlocked"]:
ip_link_set(vif_name, "up")
if action == "clear":
ip_link_set(vif_name, "up")/
Notice the hardcoded xenbr? After changing to /bridge_name = "xapi2"
/everything works fine. In my case it's always xapi2. I haven't had
time for an elegant solution.
After this I've started the VM again and everything was working as it
should. After I changed the IP of the VM it was no longer available on
the network.
And here are the ovs-ofctl flows:
/ ovs-ofctl dump-flows xapi2
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=55.637s, table=0, n_packets=0, n_bytes=0,
priority=4000,in_port=4 actions=drop
cookie=0x0, duration=55.769s, table=0, n_packets=5, n_bytes=270,
priority=6000,ip,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=192.168.1.13 actions=NORMAL
cookie=0x0, duration=55.795s, table=0, n_packets=0, n_bytes=0,
priority=7000,arp,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=0.0.0.0,arp_sha=96:7e:2b:1c:45:81
actions=NORMAL
cookie=0x0, duration=55.782s, table=0, n_packets=3, n_bytes=126,
priority=7000,arp,in_port=4,dl_src=96:7e:2b:1c:45:81,nw_src=192.168.1.13,arp_sha=96:7e:2b:1c:45:81
actions=NORMAL
cookie=0x0, duration=55.808s, table=0, n_packets=0, n_bytes=0,
priority=8000,udp,in_port=4,dl_src=96:7e:2b:1c:45:81,tp_dst=67
actions=NORMAL
cookie=0x0, duration=3788.414s, table=0, n_packets=309587,
n_bytes=91537264, priority=0 actions=NORMAL
cookie=0x0, duration=55.729s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=134 actions=drop
cookie=0x0, duration=55.703s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=146 actions=drop
cookie=0x0, duration=55.742s, table=0, n_packets=0, n_bytes=0,
priority=7000,icmp6,in_port=4,icmp_type=136 actions=drop
cookie=0x0, duration=55.65s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=153 actions=drop
cookie=0x0, duration=55.755s, table=0, n_packets=0, n_bytes=0,
priority=7000,icmp6,in_port=4,icmp_type=135 actions=drop
cookie=0x0, duration=55.716s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=137 actions=drop
cookie=0x0, duration=55.677s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=151 actions=drop
cookie=0x0, duration=55.69s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=147 actions=drop
cookie=0x0, duration=55.664s, table=0, n_packets=0, n_bytes=0,
priority=6000,icmp6,in_port=4,icmp_type=152 actions=drop/
I've seen on the internet that more users are facing this issue so
maybe this helps. I hope I didn't write anything stupid, I'm quite new
to XCP. :)
Tomas
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
_______________________________________________
Xen-api mailing list
Xen-api@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
