Прямая или почти прямая миграция KVM с LVM на серверную часть файловой системы

На моей гостевой машине 2 раздела (80 ГБ + 1 ТБ). Оба они находятся на LVM. Я хочу перенести все диски на другую машину с минимальным временем простоя. Перенёс другую машину с nc. Это занимает 4 дня, и во время передачи моя виртуальная машина была отключена.

Я попытался сделать снимок после переноса грязных страниц. Но AFAIK с LVM это невозможно. Моя целевая машина не имеет установки LVM и свободного неразделенного пространства. Поэтому на дисках целевой машины должны быть необработанные образы файлов.

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg-datastore/lv-vm-1138'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg-datastore-sata/lv-vm-1138-2'/>
  <target dev='vdb' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</disk>

Исходный хост:

  • ЦП: Intel (R) Xeon (R) ЦП D-1520 @ 2,20 ГГц
  • ОС: 16.04.1 LTS
  • Ядро : 4.2.0-34-generic
  • qemu-kvm: 1: 2.3 + dfsg-5ubuntu9.2
  • QEMU: 2.3.0
  • libvirt: 1.2.16

Целевой хост:

  • ЦП : Intel (R) Xeon (R) CPU D-1520 @ 2,20 ГГц
  • ОС: 16.04 LTS
  • Ядро: 4.4.0-28-generic
  • qemu-kvm: 1: 2.5 + dfsg-5ubuntu10. 2
  • QEMU: 2.5.0
  • libvirt: 1.3.1
4
задан 31 December 2016 в 19:37
1 ответ

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

Команда для выполнения реального переноса + копирование хранилища есть:

virsh migrate  --live --copy-storage-all --persistent qemu+ssh://root@/system

Эта команда предполагает, что у вас есть действительное соединение на основе libvirt с удаленным узлом.

Если у вас возникли проблемы с переносом виртуальных дисков, вы можете попробовать создать загрузочные файлы виртуального диска с выполнением (на целевом узле) чего-то похожего на fallocate /dev/vg-datastore/lv-vm-1138 -l 80G и /dev/vg-datastore-sata/lv-vm-1138-2 -l 1T.

В любом случае, из-за различий между хостами, это может быть ухабистой дорогой.

Проще мигрировать образы ВМ, используя blockync, можно использовать инкрементальный подход к копированию диска. Короче говоря:

  • когда ВМ запущена, сделайте первую копию виртуальных дисков на целевой хост. Эта первая копия будет некогерентной и ненадежной, но будет работать как "семена" для следующей копии;
  • в соответствующее время выключите ВМ и выполните вторую копию виртуальных дисков. Эта вторая копия будет передавать только измененные блоки и будет намного быстрее, чем первая;
  • по окончании определите виртуальный домен и запустите ВМ на целевом хосте.

Пожалуйста, обратите внимание, что связанная программа blocksync является персональной вилочной версией, основанной на этом оригинальном скрипте (который, кстати, является улучшенной версией этого скрипта )). Очевидно, что я предполагаю NO RESPONSIBILITY для данного кода и настоятельно рекомендую тщательно протестировать его перед использованием на производственных виртуальных машинах/дисковых файлах. Как всегда, вы ДОЛЖНЫ иметь подтвержденную резервную копию перед тем, как что-либо делать.

EDIT:, как предложено в комментарии ниже, еще одним замечательным программным обеспечением для синхронизации блочного устройства/файла виртуального образа является bdsync. Подход в основном тот же самый: взять первую "посылочную" копию дискового файла во время работы ВМ, затем остановить ВМ и сделать еще одну финальную копию. В прошлом я даже задавал разработчику bdsync похожий вопрос; смотрите здесь для дополнительной информации .

.
7
ответ дан 3 December 2019 в 02:56

Теги

Похожие вопросы