Онлайн миграция виртуальных машин и контейнеров Proxmox VE между узлами при помощи remote-migrate

Миграция виртуальных машин и контейнеров между узлами, не входящими в один кластер, достаточно часто встречающаяся задача. Наиболее простой способ - через выгрузку-загрузку резервной копии, но он может занять продолжительное время и не решает вопроса миграции с минимальным простоем. Начиная с Proxmox VE 7.3 мы можем использовать штатную утилиту remote-migrate, которая позволяет выполнить это задачу в кратчайшие сроки и даже поддерживает онлайн-миграцию. Подробнее в нашей статье.

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Сразу начнем с того, что утилита remote-migrate до сих пор является экспериментальной, а это значит, что не все возможности могут поддерживаться на текущий момент или в работе утилиты могут происходить ошибки. Поэтому используем ее на свой страх и риск.

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

Миграция виртуальных машин и контейнеров с ZFS-хранилища возможна только в ZFS-хранилище
Миграция дисков формата Qcow2 возможна только в хранилище с поддержкой данного формата
Версия QEMU принимающего узла должна быть не ниже версии отправляющего узла

Если обобщить, то самым универсальным для миграции форматом диска является RAW, который используется в том числе и для LVM-томов. Так как физически протестировать все варианты хранилищ у нас не было никакой возможности, то на практике вы можете столкнуться и с иными ограничениями. В этом случае вам следует выполнить конвертацию диска перенеся его в хранилище нужного типа. После этого не забудьте удалить старый диск, иначе миграция окончится неудачей.

Получение токена для аутентификации на узле-приемнике

Для подключения к узлу-приемнику нам понадобится токен, подключаемся в его консоль и выполняем там команду:

pveum user token add root@pam migration -privsep 0

С ее помощью мы получим для пользователся root токен с наименованием migration, обязательно сохраните полученную информацию, особенно значение поля value - это секретный ключ, повторно узнать его не получится.

Затем нам понадобится отпечаток (fingerprint) сертификата pve-ssl.pem, для этого выполните команду:

pvenode cert info

Нужная вам информация находится в одноименном поле.

Никаких дополнительных настроек узла приемника производить не нужно.

Миграция виртуальных машин

Теперь приступим непосредственно к миграции, для этого нам нужно знать идентификаторы (ID) нужных нам машин на узле-источнике и свободные идентификаторы на узле приемнике, а также наименование нужного хранилища узла-приемника и сетевого моста, к которому мы будем производить подключение сетевой карты виртуальной машины.

Команда миграции довольно сложная и длинная, поэтому, в целях улучшения ее восприятия мы ее упростим, используя переменные среды, это удобно, особенно если вы переносите сразу несколько машин или экспериментируете с миграцией. Добавим две временные переменные, они будут существовать до завершения текущего сеанса:

export APITOKEN='PVEAPIToken=root@pam!migration=9cc535ee-4dc5-4166-a433-6a4268d13fd0'
export FINGERPRINT='3B:E8:31:8F:4D:21:AC:9B:F6:7E:D6:C9:8F:E8:99:C7:37:84:4E:C6:5F:2F:5F:DC:AC:BB:2F:7B:0C:00:09:64'

В первой переменной мы указываем имя токена и секретный ключ для него, во второй - отпечаток сертификата. Глядя на длину строк, можно представить насколько мы только что сократили размер команд. Для самого переноса выполним:

qm remote-migrate 804 704 apitoken=${APITOKEN},host=192.168.3.76,fingerprint=${FINGERPRINT} --target-bridge vmbr0 --target-storage local-lvm

После самой команды мы указываем текущий идентификатор виртуальной машины на данном узле, желаемый идентификатор на узле приемнике, затем параметры подключения к узлу, включающие адрес хоста, токен и отпечаток сертификата, которые мы заменили переменными. Последние два параметра указывают сетевой мост и хранилище узла приемника. Для такого переноса виртуальная машина должна быть выключена.

Для онлайн переноса включенной машины добавьте к команде дополнительный ключ online:

qm remote-migrate 804 704 apitoken=${APITOKEN},host=192.168.3.76,fingerprint=${FINGERPRINT} --target-bridge vmbr0 --target-storage local-lvm --online

При онлайн миграции сначала будет скопировано хранилище, затем виртуальная машина будет поставлена на паузу и перенесено состояние памяти, после чего она будет запущена на новом узле. При этом само состояние машины сохраняется, а для внешних пользователей она не некоторое время становится недоступной, данное время зависит от размера занятой памяти и скорости передачи данных между узлами.

На узле источнике перенесенная машина будет заблокирована, чтобы избежать появления в сети клона мигрировавшей машины.

Миграция контейнеров

Миграция контейнеров в целом не отличается от миграции виртуальных машин, с одним только ограничением - онлайн миграция контейнеров на момент написания данной статьи не поддерживается. Поэтому переносим контейнер в выключенном состоянии:

pct remote-migrate 806 706 apitoken=${APITOKEN},host=192.168.3.76,fingerprint=${FINGERPRINT} --target-bridge vmbr0 --target-storage local-lvm

В остальном синтаксис команды повторяет такой же для виртуальных машин, и мы также используем переменные, поэтому не забудьте задать их заранее.

Если контейнер запущен, и вы не хотите выключать его руками, то используйте миграцию с перезагрузкой:

pct remote-migrate 806 706 apitoken=${APITOKEN},host=192.168.3.76,fingerprint=${FINGERPRINT} --target-bridge vmbr0 --target-storage local-lvm --restart

Ключ restart указывает выключить контейнер перед миграцией и включить его на узле приемнике после переноса. Как и виртуальная машина после миграции контейнер будет заблокирован.