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="">
+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="">
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@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
|
