Я экспериментирую с функциями «блокировки порта коммутатора» XCP / XenServer, которые позволяют гипервизору ограничивать IP-адреса, которые может использовать виртуальная машина. Однако я не могу заставить его работать так, как ожидалось.
Среда: XCP 1.6 работает на Dell PE2950. ВМ (Ubuntu 12.04 VM) подключена к единой сети. Сеть предоставляется XCP как связанная (но не LACP) немаркированная (т. Е. Без VLAN) сеть. XCP использует OVS, а не мост Linux.
VIF, связанный с рассматриваемой виртуальной машиной, настроен следующим образом:
# 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
Я бы ожидал, что когда виртуальная машина настроена на использование IP-адреса, такого как 192.168.1.132, трафик не будет передаваться, но это:
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
Если я установлю режим блокировки VIF на «отключено», весь трафик перестанет течь, как и ожидалось.
Что мне не хватает? Что-то очевидное для кого-то, я уверен ...
Благодаря некоторой полезной работе в сообществе у нас есть исправление! Проблема была обнаружена и исправлена Джорджем Скуклином. Рассматриваемый сценарий - это / opt / xensource / libexec / setup-vif-rules. Возникла проблема со строкой 234.
"Bridge_name =" xenbr% s "% devid"
«Devid - это номер устройства для domU (например, vif1.15; 15 - devid) и определенно НЕ является номером xenbr (xenbr0, xenbr1 и т. Д.)».
Был создан патч, который заменяет эту строку и добавляет функцию, которая возвращает правильный мост, который также принадлежит VIF. Я перевел свои хосты в режим обслуживания и применил патч из домашнего каталога dom0 на каждом хосте, выполнив следующие действия:
cd ~
wget https://github.com/selectel/xen-api/commit/7f5608382e7d1c634f748ec78ace67c2c98ba617.patch
patch -p2 /opt/xensource/libexec/setup-vif-rules 7f5608382e7d1c634f748ec78ace67c2c98ba617.patch
После исправления я обнаружил, что блокировка уровня VIF работает должным образом в любой сети в моем пуле.