Переносим виртуальные машины с одной платформы на другую ♦ Блог VK Cloud | Блог VK Cloud

VK Cloud

VK Cloud

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

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

Рассказываем, как подготовиться и провести миграцию между платформами без боли и нежелательных последствий, а также покажем сценарии переноса ВМ между платформами для операционных систем (ОС) 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 —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= --block-device
id=,source=volume,dest=volume,bus=ide,
device=/dev/ vdb,size=1,type=cdrom,bootindex=1 --block-device source=volume,id=,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

15. Создаем клон основного диска Windows
openstack volume create –volume
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 с разных исходных платформ виртуализации практически не различаются.

Рассказываем об IT-бизнесе, технологиях и цифровой трансформации

Подпишитесь в соцсетях или по email