10.06.2023 22:05
sokolov-denis 9 3000 Источник

Некоторое время назад потребовалось решить задачу по переносу виртуальных машин KVM с одного кластера Proxmox VE на другой с минимальным временем простоя. В PVE «из коробки» такой возможности нет, но, как оказалось, онлайн‑миграцию виртуальных машин между кластерами можно выполнить средствами KVM. Процедуру переноса я подробно опишу в этом руководстве.

Важные замечания

  1. Процедура протестирована для Proxmox VE 6.x

  2. На серверы кластера между которыми производится миграция должен быть настроен вход по SSH без пароля

Условные обозначения

  • pve-01 - сервер с которого будем выполнять миграцию

  • pve-02 - сервер на который будем выполнять миграции

  • 100 - исходный ID виртуальной машины

  • 120 - ID виртуальной машины после миграции

  • pc-i440fx-2.11 - чипсет виртуальной машины, в вашем случае может отличаться, ниже я покажу как определить

  • 192.168.0.3 - IP-адрес сервера на который будем мигрировать виртуальную машину

Процедура

  1. Зайдём по SSH на оба сервера

  2. На сервере pve-01 найдём чипсет который эмулируется для нашей виртуальной машины. В нашем случае это будет pc-i440fx-2.11

    cat << EOF | socat STDIO UNIX:/run/qemu-server/$SRCID.qmp | grep --color current
{ "execute": "qmp_capabilities" }
{ "execute": "query-commands" }
{ "execute": "query-machines" }
EOF

  3. Для удобства установим переменные окружения на обоих серверах

    SRCID=100
DSTID=120
CHIPSET=pc-i440fx-2.11
DSTIP=192.168.0.3
DSTPORT=60000

  4. Получим на сервере pve-01 команду запуска виртуальной машины

    ps ax | grep $SRCID

  5. Скопируем с pve-01 на pve-02 файл конфигурации виртуальной машины. После выполнения этого шага, в веб-интерфейсе PVE появится конфигурация виртуальной машины с ID $DSTID

    scp /etc/pve/local/qemu-server/$SRCID.conf $DSTIP:/etc/pve/local/qemu-server/$DSTID.conf

  6. В интерфейсе PVE сервера pve-02 из конфигурации виртуальной машины $DSTID удалим все диски (Hard Disk) и добавим заново такое же количество дисков такого же размера.

  7. В консоли сервера pve-02 запустим виртуальную машину $DSTID в режиме ожидания миграции. Для этого модифицируем строку запуска полученную на шаге 4:

    1. $SRCID заменить на $DSTID

    2. Удалить из строки ,x509 если есть

    3. Убедиться, что в строке запуска указан -machine type=$CHIPSET полученный на шаге 2

    4. Добавить -incoming tcp:$DSTIP:$DSTPORT -S

    /usr/bin/kvm -id $DSTID <остальные параметры> -incoming tcp:$DSTIP:$DSTPORT -S

  8. Запустим миграцию 

    qm monitor $SRCID
# Опционально можно ограничить скорость передачи данных
qm> migrate_set_speed 100M
qm> migrate -b tcp:$DSTIP:$DSTPORT

# Прогресс можно наблюдать командой
qm> info migrate

  9. Запустим qm monitor на сервере pve-02, чтобы отслеживать прогресс. Когда копирование данных завершится, исходная VM перейдёт в состояние VM status: paused (postmigrate)

    qm monitor $DSTID
qm> info status

VM status: paused (postmigrate)

  10. В qm monitor на сервере pve-02 запустим перенесённую виртуальную машину

    qm> c

  11. На сервере pve-01 остановим исходную виртуальную машину

    qm stop $SRCID

  12. Проверяем, что после миграции всё работает как ожидалось и удаляем исходную виртуальную машину

    qm destroy $SRCID

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

Замечания

  1. В Proxmox VE версии 7.3 появилась штатная возможность миграции виртуальных машин на другой кластер. Команда qm remote-migrate. Спасибо за уточнение пользователю @Gunslinger38

Комментарии (9)


  1. onegreyonewhite
    11.06.2023 01:33
    #25637314
    +5

    Если у proxmox подключён zfs на хранилище и zfs на backup server, то очень часто проще, предсказуемее и эффективнее сделать через backup/restore. Потому что в 99% случаев минимальные простои ни на что не влияют, кроме красивых 9 после запятой.

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

    Просто выглядит как заход с чёрного хода и начинаешь в такие моменты думать где потом сломается.


    1. sokolov-denis Автор
      11.06.2023 01:33
      #25637892
      +3

      Согласен, что если нет жестких требований по непрерывности сервиса, то мигрировать проще, через backup/restore.

      Правильно ли я понял, что структуру хранилищ на конечном кластере можно
      тоже безопасно изменить, подключив, например, диски к разным хранилищам?

      Да, мы мигрировали на кластер с отдельным хранилищем.


      1. werter_l
        11.06.2023 01:33
        #25645442

        А zfs replication не про тоже самое?

        https://pve.proxmox.com/wiki/Storage_Replication


        1. sokolov-denis Автор
          11.06.2023 01:33
          #25645708

          Не, статья про то как мигрировать VM без даунтайма (почти) на другой кластер. В рамках одного кластера миграция работает без Storage Replication.


  1. Gunslinger38
    11.06.2023 01:33
    #25637894
    +6

    В актуальной ветке (начиная с 7.3) задача решается штатными средствами:

    Hidden text
    root@pve1:~# qm help remote-migrate
USAGE: qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <string> --target-storage <string> [OPTIONS]

  Migrate virtual machine to a remote cluster. Creates a new migration
  task. EXPERIMENTAL feature!

  <vmid>     <integer> (1 - N)

             The (unique) ID of the VM.

  <target-vmid> <integer> (1 - N)

             The (unique) ID of the VM.

  <target-endpoint> apitoken=<A full Proxmox API token including the secret
             value.> ,host=<Remote Proxmox hostname or IP>
             [,fingerprint=<Remote host's certificate fingerprint, if not
             trusted by system store.>] [,port=<integer>]

             Remote target endpoint

  -bwlimit   <integer> (0 - N)   (default=migrate limit from datacenter or
             storage config)

             Override I/O bandwidth limit (in KiB/s).

  -delete    <boolean>   (default=0)

             Delete the original VM and related data after successful
             migration. By default the original VM is kept on the source
             cluster in a stopped state.

  -online    <boolean>

             Use online/live migration if VM is running. Ignored if VM is
             stopped.

  -target-bridge <string>

             Mapping from source to target bridges. Providing only a single
             bridge ID maps all source bridges to that bridge. Providing
             the special value '1' will map each source bridge to itself.

  -target-storage <string>

             Mapping from source to target storages. Providing only a
             single storage ID maps all source storages to that storage.
             Providing the special value '1' will map each source storage
             to itself.


    1. sokolov-denis Автор
      11.06.2023 01:33
      #25637906

      Здорово! Я ожидал, что рано или поздно они это реализуют. Даже странно, что сделали только в 7.3. Работая над задачей я подсматривал в скрипты миграции PVE и удивлялся почему до сих пор не сделана внешняя миграция, т.к. доработки там нужны были не очень большие.


  1. werter_l
    11.06.2023 01:33
    #25645362

    Спасибо. Оч. не хватало этого механизма на pve.

    Интересно, когда это в веб добавят?

    Кстати, 8-ка "забэтилась" https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.0_beta1

    Ps. Цикл заметок по proxmox, ceph, zfs, pfsense https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/

    Может кому чего и пригодится )


  1. werter_l
    11.06.2023 01:33
    #25645392

    >qm stop $SRCID

    Может все же 'qm shutdown' ? Stop уж слишком жестко.


    1. sokolov-denis Автор
      11.06.2023 01:33
      #25645632

      Неважно, потому что следом мы её всё равно удаляем qm destroy $SRCID.