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

27 октября 2022 г.

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

Рассказываем, как подготовиться и провести миграцию между платформами без боли и нежелательных последствий, а также покажем сценарии переноса ВМ между платформами для операционных систем (ОС) Linux и Windows.

Когда может понадобиться миграция ВМ

Причин для переноса ВМ на новое решение может быть много. Вот основные:

плановое обслуживание сервера — когда важно, чтобы ВМ оставалась доступной даже в период сервисных работ;
обновление ИТ-инфраструктуры — чтобы запустить виртуальные машины на более мощных и современных серверах;
смена вендора — чтобы перейти на новую площадку от поставщика услуг, работа с которым не устраивает или не может быть продолжена из-за разных причин.

Как подготовиться к миграции ВМ

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

1. Планирование

Миграция невозможна без тщательной проработки — нужен четкий план, в котором надо отразить:

актуальное состояние ВМ;
параметры текущей площадки и платформы, на которую планируется перенос;
последовательность миграции;
дедлайны по проекту в целом и по каждому этапу в отдельности;
варианты реагирования на инциденты.

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

2. Подготовка скриптов

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

3. Выгрузка образа системы

Следующий шаг — выгрузить образ виртуальной машины с текущей платформы. Варианты выгрузки могут быть разные: они зависят от платформы, на которой развернута ВМ.

4. Промежуточная конвертация

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

5. Загрузка

Образ в формате VMDK загружают на новую платформу виртуализации.

6. Запуск

ВМ запускается на новой платформе. При этом при миграции виртуальных машин с Hyper V или любых других поменяются сетевые адреса. То есть перед запуском нужно перенастроить DNS-записи и переключить нагрузку.

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

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

Рассмотрим миграцию на примере переноса виртуальных машин VMware в частное облако Private Cloud. Инструкцию разработал Роман Клименко, он помогает крупным клиентам VK Cloud с миграцией.

Сценарий миграции для операционных систем (ОС) семейства Linux

Перед миграцией ВМ проводим подготовку. Она нужна, чтобы обеспечить корректную работу виртуального сервера:

1. Проверяем, поддерживает ли ядро ОС драйвер virtio Для проверки запускаем команду:

grep -i virtio/boot/config-$(uname -r)

Проверяем, содержится ли драйвер virtio во временной файловой системе initramfs или initrd:

lsinitrd/boot/initramfs-$ (uname -r).img | grep virtio

Если initramfs содержит драйвер virtio_blk и зависимости virtio.ko, virtio_pci.ko и virtio_ring.ko — можно импортировать пользовательские образы в OpenStack.

Если initramfs не содержит драйвер virtio, перед импортом пользовательских образов в OpenStack надо восстановить временную файловую систему.

2. Восстанавливаем временную файловую систему Для ОС CentOS и подобных восстанавливаем файловую систему через команды:

CentOS/RedHat 5

 mkinitrd -f --allow-missing --with=xen-vbd --preload=xen-vbd --with=xen-platform-pci — preload=xen-platform-pci --with=virtio_blk --preload=virtio_blk --with=virtio_pci — preload=virtio_pci --with=virtio_console --preload=virtio_console

CentOS/RedHat 6/7

 mkinitrd -f --allow-missing --with=xen-blkfront --preload=xen-blkfront --with=virtio_blk --preload=virtio_blk --with=virtio_pci --preload=virtio_pci --with=virtio_console — preload=virtio_console /boot/initramfs-$(uname -r).img $(uname -r)

3. Устанавливаем QEMU Guest Agent и Cloud-init

yum install -y qemu-guest-agent cloud-init && systemctl enable --now qemu-guest-agent

4. Удаляем vmware tools

/usr/bin/vmware-uninstall-tools.pl

5. Останавливаем ВМ и экспортируем ее как шаблон в формате OVF Начало экспорта ВМ из VMware:

После завершения экспорта скачиваем файл с расширением .vmdk.

6. Копируем VMDK-диск на хост с openstack-client Копируем файл с расширением .vmdk на любой узел с OpenStack CLI или kollaansible.

7. Конвертируем VMDK-файл в формат RAW Для конвертации .vmdk в RAW используем команду:

qemu-img convert -f vmdk -O raw migrate-vm-to-openstack-wv-1.vmdk migrate-vm-toopenstack-wv-1.raw

8. Импортируем VMDK-диск через openstack-client в хранилище образов

openstack image create --private --container-format bare --disk-format vmdk --file <ИМЯ_ФАЙЛА.vmdk> --property hw_qemu_guest_agent=yes --property os_require_quiesce=yes <ИМЯ_ОБРАЗА>

9. Проверяем, загружен ли образ Заходим в личный кабинет (портал самообслуживания) частного облака Private Cloud, переходим в раздел «Облачные вычисления» на страницу «Образы». Проверяем соответствие названия и ID загруженному образу.

10. Создаем ВМ на основе загруженного образа Через портал самообслуживания создаем ВМ на основе загруженного образа. Устанавливаем размер диска не меньше того, что был указан при создании ВМ на VMware или другой платформе виртуализации. Проверяем размер диска.

После создания ВМ проверяем, что она запустилась и работает.

Сценарий миграции для ОС семейства Windows

1. Удаляем vmware tools и устанавливаем Cloudbase-init Если vmware-tools установлен, удаляем его. По ссылке и устанавливаем его через стандартный инсталлятор.

2. Останавливаем ВМ и экспортируем ее как шаблон в формате OVF После завершения экспорта скачиваем файл с расширением .vmdk.

3. Копируем VMDK-диск на хост с установленным openstack-client Копируем файл с расширением .vmdk на любой узел с OpenStack CLI или kollaansible.

4. Конвертируем VMDK-файл в формат RAW Для конвертации .vmdk в RAW используем команду:

qemu-img convert -f vmdk -O raw
migrate-vm-to-openstack-wv-1.vmdk
migrate-vm-toopenstack-wv-1.raw

5. Создаем образ на основе файла в формате RAW Формируем образ для OpenStack на основе сконвертированного образа:

openstack image create --disk-format raw --file
migrate-vm-to-openstack-wv-1.raw win8-image

6. Создаем загрузочный диск

openstack volume create --image win8-image –size
<РАЗМЕР_ЗАГРУЗОЧНОГО_ДИСКА_В_ГБ> win8-volume

7. Скачиваем ISO-образ с драйверами virtio на хост, где установлен openstack-client ISO-образ с драйверами virtio нужен для запуска мигрированной ВМ. Его можно скачать по ссылке:

8. Скачиваем образ virtio из ISO-файла

openstack image create --private --container-format bare --disk-format iso --file <ИМЯ_ФАЙЛА_НА_ЛОКАЛЬНОМ_ДИСКЕ>.iso virtio-img

9. Создаем диск из образа virtio

openstack volume create --image virtio-img –size 1
virtio-volume-drivers

10. Запускаем ВМ Запускаем ВМ, у которой первым устройством типа CD-ROM будет ISO-файл с драйверами virtio, а вторым — созданный ранее диск из загруженного образа Windows. Используем команду:

nova boot --flavor Tiny-1-1-10 --nic net-id=<NETWORK_ID> --block-device
id=<VOLUME_ID_FOR_VIRTIO_VOLUME_DRIVERS>,source=volume,dest=volume,bus=ide,
device=/dev/ vdb,size=1,type=cdrom,bootindex=1 --block-device source=volume,id=<VOLUME_ID_FOR_WIN8_VOLUME>,dest=volume,bus=virtio,device=/dev/ vda,size=35,bootindex=0
win8-migrate-from-vmware

Для выполнения последующих шагов записываем имя сервера

win8-migrate-from-vmware

11. Используем режим восстановления После запуска ВМ переходим в консоль. Windows будет пытаться запуститься, но будет выдавать BSOD («синий экран смерти»). После нескольких ошибок ОС будет запущен режим восстановления. После перехода в режим восстановления выбираем раскладку клавиатуры, а в окне «Выбор действия» выбираем пункт «Поиск и устранение неисправностей». Запускаем командную строку. Проверяем список доступных дисков. Чтобы получить доступ к дискам ВМ, временно устанавливаем драйвер virtio.

После этого устанавливаем драйверы viostor, viorng и netkvm. Выходим из консоли.

Нажимаем «Продолжить» — запустится Windows-инстанс. Входим в учетную запись.

12. Устанавливаем virtio Переходим в ISO-диск c virtio и выбираем установку virtio-win-gt-x64.

Проверяем, что диск и сетевая карта работают на драйвере virtio.

13. Останавливаем ВМ Используем имя сервера, записанное на шаге запуска ВМ:

openstack server stop win8-migrate-from-vmware

14. Отключаем ISO-диск от инстанса

nova volume-detach <VM_NAME_OR_ID>
<VOLUME_ID_FOR_VIRTIO_VOLUME_DRIVERS>

15. Создаем клон основного диска Windows

openstack volume create –volume
<VOLUME_ID_FOR_WIN8_MIGRATE_FROM_VMWARE> win8-volumeclone

16. Создаем публичный образ из клона основного диска Windows

openstack image create --container-format bare --disk-format
raw –volume win8-volumeclone –public --property
os_type='windows' --property os_version='8.1' –property
hw_qemu_guest_agent='true' win8-bios

Дожидаемся создания образа.

17. Создаем ВМ После создания проверяем ВМ, и можно начинать пользоваться.

Сценарий также подходит для миграции ВМ в публичное облако VK Cloud. Новые пользователи VK Cloud могут бесплатно протестировать возможности облака. Для этого нужно зарегистрироваться на платформе VK Cloud и активировать аккаунт. Для тестирования сервиса будет начислено 3000 рублей.

Главное по теме

Миграция ВМ между платформами — сложный, но иногда необходимый процесс.
Причин для переноса ВМ на новое решение может быть много. Основные из них — плановое обслуживание сервера, обновление ИТ-инфраструктуры, смена вендора.
Обычно миграция состоит из нескольких этапов: планирования, подготовки скриптов, выгрузки образа, промежуточной конвертации, загрузки и запуска.
При тщательной подготовке можно быстро мигрировать виртуальные машины с любой платформы виртуализации. Задачу упрощают и типовые сценарии переноса. Например, процессы миграции в частное облако Private Cloud с разных исходных платформ виртуализации практически не различаются.

Узнавайте о выходе новых статей в блоге первыми!

Будем держать в курсе новостей и облачных трендов

Почитать по теме

4 августа

Как перенести резервное копирование в облако и не переплачивать за инфраструктуру

Читать статью

3 августа

Гибридное облако: как объединить локальную инфраструктуру с облаком VK Cloud

Читать статью

23 июля

От текущих вызовов к нео-клинике: в деталях о потенциале внедрения Cloud и AI для развития медицинской отрасли

Читать статью