1

I am experimenting with XCP/XenServer's "switch port locking" features that allow the hypervisor to limit the IP addresses a virtual machine can use. However, I cannot seem to get it to work as expected.

Environment: XCP 1.6 running on Dell PE2950. VM (Ubuntu 12.04 VM) connected to single network. Network provided to XCP as a bonded (but not LACP), untagged (i.e., no VLANs) network. XCP is using the OVS, not Linux bridging.

VIF associated with the VM in question is configured as follows:

# xe vif-param-list uuid=31c2106f-18c0-1feb-453b-5500f6d7c2b4 
uuid ( RO)                        : 31c2106f-18c0-1feb-453b-5500f6d7c2b4
                 vm-uuid ( RO): 53cf1c1e-8fce-4c75-dbc5-987ed1dd6444
           vm-name-label ( RO): wtctest1
      allowed-operations (SRO): attach; unplug
      current-operations (SRO): 
                  device ( RO): 0
                     MAC ( RO): ae:63:a8:61:f6:24
       MAC-autogenerated ( RO): false
                     MTU ( RO): 1500
      currently-attached ( RO): true
      qos_algorithm_type ( RW): 
    qos_algorithm_params (MRW): 
qos_supported_algorithms (SRO): 
            other-config (MRW): 
            network-uuid ( RO): 8f2489a4-1b0e-b906-24bf-0f1c724396da
      network-name-label ( RO): 192.168.1.0/24
             io_read_kbs ( RO): 0.331
            io_write_kbs ( RO): 0.134
            locking-mode ( RW): locked
            ipv4-allowed (SRW): 192.168.1.131
            ipv6-allowed (SRW): fe80::ac63:a8ff:fe61:f624; 2001:470:e872:1::132

I would expect that when the VM is configured to use an IP such as 192.168.1.132, that the traffic would not be passed, yet it is:

root@wtctest1:~# ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 192.168.1.132/24 brd 192.168.1.255 scope global eth0
root@wtctest1:~# ping -c1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=64 time=1.05 ms

If I set the VIF's locking-mode to "disabled" all traffic ceases to flow, as expected.

What am I missing? Something obvious to someone else, I'm sure...

ktower
  • 1,161
  • 9
  • 14

1 Answers1

1

Thanks to some handy work in the community we have a fix! The problem was discovered and patched by George Skuklin. The script in question is /opt/xensource/libexec/setup-vif-rules. There is an issue with line 234.

“bridge_name = "xenbr%s" % devid”

"Devid is device number for domU (f.e. vif1.15; 15 - devid) and is definitely NOT a xenbr number (xenbr0, xenbr1, etc)."

A patch was created that replaces this line and adds a function that returns the correct bridge the VIF belongs too. I put my hosts into maintenance mode and applied the patch from the dom0 home directory on each host by doing the following:

cd ~

wget https://github.com/selectel/xen-api/commit/7f5608382e7d1c634f748ec78ace67c2c98ba617.patch

patch -p2 /opt/xensource/libexec/setup-vif-rules 7f5608382e7d1c634f748ec78ace67c2c98ba617.patch

After patching I found VIF level locking to be working as intended on any network in my pool.

Matthew
  • 204
  • 6
  • 15