KVM live migration без shared storage: настраиваем через NBD на CentOS 7

После перехода на CentOS 7 у одного из клиентов встал вопрос: есть два физических хоста с KVM, нет shared storage, и нужна возможность перекидывать виртуалки между ними без остановки. Не потому что очень нужно прямо сейчас - а потому что хочется понять, работает ли это вообще на RHEL/CentOS 7 без NetApp и FC под ногами.

Потратили день на настройку и несколько часов на разбор того, почему не работало. Получилось - но с нюансами, о которых в документации написано мелко.

Зачем NBD и что это такое

Live migration в KVM может работать двумя способами. Первый - shared storage: оба хоста видят одно и то же хранилище (NFS, iSCSI, FC), диск ВМ не переезжает, переезжает только RAM и состояние CPU. Быстро, элегантно, требует шаред-стораджа.

Второй способ - без shared storage, через NBD (Network Block Device): диск ВМ копируется между хостами по сети прямо в процессе миграции. Медленнее, потребляет полосу, но при этом требует только сеть между хостами. Нам подходил второй вариант.

В libvirt этот режим называется --copy-storage-all при вызове virsh migrate. KVM копирует диск блоками, одновременно реплицируя изменения - примерно как rsync в --inplace с постоянно работающим сервисом сверху.

Первая проблема: CPU feature flags

Запустили миграцию. Ошибка:

error: unable to migrate guest: unsupported configuration: guest and host CPU are not compatible

Хосты куплены в разное время - разные процессоры. Один Intel Xeon E5-2620, второй E5-2650. Архитектурно оба Sandy Bridge-EP, но наборы feature flags отличаются. KVM по умолчанию передаёт ВМ реальные флаги хоста через cpu mode=host-passthrough. При миграции целевой хост видит ВМ с флагами источника и говорит: я так не умею.

Решение - переключить тип CPU в XML виртуалки на cpu mode='custom' и указать базовую модель, поддерживаемую обоими хостами. Смотрели через virsh capabilities на каждом хосте, находили пересечение. В нашем случае подошёл Westmere - консервативно, зато миграция прошла.

Важный момент: менять cpu mode можно только на остановленной ВМ. Если ВМ уже живёт с host-passthrough и внутри неё что-то опирается на конкретные CPU-расширения (AVX, AES-NI и подобное), придётся думать аккуратнее. У нас внутри жил типовой веб-сервер, ему было всё равно.

Вторая проблема: libvirtd и удалённые подключения

Для live migration libvirtd на обоих хостах должен принимать удалённые подключения. По умолчанию на CentOS 7 libvirtd слушает только Unix-сокет. Для миграции нужен TCP.

В /etc/libvirt/libvirtd.conf нужно раскомментировать:

listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
auth_tcp = "none"

И добавить -l (listen) в параметры запуска демона - в /etc/sysconfig/libvirtd:

LIBVIRTD_ARGS="--listen"

auth_tcp = "none" - это отключение аутентификации. В изолированной сети между двумя хостами терпимо, но надо понимать что делаешь. В идеале - SASL или TLS с сертификатами, но это отдельная история. У клиента хосты в отдельном management-VLAN без выхода наружу, решили что достаточно.

После изменений - systemctl restart libvirtd и проверка, что порт 16509 слушается: ss -tlnp | grep 16509. Firewall тоже надо проверить: firewall-cmd --add-port=16509/tcp.

Как выглядит миграция

Команда для live migration с копированием дисков:

virsh migrate --live --copy-storage-all \
  --verbose vm-name \
  qemu+tcp://host2/system

--verbose добавили чтобы видеть прогресс - без него команда просто молчит несколько минут. На ВМ с диском в 20 ГБ и загрузкой копирование заняло около 10 минут по гигабитной сети. ВМ при этом продолжала работать, пинг не прерывался.

После успешного завершения ВМ работает на втором хосте. На первом запись о ней остаётся в virsh list --all как остановленная с пустым диском - надо руками убрать через virsh undefine и удалить образ. Это немного неряшливо, но так работает libvirt без vCenter под управлением.

Что в итоге

Live migration через NBD на CentOS 7 с KVM работает. Два реальных камня:

• CPU compatibility. Если хосты разные - проверить пересечение feature flags заранее, до того как ВМ запущена с host-passthrough. Исправить это потом дороже.
• libvirtd listen mode. По умолчанию выключен, включается в конфиге и параметрах запуска - в двух местах одновременно, и про второе место (LIBVIRTD_ARGS) документация упоминает не везде.

Shared storage это всё обходит - диск не переезжает, CPU flags не нужно выравнивать через custom-модель. Но shared storage стоит денег и требует отдельной инфраструктуры. Для небольшого клиента с двумя хостами и нежеланием поднимать NFS-сервер только ради миграции - NBD-подход вполне рабочий.

Насколько это подходит для регулярного использования как замена vMotion - вопрос открытый. Для плановых перемещений раз в неделю нормально. Для автоматического балансировки нагрузки, как в VMware DRS, этого мало. Но у нас сейчас и задачи такой нет.

Клиентам, которым мы ведём управляемую инфраструктуру на KVM, эту схему покажем как опцию при следующем плановом обсуждении конфигурации.