KVM QEMU VMs with static IP loose network connectivity
У меня есть KVM/QEMU установка с хостом и гостем (VM) под управлением Ubuntu 18.04 LTS с объединенной сетью. ВМ, настроенные со статическим IP, теряют сетевое соединение случайным образом (нет никакой закономерности). ВМ, настроенные с помощью DHCP, работают нормально.
Вот конфигурация сети хоста,
network:
version: 2
ethernets:
eno1:
dhcp4: no
dhcp6: no
eno4:
dhcp4: true
eno5np0:
dhcp4: true
eno6np1:
dhcp4: true
ens2f0np0:
dhcp4: true
ens2f1np1:
dhcp4: true
bridges:
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/24
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вот конфигурация сети vm (guest) со статическим IP,
network:
version: 2
ethernets:
ens3:
dhcp4: no
addresses:
- 10.2.0.210/23
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вот конфигурация сети vm (guest) с DHCP,
network:
version: 2
ethernets:
ens3:
dhcp4: true
VMs со статическим IP переходит в состояние простоя. Поэтому при попытке SSH или доступа к службам на ней, требуется время, затем она подключается,
$ nc -z -v -w5 10.2.0.210 22
nc: connect to 10.2.0.210 port 22 (tcp) timed out: Operation now in progress
Попробуйте еще раз, и все получится, потому что ВМ перешла из состояния простоя в рабочее состояние из-за первой попытки,
$nc -z -v -w5 10.2.0.210 22
Connection to 10.2.0.210 22 port [tcp/ssh] succeeded!
Нет проблем с ВМ, имеющими DHCP. Она подключается просто отлично в любое время,
$ nc -z -v -w5 10.2.0.184 22
Connection to 10.2.0.184 22 port [tcp/ssh] succeeded!
Я проверил следующие ссылки,
но это не помогло.
Какие-то проблемы в конфигурации KVM? Не только SSH, но и любые службы, открытые в виртуальных машинах, также недоступны. Я убедился, что ВМ находятся в запущенном состоянии при запросе virsh.
Я вижу одну довольно простую проблему в том, что ваш шлюз на br0 не входит в область действия адреса. Вы определяете / 24 вместо / 23.
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/**24**
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
Вам просто нужно изменить / 24 на / 23
10.2.0.92/23 будет включать 10.2.0.0 в 10.2.1.255, точно так же, как хосты в вашей виртуальной машине. Проблема не в перекрывающихся пробелах, а в том, что с / 24 шлюз хостов не доступен хосту.
Если вы должны были пинговать с гостя -> хост ... Пакет покинет гостя и получит широковещательную рассылку, потому что хост находится в пределах NETMASK для текущей сети гостя. Хост получит пакет. Хост отправит ответ. Поскольку пункт назначения x.x.1.x не находится в текущей сети x.x.0.x, пакет обычно направляется на шлюз. Ой, подождите, шлюза тоже нет на x.x.0.x. Пакет никуда не денется.
Помните, что пакеты неумные. Они идут только туда, куда вы им говорите.
Часть этого, о которой я не говорил выше, - это ARP. Приведенный выше комментарий @ Gerrit также касается этого. Когда пакеты отправляются в домене коллизии, они перемещаются по MAC-адресу, а не по IP. Когда 10.2.0.210/23 отправляет пакет на 10.2.0.92, исходящие пакеты отправляются непосредственно на 10.2.0.92 после того, как 10.2.0.210/23 отправляет широковещательный пакет с вопросом, кто такой 10.2.0.92. Я не уверен, получит ли гость ответ или нет. Это может быть, поскольку ARP отвечает на MAC-адрес запрашивающей стороны. Гость добавит эту информацию в свою собственную таблицу ARP.
Хост, хотя в ответе не будет иметь MAC-адрес гостя, потому что для хоста гость находится за пределами его домена коллизии / 24. Обычно для маршрутизации он идет на шлюз, но он не может этого сделать, потому что шлюз HOST также не находится в локальной сети. Шлюзы, являющиеся маршрутизаторами, не могут направлять пакеты обратно по проводу, по которому они поступают. Пакет должен пройти через устройство. Вероятно, его бы уронили, если бы он добрался до шлюза.
Что мне интереснее, так это то, что иногда это срабатывает. Сетевая маска, широковещательная рассылка и конфликтные домены влияют только на отправителя пакетов, а не на их получателей. Возможно, потому что Гость - это виртуальная вещь на хосте, некоторые пакеты проходят через виртуальный коммутатор и видны.