[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] XCP 1.6 BUG: locking-mode not working

  • To: xen-api@xxxxxxxxxxxxx
  • From: George Shuklin <george.shuklin@xxxxxxxxx>
  • Date: Tue, 01 Jan 2013 09:29:43 +0400
  • Delivery-date: Tue, 01 Jan 2013 05:30:02 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>

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 пишет:

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):
                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= 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=,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=,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. :)


Xen-api mailing list

Xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.