С Ubuntu 16.04 и KVM, я не могу заставить vms объединяться в сеть, не используя NAT
Я пытаюсь получить vm, работающий в KVM, который действует, как будто он имеет свой собственный физический сетевой интерфейс в локальной сети. Я полагаю, что это называют, образовывая мост, и я судил следующие много различных руководств онлайн без удачи. Каждый раз я заканчиваю с VM, который имеет виртуальный сетевой адаптер, который не может говорить с моей локальной сетью.
Мой хост и гости все выполняют сервер Ubuntu 16.04.
Я запустил путем добавления a br0 к моему /etc/network/interfaces файл, который теперь похож на это:
~$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface enp2s0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports enp2s0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
После перезагрузки мой ifconfig похож на это:
~$ ifconfig
br0 Link encap:Ethernet HWaddr d0:50:99:c0:25:fb
inet addr:192.168.113.2 Bcast:192.168.113.255 Mask:255.255.255.0
...
docker0 Link encap:Ethernet HWaddr 02:42:dc:4f:96:9e
...
enp2s0 Link encap:Ethernet HWaddr d0:50:99:c0:25:fb
inet6 addr: fe80::d250:99ff:fec0:25fb/64 Scope:Link
...
lo Link encap:Local Loopback
...
veth009cb0a Link encap:Ethernet HWaddr 66:d6:6c:e7:80:cb
inet6 addr: fe80::64d6:6cff:fee7:80cb/64 Scope:Link
...
virbr0 Link encap:Ethernet HWaddr 52:54:00:1a:56:65
inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0
...
Хост имеет статическую запись в моем сервере DHCP, таким образом, это всегда добирается 192.168.113.2, так, чтобы IP на br0 был корректен. Насколько я понимаю все, что я должен должен быть сделать теперь, должно запустить новый vm использование интерфейса br0. Таким образом, я выполняю это:
sudo virt-install --virt-type=kvm --name myvm \
--hvm --ram 4096 --vcpus=2 --graphics vnc \
--network bridge=br0 \
--os-type=linux --os-variant=ubuntu16.04 \
--cdrom=/var/lib/libvirt/boot/ubuntu-16.04.2-server-amd64.iso \
--disk path=/var/lib/libvirt/images/myvm.qcow2,size=16,bus=virtio,format=qcow2
Я могу VNC в vm и прогресс через установку в этой точке, пока я не получаю к "Конфигурированию сети с DHCP" фазу, в которой точке это приводит к таймауту и никогда не получает IP.
Если я использую интерфейс NAT по умолчанию, он хорошо работает, надевает IP 192.168.112.xxx диапазон и может получить доступ к локальной сети и большему Интернету, без проблем., Если я затем изменяю конфигурацию virsh на этой работе vm для образования моста к br0, то я не могу говорить ни с какой сетью, локальной или иначе. DHCP не удается получить IP, и установка статического IP приводит не к движению на внешней стороне.
В случае, если это полезно, в то время как установщик работал, я открыл другой терминал и получил больше информации от хоста:
~$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.d05099c025fb no enp2s0
vnet0
docker0 8000.0242dc4f969e no veth009cb0a
virbr0 8000.5254001a5665 yes virbr0-nic
~$ brctl showmacs br0
port no mac addr is local? ageing timer
1 00:04:20:eb:7e:96 no 3.90
1 00:11:32:63:9c:cf no 1.86
1 30:46:9a:0f:81:cd no 3.39
1 44:8a:5b:9e:d1:90 no 0.00
1 88:de:a9:13:86:48 no 0.29
1 b8:ae:ed:73:3e:ca no 3.89
1 d0:50:99:c0:25:fb yes 0.00
1 d0:50:99:c0:25:fb yes 0.00
1 d0:50:99:e0:21:46 no 2.90
1 f0:f6:1c:e3:7f:be no 173.56
2 fe:54:00:6f:b8:64 yes 0.00
2 fe:54:00:6f:b8:64 yes 0.00
~$ ip route
default via 192.168.113.1 dev br0
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.113.0/24 dev br0 proto kernel scope link src 192.168.113.2
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Я готов подбросить весь dumpxml здесь, если кто-то хочет его, но здесь является просто сегментом сети:
<interface type='bridge'>
<mac address='52:54:00:6f:b8:64'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
ОБНОВЛЕНИЕ 25.03.2017: Путем изменения следующего:
<interface type='network'>
<mac address='52:54:00:6f:b8:64'/>
<source network='default'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
Затем NAT работает, и я добираюсь 192.168.122.xxx IP и могу говорить с внешними сервисами и т.д. Так... есть ли что-то не так с моими хостами br0? Если так, затем почему хост получает IP на нем очень хорошо? Есть ли некоторые устройства Ethernet, которые просто не поддерживают образование моста? Вот результат lspci на хосте:
~$ lspci | grep Ethernet
02:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
03:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
Я не имею, устанавливают второй контроллер Ethernet вообще, возможно, я настрою его и попытаюсь соединить мостом тот вместо этого.
ОБНОВИТЕ 25.03.2017 b: второй интерфейс, казалось, не изменил результаты. Вот получающийся/etc/network/interfaces:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet dhcp
auto enp3s0
iface enp3s0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports enp3s0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
Который, когда я ip a, результаты в:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether d0:50:99:c0:25:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.113.2/24 brd 192.168.113.255 scope global enp2s0
valid_lft forever preferred_lft forever
inet6 fe80::d250:99ff:fec0:25fb/64 scope link
valid_lft forever preferred_lft forever
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
link/ether d0:50:99:c0:25:fa brd ff:ff:ff:ff:ff:ff
inet6 fe80::d250:99ff:fec0:25fa/64 scope link
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether d0:50:99:c0:25:fa brd ff:ff:ff:ff:ff:ff
inet 192.168.113.100/24 brd 192.168.113.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::d250:99ff:fec0:25fa/64 scope link
valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:1a:56:65 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:1a:56:65 brd ff:ff:ff:ff:ff:ff
7: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:18:2c:73:bb brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:18ff:fe2c:73bb/64 scope link
valid_lft forever preferred_lft forever
9: vethaa3cd40@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether ae:05:f7:1b:f9:9e brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::ac05:f7ff:fe1b:f99e/64 scope link
valid_lft forever preferred_lft forever
10: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
link/ether fe:54:00:3a:54:b3 brd ff:ff:ff:ff:ff:ff
inet6 fe80::fc54:ff:fe3a:54b3/64 scope link
valid_lft forever preferred_lft forever
VM продолжает иметь те же самые проблемы при сообщении использовать br0.
3 ответа
Решенный.
проблемой были настройки по умолчанию в br_netfilter модуле, которые отправляют соединенные мостом пакеты в iptables. libvirt документы действительно упоминают это на их сетевая страница , но большинство учебных руководств, за которыми я следовал, не касалось его.
По некоторым причинам iptables ел те пакеты (возможно, что-то, что докер добавил?), но отправляющий те пакеты в iptables по-видимому неэффективен невнимательный, таким образом, фиксация должна обойти iptables путем изменения тех настроек.
Примечание метод, который я обрисовываю в общих чертах здесь, является на самом деле примером в , sysctl.d страница справочника .
Создает /etc/udev/rules.d/99-bridge.rules и вставляет эту строку:
ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", RUN+="/lib/systemd/systemd-sysctl --prefix=/net/bridge"
Затем создайте /etc/sysctl.d/bridge.conf и вставьте эти три строки:
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Затем я просто должен был вернуться назад к моей исходной установке моста, которая включает /etc/network/interfaces, который похож на это:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports enp2s0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
И virsh определение сетевого интерфейса, которое похоже на это:
<interface type='bridge'>
<mac address='52:54:00:37:e1:55'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
Со всем, что на месте, мои начальные загрузки VM, это получает IP, и я могу свободно говорить со своим хостом, локальной сетью и Интернетом.
Я заставил это работать, с помощью прямого вместо моста:
Используя это /etc/network/interfaces
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto enp2s0
iface enp2s0 inet dhcp
auto enp3s0
iface enp3s0 inet manual
И эта установка virsh:
<interface type='direct'>
<mac address='52:54:00:37:e1:55'/>
<source dev='enp3s0' mode='vepa'/>
<target dev='macvtap0'/>
<model type='rtl8139'/>
<alias name='net0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
Моя локальная сеть видит 52:54:00:37:e1:55 MAC-адрес, и сервер DHCP дает ему IP, и я могу ssh в к этой машине через тот IP, таким образом, все кажется хорошим. Я могу выполнить второй VM одновременно, его MAC также получает IP, таким образом, у меня, кажется, есть решение, я хотел.
, Возможно, затем я попытаюсь делать все это на исходном порте Ethernet. Мне также любопытно, что образование моста действительно, и что оно решает, это прямое не делает, если у кого-либо читающего это есть ответ.Спасибо!
ОБНОВЛЕНИЕ : проблема, которую имеет это решение, состоит в том, что любые VMs, которые совместно используют единственный сбой физического интерфейса, чтобы говорить друг с другом. То же верно для хоста, когда хост и VMs совместно используют тот же физический интерфейс.
я подозреваю, что это - самая проблема, которую образование моста, как предполагается, решает, но я мог действительно использовать некоторое руководство от кого-то с некоторым опытом с этим материалом.
Я потратил неделю на борьбу с этим и... это был Докер. Когда Docker работает, он помещает правила времени выполнения в сетевой фильтр с целью изоляции контейнеров Docker. Побочным эффектом этого является блокирование трафика к виртуальным машинам, подключенным мостом.
Я остановил и отключил Docker через systemctl, перезагрузил хост-систему, и все заработало.
Думаю, я установлю Docker на виртуальную машину с мостовым соединением, где он может быть королем сам по себе.