Как я уже раньше писал, OpenVZ заманала меня окончательно. И учитывая то, что Debian начиная с Wheezy вообще отказывается от поддержки OpenVZ в своем дистрибутиве, я решил полностью переходить на KVM. Вопрос только в том, что все OpenVZ-контейнеры нужно переделывать под самостоятельные машины, пригодные для запуска внутри KVM/Qemu. Для этого я и создал эту инструкцию, напоминашку, шпаргалку (нужное подчеркнуть).
Для определенности я буду исходить из предположений, что в качестве оболочки ("морды") используется ProxMox. Мы будем преобразовывать OpenVZ контейнер с VEID=100 в KVM-виртуалку с ID=500. В качестве гостевой системы выступает Debian Squeeze.
- Chroot-имся вовнутрь остановленного контейнера.
chroot /var/lib/vz/private/100 /bin/bash
- Инсталлируем пакеты linux-image, grub-pc, acpi-support-base и все их зависимости.
apt-get install linux-image-2.6.32-5-amd64 grub-pc acpi-support-base
Загрузочную запись GRUB-а, понятно, пока не создаём. Установка ACPI, скорее всего, закончится ошибкой. Но пока это не суть важно. При установке ядра указываем в параметрах запуска по умолчанию переменнуюelevator=noop
- Проверяем, что не отключили (то есть на месте) запуск checkroot.sh, urandom. При необходимости включаем. Также проверяем в /etc/default/rcS переменную "HWCLOCKACCESS". Проверяем в /etc/init.d/rc переменную "CONCURRENCY". Проверяем, что включены терминалы в /etc/inittab:
1:2345:respawn:/sbin/getty 38400 tty1
Удаляем файлы "/etc/init.d/.legacy-bootordering" и "/etc/rc6.d/S00vzreboot" (если таковые имелись).
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6 - На всякий случай проверяем, что с init-скриптами всё в порядке:
dpkg-reconfigure insserv sysv-rc
- Выходим из chroot-окружения контейнера.
- Создаем новую KVM-ную виртуалку с жестким диском типа "Raw". В качестве образа CDROM скармливаем ей NetInstall-дистрибутив. Он нам понадобится позже для создания загрузочной записи GRUB-а. Поскольку в Linux-е проблем с драйверами для VirtIO нет, то разумно использовать именно их в качестве дисковых и сетевых устройств.
- Размечаем виртуальный диск на разделы.
cd /var/lib/vz/images/500/
На всякий случай проверяем смещение только что созданного раздела:
parted vm-500-disk-1.raw
(parted) mklabel msdos
(parted) mkpart primary ext3 0% 100%(parted) unit B
Как видно, у меня оно равно 1048576 байтам:
(parted) printPartition Table: msdos
Если у вас значение будет другим, то везде далее по тексту необходимо будет внести соответствующие коррективы.
Number Start End Size Type File system Flags
1 1048576B 5368709119B 5367660544B primary
(parted) quit - Монтируем только что отформатированный диск как LOOP-устройство.
losetup -o 1048576 /dev/loop1 vm-500-disk-1.raw
- Создаем файловую систему. Приведенные ниже параметры сугубо "на любителя". Не советую их тупо копировать, если не знаете что они означают.
mkfs.ext3 -b 2048 -I 128 -m 1 -L rootfs -O large_file,sparse_super /dev/loop1
tune2fs -c0 -i0 /dev/loop1 - Монтируем корневую ФС будущей виртуалки и переносим на неё все из контейнера.
mkdir /mnt/temp
mount /dev/loop1 /mnt/temp
cp -a /var/lib/vz/private/100/. /mnt/temp/ - Выясняем какой ID получила вновь созданная ФС и прописываем её внутри fstab будущей виртуалки:
blkid | grep loop1
cat >> /mnt/temp/etc/fstab
proc /proc proc defaults 0 0
UUID=подставить_свой_UUID / ext3 noatime,errors=remount-ro 0 1 - Проверяем настройки сети в "/etc/network/interfaces".
- Размонтируем ФС виртуальной машины.
umount /mnt/temp
losetup -d /dev/loop1 - Запускаем только что созданную KVM-ную виртуалку, загружаемся с NetInst-образа в Rescue mode. На последнем шаге выбираем опцию "Execute a shell in /dev/vda1" (если, конечно, до этого выбрали VirtIO).
- В chroot-ованном шелле до-устанавливаем acpi, записываем загрузочную запись GRUB-а и генерируем заново InitRamFS.
apt-get -f install
grub-install /dev/vda
update-grub
update-initramfs -u - Перезагружаемся. По идее всё должно заработать.