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...
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:
After patching I found VIF level locking to be working as intended on any network in my pool.