Опыт переноса виртуальной машины с чужого хостинга XEN на свой KVM

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

Сайт крутился в облаке известного провайдера на виртаульной машине с гипервизором XEN. Я надеялся, что поддержка пойдёт навстречу и выдаст образ виртуальной машины, но чуда не случилось: отказ был холоден и учтив, наверное, как обычно. В результате родилась примерная схема переноса: сделать образ диска, передать его на свой сервер, создать у себя виртуалку, указав полученный образ в качестве источника.

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

1. Подключение к своему серверу

Поскольку делать образ диска на сам этот диск достаточно хлопотно, нужно было подключить файловую систему, отличную от используемой. Первое, что пришло в голову — смонтировать домашнюю папку своего сервера в файловую систему на виртуалке с помощью sshfs. Команды привожу для дистрибутива Debian:

# apt-get install sshfs
# mkdir /mnt/vasya
# sshfs vasya@pupkin.ru:/home/vasya /mnt/vasya
Password: Чебурашка-2014

2. Перевод ФС в read-only

Для того, чтобы файловая система не потеряла целостность, нужно было перевести её в режим защиты от записи (read-only). Для этого в линуксе предусмотрена возможность перемонтирования ФС: mount -o ro,remount /. Команда закономерно не сработала, ядро блокировало выполнение команды с ошибкой mount: / is busy. После некоторого гугления нашлась причина: многие файлы были открыты демонами. На сервере мне пришлось остановить ntp, apache2, mysql, rsyslogd (возможно, я что-то пропустил, но список запущенных процессов можно посмотреть командой htop или top).

# invoke-rc.d ntp stop
# invoke-rc.d apache2 stop
# invoke-rc.d mysql stop
# invoke-rc.d rsyslogd stop
# mount -o ro,remount /
# touch /test
touch: cannot touch `/test': Read-only file system

3. Создание и передача образа

Для создания образа я воспользовался программой dd. Также я воспользовался конвейером данных и направил их через программу сжатия gzip в файл, расположенный в папке, которая смонтирована на удалённый сервер.

# dd if=/dev/xvda bs=64K | gzip -c > /mnt/vasya/xvda.raw.gz

Через полтора часа я имел у себя на сервере файл /home/vasya/xvda.raw.gz с нужным мне образом. Коэффициент сжатия оказался неплохим: 8.5/12.

4. Подключение образа к новой виртуальной машине

На локальном железе я использую Proxmox VE 3.1. Я создал виртуальную машину со следующей конфигурацией:

balloon: 256
bootdisk: virtio0
cores: 2
ide2: nfs-da:iso/debian-7.2.0-amd64-netinst.iso,media=cdrom,size=222M
memory: 768
name: pupkin
net0: virtio=26:95:81:17:D9:14,bridge=vmbr0
ostype: l26
sockets: 1
virtio0: nfs-da:143/vm-143-disk-1.raw,format=raw

Файл образа виртауальной машины я, конечно, разархивировал и положил в нужное место с нужными правами доступа (/mnt/nfs — это раздел, сконфигурированный как хранилище Proxmox VE, 143 — идентификатор новой виртуалки):

# zcat /home/vasya/xvda.raw.gz > /mnt/nfs/images/143/vm-143-disk-1.raw
# chown nobody:nogroup /mnt/nfs/images/143/vm-143-disk-1.raw

По своей неопытности я предвкушал победу, но не тут-то было: загрузчик Grub выпадал в свою консоль. Более того, попытки загрузиться вручную были обречены на провал: в полученном образе отсутствовал инициализатор окружения initrd, а ядро было узкоспециализированным и не содержало драйверов для virtio устройств (сеть и жёсткий диск). Опытные специалисты могут меня дополнить и объяснить, как сконфигурирована загрузка Linux в среде XEN, мне до этого не было дела, у меня уже зарождался новый план: нужно положить на образ ядро linux, его драйверы и initrd от работающей виртуальной машины с похожей операционкой.

5. Исправление загрузчика

У меня была рабочая виртуалка, к которой я добавил новый диск, а затем удалил его образ с файловой системы и заменил его симлинком на сломанный образ. Предварительно я, конечно, выключил виртуалку 143, чтобы образ случайно не открыли 2 процесса одновременно.

# rm /mnt/nfs/images/200/vm-200-disk-2.raw
# ln -s /mnt/nfs/images/143/vm-143-disk-1.raw /mnt/nfs/images/200/vm-200-disk-2.raw

Я загрузил виртуалку 200, смонтировал ФС сломанного образа и скопировал туда ядро linux, рабочий загрузчик и драйверы устройств.

# mkdir /mnt/vdb1
# mount /dev/vdb1 /mnt/vdb1
# cp /boot/vmlinuz-3.2.0-4-amd64 /mnt/vdb1/boot/vmlinuz-3.2.0-4-amd64 
# cp /boot/initrd.img-3.2.0-4-amd64 /mnt/vdb1/boot/initrd.img-3.2.0-4-amd64
# cp /boot/System.map-3.2.0-4-amd64 /mnt/vdb1/boot/System.map-3.2.0-4-amd64
# cp -r /lib/modules/3.2.0-4-amd64 /mnt/vdb1/lib/modules

Я выключил 200, включил 143 и ввёл команды ручной загрузки Grub:

grub> root (hd0,msdos1)
grub> linux /boot/vmlinuz-3.2.0-4-amd64 root=/dev/vda1
grub> initrd /boot/initrd.img-3.2.0-4-amd64
grub> boot

Система загрузилась и даже успешно стартовала mysql и apache2. Мне, конечно, пришлось поправить /etc/network/interfaces, чтобы система вышла в локальную сеть и смогла общаться с маршрутизатором и сетью Интернет.

На полноценно работающей машине дальше уже не возникало проблем: я запустил установку grub и установил ядро linux из репозитория, чтобы выпрямить загрузчик окончательно и следовать debian-way:

# grub-install /dev/vda
# apt-get update
# apt-get install linux-image-2.6.32-5-486
# reboot

Вывод

В результате всех манипуляций я получил виртуальную машину, почти идентичную исходной, но работающую в среде Proxmox VE с гипервизором KVM и не требующую специального загрузчика. Образ планируется передать клиенту для запуска в кластере VMware ESX.

Автор: ujifgc

Источник