Назад | Перейти на главную страницу

Гости macvtap libvirt не имеют сетевого подключения после миграции сервера

У меня есть два выделенных сервера, принадлежащих OVH, SP-128 и MG-512. Аппаратное обеспечение аналогично (обе сборки основаны на Supermicro), но SP-128 имеет мост Xeon E5 Ivy и Ethernet 1 Гбит / с; MG-512 имеет два процессора Xeon E5 Haswell и Ethernet 10 Гбит / с.

Я занимаюсь переносом всего со старого сервера (SP-128) на новый (MG-512). Вот что я сделал до сих пор:

Настроить разделы на новом ящике
Скопировал данные и ОС (весь пул хранилищ ZFS, все включено) из старого в новый ящик, используя zfs send | ... ssh "zfs recv"
Переустановил GRUB
Новый сервер имеет новый общедоступный IP-адрес, поэтому я изменил его в /etc/network/interfaces, и у него новое «имя» для своего основного адаптера Ethernet, поэтому я обновил конфигурацию (старый: eno1; новый: enp3s0f0)
Я также обновил сетевой адаптер libvirt, macvtap0 (помечено macvtap-net в libvirt) заменяя eno1 с участием enp3s0f0 в конфигурации, и сделали virsh destroy macvtap-net; virsh start macvtap-net чтобы изменения вступили в силу.
Новый сервер загружается и доступен по сети.!

Теперь у меня есть несколько гостей LXD и libvirt / KVM. У каждого из них есть один или несколько статических IP-адресов, которые они запрашивают из одной из двух общедоступных / 27 подсетей, которые у меня есть. OVH перенес оба / 27 на мой новый сервер (по моей просьбе). Вот еще несколько деталей настройки сети:

Контейнеры LXD подключаются с помощью macvlan. Сеть работает. Все мои контейнеры LXD могут подключаться к общедоступному Интернету (и быть доступным).
Гости KVM подключаются с помощью macvtap. Сеть не работает.
Шлюз по умолчанию и подсеть, используемые гостевыми LXD и KVM, абсолютно одинаковы; Единственное, что отличается, - это MAC-адрес, используемый каждым гостем / контейнером, и конкретный IP-адрес в / 27. Я не менял конфигурацию IP гостя, потому что менять ее не нужно.

Моя проблема заключается в следующем: сеть для гостей KVM не работает. Под "не работает" я имею в виду, что гости могут устанавливать статический IP как и раньше, но они полностью недоступны. Гости не могут пинговать свой шлюз по умолчанию или любой другой IP, публичный или частный.

У меня одновременно работают старый и новый сервер, поэтому я достаточно тщательно проверил, одинакова ли конфигурация между ними. Например, старый сервер не включить неразборчивый режим ни для основного адаптера Ethernet, ни для macvtap0. Новый сервер тоже.

Большинство других настроек не мог измениться, потому что файлы, составляющие конфигурацию ОС, бит за битом копируются со старого сервера на новый. Например, конфигурация libvirt / KVM не была изменена или воссоздана между серверами; это буквально такая же конфигурация копируется как часть передачи данных на уровне файловой системы с помощью zfs send / zfs recv.

Итак, как я вижу, здесь задействованы следующие переменные:

«Основной» общедоступный IPv4-адрес самого физического сервера изменился со старого на новый сервер.
Модель адаптера Ethernet изменилась с Intel Gigabit Ethernet на 10G.
В название адаптера Ethernet изменено, с eno1 к enp3s0f0.
Шлюз по умолчанию для физической коробки изменилось, но шлюз по умолчанию для / 27 по-прежнему маршрутизируемый и пригодный (он работает в LXD с macvlan).

Я трижды проверил правильность MAC-адресов адаптеров virtio-net KVM, потому что OVH выполняет фильтрацию MAC-адресов (в основном для предотвращения случайной неправильной конфигурации, а не в качестве меры безопасности) и назначил определенный MAC-адрес каждому IP-адресу. м с помощью.

Так что я в растерянности. Почему мои гости KVM (у меня один Linux и один Windows) не могут получить доступ к сети на новом компьютере, когда в основном все то же самое, и единственные вещи, которые были законными изменениями, уже были изменены?

ой, и я также изменил сетевой адаптер в каждом из libvirt гостевой config (и перезагрузил гостей). Вот как это выглядит сейчас:

<interface type='direct'>
      <mac address='re:da:ct:ed'/>
      <source dev='enp3s0f0' mode='bridge'/>
      <target dev='macvtap0'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>

Уведомление enp3s0f0 тоже там (раньше был eno1).

Вот некоторые дополнительные способы устранения неполадок:

ip -d link macvtap0 show на новой коробке:

18: macvtap0@enp3s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 500
    link/ether re:da:ct:ed brd ff:ff:ff:ff:ff:ff promiscuity 0
    macvtap mode bridge addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

На старом ящике результат на 100% идентичен, за исключением замены enp3s0f0 с участием eno1.

Я решил эту проблему, выполнив этот процесс устранения неполадок:

Я попробовал MAC-адрес и адаптер macvtap с виртуальной машины Windows, которая не работала, с одной из моих новых виртуальных машин Ubuntu 18.04. Это сработало. Какого черта? А сейчас некоторые Гости KVM работают с macvtap, а другие - нет?
Я провел построчное сравнение моей (рабочей) виртуальной машины Ubuntu и XML-файла виртуальной машины Windows 2k16 в libvirt (virsh edit xxx), чтобы выяснить, в чем может быть разница.
Основное различие, которое я заметил, заключалось в следующем:

Ubuntu 18.04 (работает с macvtap):

<type arch='x86_64' machine='pc-i440fx-bionic'>hvm</type>

<type arch='x86_64' machine='pc-i440fx-yakkety'>hvm</type>

Зная названия выпусков Ubuntu, я вспомнил, что Yakkety старше Bionic. Итак, исходя из идей, я произвольно решил «обновить» тип машины виртуальной машины Windows до бионического и переключил виртуальную машину Ubuntu обратно на NAT (общедоступный IP-адрес не нужен).

Это сработало!

Итак, извлеченный здесь урок ужасно ясен. Часто обновляйте типы KVM-машин, особенно с новым выпуском ОС или даже с обновлением оборудования. В этом случае yakkety тип машины работал с оборудованием Ivy Bridge и адаптером Ethernet 1 Гбит / с, но bionic тип машины требовался для работы с физическим процессором Haswell и ixgbe (10 Гбит / с) физическая сетевая карта.

Кстати, я ранее пробовал эмулировать адаптер e1000 в гостевой системе, и это не устранило проблему, так что это был не virtio как таковой. Это было где-то глубоко в недрах уровня трансляции между физическим оборудованием и гостем.