​ Как перенести виртуальную машину KVM на другой сервер: полное руководство по миграции

Введение

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

KVM (Kernel-based Virtual Machine) — это мощный гипервизор с открытым исходным кодом, встроенный непосредственно в ядро Linux. Однако в отличие от VMware vSphere с его интуитивным мастером vMotion, в «чистом» KVM отсутствует встроенная графическая консоль для миграции. Администраторам чаще всего приходится работать с командной строкой или использовать сторонние решения для безопасного перемещения виртуальных машин.

В этом руководстве вы найдёте всё необходимое для успешного переноса KVM: от подготовки и четырёх практических методов миграции до конвертации виртуальных машин из VMware в KVM, типичных ошибок и инструментов для автоматизации.

 Что такое миграция виртуальной машины KVM

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

 Миграция может потребоваться в различных ситуациях:

• плановое техническое обслуживание или апгрейд серверного оборудования;

• перераспределение нагрузки между физическими хостами;

• предотвращение аварий и повышение отказоустойчивости;

• консолидация или расширение виртуальной инфраструктуры.

 Живая миграция (Live Migration)

Живая миграция — это перенос работающей виртуальной машины с одного хоста на другой. Состояние памяти и устройств ВМ передаётся на приёмник, пока гостевая операционная система продолжает функционировать. Финальное переключение занимает доли секунды и практически незаметно для пользователей.

 Преимущества:

• нулевой или минимальный простой сервисов;

• подходит для критичных производственных сред;

• не требует остановки приложений.

Требования:

•  общее хранилище (NFS, Ceph, GlusterFS) или использование блочной миграции;

• совместимость процессоров на хостах;

• стабильное сетевое соединение с достаточной пропускной способностью.

 Холодная миграция (Cold Migration)

 Холодная миграция выполняется после полного выключения виртуальной машины. Процесс сводится к копированию дискового образа и XML-конфигурации на новый хост с последующим запуском ВМ.

 Преимущества:

• проще в реализации — не требует общего хранилища;

• меньше требований к совместимости оборудования;

•  ниже риск ошибок при переносе.

 Недостатки:

• требует остановки сервиса на время миграции;

• чем больше диск, тем дольше копирование.

Подготовка перед переносом виртуальной машины KVM

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

  Проверка совместимости процессоров

 Процессор на целевом сервере должен поддерживать те же наборы инструкций, которые ожидает виртуальная машина. Если вы используете прямой проброс процессора (passthrough) или фиксированную модель, на приёмнике может не оказаться нужных функций.

 Рекомендация:используйте в конфигурации ВМ режим  host-model. Он позволяет libvirt автоматически выбрать совместимую модель процессора, что повышает вероятность успешного переноса между разными хостами.

<cpu mode='host-model' check='partial'/>

Как проверить совместимость:

 virsh cpu-compare /etc/libvirt/qemu/your_vm.xml

Если вы видите сообщение о несовместимости, измените модель CPU на более универсальную, например  host-model, или выберите виртуальную модель, поддерживаемую на обоих серверах.

 Проверка версий QEMU и libvirt

 Разные версии QEMU и libvirt могут иметь незначительные различия в протоколах миграции и поддерживаемых функциях. Безопаснее всего запускать  одну и ту же мажорную версию на обоих хостах или убедиться, что версия на приёмнике не старше, чем на источнике.

qemu-system-x86_64 --version
libvirtd --version

 Если версии различаются, протестируйте миграцию в тестовой среде перед переносом боевых ВМ.

 Настройка хранилища

 Вариант 1. Общее хранилище (NFS, Ceph, GlusterFS)

 Смонтируйте общее хранилище на обоих серверах по одному и тому же пути. Это позволяет выполнять живую миграцию без копирования дисковых данных — передаётся только состояние памяти.

 Вариант 2. Локальное хранилище

 Если общего хранилища нет, путь к каталогу с дисками должен существовать на целевом сервере, а сам файл диска необходимо скопировать заранее (для холодной миграции) или в процессе блочной миграции.

 Убедитесь, что на целевом сервере есть достаточно свободного места для размещения копии диска.

 Проверка сети

•  На целевом сервере должен существовать тот же виртуальный сетевой мост, что и на источнике (например,  br0, virbr0). Если мосты отличаются, после миграции ВМ может потерять сетевую доступность.

•  Для живой миграции настоятельно рекомендуется выделить отдельный сетевой интерфейс — это позволит избежать перегрузки управляющей или рабочей сети.

•   Настройте вход по SSH без пароля от источника к приёмнику:

ssh-copy-id root@destination_server_ip

  Создание резервной копии перед миграцией

 Никогда не пренебрегайте резервным копированием. Даже при простой миграции всегда существует риск повреждения данных. Сделайте снимок состояния ВМ или полную копию диска и XML-конфигурации.

•  Для быстрого снимка используйте: virsh snapshot-create-as vm_name

• Для полноценного резервного копирования с согласованностью данных приложений используйте специализированные решения, например  Vinchin Backup & Recovery

 Способы миграции виртуальной машины KVM на другой сервер

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

Способ 1. Холодная миграция через virsh

 Этот метод максимально прост и не требует общего хранилища или идентичных процессоров. Подходит для переноса одной-двух ВМ в среде, где допустим простой.

 Шаг 1 :Посмотрите список доступных ВМ:

virsh list --all

Шаг 2 : Корректно выключите виртуальную машину:

virsh shutdown vm_name
virsh domstate vm_name

Шаг 3 :Сохраните XML-конфигурацию ВМ в файл:

virsh dumpxml vm_name > /root/vm_name.xml

Шаг 4 :Скопируйте XML-файл на целевой сервер:

scp /root/vm_name.xml root@destination_ip:/etc/libvirt/qemu/

Шаг 5 :Узнайте путь к дисковому образу:

virsh domblklist vm_name

Шаг 6 – Скопируйте образ диска на целевой сервер (в тот же абсолютный путь):

scp /var/lib/libvirt/images/vm_name.qcow2 root@destination_ip:/var/lib/libvirt/images/

Если путь на целевом сервере отличается, после копирования отредактируйте XML с помощью virsh edit vm_name и укажите правильный путь в секции  <source>.

 Шаг 7 : Зарегистрируйте ВМ на целевом сервере:

virsh define /etc/libvirt/qemu/vm_name.xml

Шаг 8 – Запустите ВМ и убедитесь, что она работает:

virsh start vm_name
virsh list

 Способ 2. Живая миграция (Live Migration) через virsh

 Живая миграция позволяет перенести работающую ВМ с минимальным простоем. Для этого требуется общее хранилище (либо используется блочная миграция) и совместимость процессоров.

 Предварительные требования:

•  общее хранилище смонтировано на обоих серверах по одному пути;

• настроен вход по SSH без пароля;

• проверена совместимость CPU;

• открыты порты, используемые службой миграции QEMU (зависит от конфигурации libvirt).

 Базовая команда для живой миграции:

virsh migrate --live --verbose --undefinesource --persistent \
vm_name qemu+ssh://destination_server/system

Что означают опции:

Если вы используете выделенную сеть для миграции:

virsh migrate --live --verbose --migrateuri tcp://destination_migration_ip \
vm_name qemu+ssh://destination_server/system

Как отслеживать прогресс: во время миграции на сервере-источнике можно использовать команду:

virsh domjobinfo vm_name

Способ 3. Миграция без общего хранилища (блочная миграция)

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

 Вариант A — скопировать весь диск во время живой миграции:

virsh migrate --live --copy-storage-all --verbose \
vm_name qemu+ssh://destination_server/system

Вариант B — инкрементальное копирование (быстрее для больших дисков):

virsh migrate --live --copy-storage-inc --verbose \
vm_name qemu+ssh://destination_server/system

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

  На сетях с пропускной способностью 1 Гбит/с блочная миграция больших дисков может занимать много времени. Если возможно, используйте более быстрые каналы или рассмотрите сжатие трафика (опция  --compressed при поддержке).

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

 Многие организации рассматривают переход с VMware на KVM для снижения затрат на лицензирование. В этом разделе мы расскажем, как перенести существующую ВМ VMware (в формате VMDK) в среду KVM.

 Конвертация VMDK в QCOW2

 KVM работает с дисковым форматом QCOW2 «из коробки». Этот формат поддерживает тонкое выделение места, снимки состояния и сжатие. В VMware по умолчанию используется формат VMDK.

 Шаг 1 – Скопируйте файл VMDK с хоста VMware на сервер Linux.

 Используйте  scp, rsync  или экспортируйте ВМ через vCenter.

 Шаг 2 – Преобразуйте диск с помощью утилиты  qemu-img :

qemu-img convert -f vmdk -O qcow2 source.vmdk migrated_disk.qcow2

 Чтобы видеть прогресс, добавьте опцию  -p:

qemu-img convert -p -f vmdk -O qcow2 source.vmdk migrated_disk.qcow2

При необходимости можно изменить размер диска во время конвертации:

qemu-img convert -O qcow2 source.vmdk new_disk.qcow2 -o preallocation=metadata

Настройка виртуальной машины в KVM

 После конвертации создайте новое определение ВМ с указанием на преобразованный диск.

 Пример минимального XML-файла для ВМ:

<domain type='kvm'>
  <name>migrated_vm</name>
  <memory unit='MiB'>4096</memory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-7.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <devices>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/migrated_disk.qcow2'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>
    <graphics type='vnc' port='-1' autoport='yes'/>
  </devices>
</domain>

Зарегистрируйте и запустите ВМ:

virsh define /path/to/vm.xml
virsh start migrated_vm

 Установка драйверов VirtIO для Windows

 Виртуальные машины Windows, работавшие на VMware, использовали SCSI или IDE-контроллеры. При загрузке на KVM с дисками VirtIO (для лучшей производительности) Windows может не увидеть диск.

 Решение:

• Временно подключите к ВМ дополнительный диск с  bus='ide'.

• Загрузитесь с этого диска и установите гостевые драйверы VirtIO (их можно скачать из ISO-образа от проекта Fedora).

• После установки драйверов переключите основной диск на VirtIO.

Альтернативный вариант — на KVM использовать  bus='sata' или `bus='ide', чтобы избежать проблем с драйверами, но это снизит производительность дисковых операций.

 Для гостевых систем Linux драйверы VirtIO встроены в ядро (начиная с версии 2.6.25) и работают без дополнительных действий.

 Типичные проблемы при миграции KVM и их решения

Ручная миграция или специализированный инструмент

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

Когда подойдёт ручная миграция:

• вы управляете небольшой средой (до 20 ВМ);

• у вас идентичные серверы и общее хранилище;

• у вас есть опытный администратор Linux;

• бюджет ограничен.

 Когда лучше рассмотреть корпоративный инструмент:

• требуется перенос между разными гипервизорами (VMware → KVM или обратно);

• в вашей инфраструктуре сотни ВМ;

• для критичных приложений нужен минимальный простой;

• требуются аудиторские следы и отчётность;

• вы хотите исключить ошибки ручного администрирования.

Для компаний, которые выполняют миграцию десятков или сотен виртуальных машин, ручной перенос через virsh становится трудоёмким и повышает риск ошибок. Vinchin Backup &  Recovery позволяет централизовать управление миграцией, выполнять V2V-конвертацию и переносить виртуальные машины между различными гипервизорами без ручного копирования дисков. Кроме того, решение обеспечивает автоматический откат при сбоях и встроенное планирование — это особенно важно, когда речь идёт о поддержании непрерывности бизнес-процессов.

  Часто задаваемые вопросы

 Вопрос 1. Можно ли перенести работающую ВМ KVM без общего хранилища?

 Да. Используйте блочную миграцию с опциями  --copy-storage-all  или  --copy-storage-inc. Данные диска будут копироваться по сети в процессе живой миграции.

 Вопрос 2. В чём главное различие между живой и холодной миграцией?

 При живой миграции ВМ остаётся включённой, переключение происходит с минимальной паузой. При холодной — ВМ полностью выключается перед переносом.

 Вопрос 3. Как перенести виртуальную машину из Proxmox в KVM?

 В Proxmox используется тот же гипервизор KVM, поэтому достаточно экспортировать конфигурацию ВМ и скопировать диск. Можно использовать встроенные средства Proxmox или инструменты V2V-конвертации.

 Вопрос 4. Чем заменить VMware на KVM?

 KVM — это полноценная open-source альтернатива VMware, которая работает на любом современном дистрибутиве Linux. Для миграции из VMware в KVM преобразуйте VMDK в QCOW2, как описано выше, и настройте сеть и драйверы. Для управления большим количеством ВМ можно использовать oVirt, Proxmox VE или OpenStack.

 Вопрос 5. Как перенести ВМ между серверами с разными процессорами (AMD и Intel)?

 Технически это возможно, но не рекомендуется из-за различий в наборах инструкций. Если перенос необходим, установите в конфигурации ВМ режим CPU `host-model` и обязательно протестируйте в тестовой среде.

 Вопрос 6. Сколько времени занимает живая миграция?

 Время зависит от объёма оперативной памяти, интенсивности её изменения, пропускной способности сети и типа хранилища. Для обычной ВМ с 8 ГБ RAM по сети 10 Гбит/с миграция обычно занимает 10–30 секунд. Крупные ВМ с активными приложениями могут мигрировать несколько минут.

 Вопрос 7. Что делать, если миграция прервалась?

 В большинстве случаев ВМ остаётся работать на источнике без потерь. Проверьте логи (`/var/log/libvirt/qemu/vm_name.log`), устраните проблему и повторите попытку. Всегда делайте резервную копию перед началом миграции.

 Вопрос 8. Можно ли автоматизировать миграцию нескольких ВМ? 

Да. Вы можете написать shell-скрипт с перебором списка ВМ или использовать корпоративные решения, такие как Vinchin, которые поддерживают пакетную миграцию с единым интерфейсом управления.

 Заключение

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

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