Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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...

share|improve this question

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer
    
That did the trick, excellent. Hopefully it'll get merged into the release code base soon. –  ktower Jan 7 '13 at 3:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.