Каким будет оптимальный способ конвертировать контейнеров LXC в виртуальную машину KVM в proxmox?

Question

[Дмитрий]

Имеется кластер виртуализации под управлением Proxmox, в котором работает большое количество виртуалок, а также контейнеров LXC. Также есть система хранения данных, выполняющая роль разделяемого хранилища, на котором хранятся виртуальные диски контейнеров и виртуалок. Возникла необходимость миграции всего комплекса в другое помещение, желательно с наименьшим возможным простоем или в идеале без него. В связи с этим было решено развернуть второе временное хранилище в новой локации, и переносить сервера по одному, мигрируя виртуалки на лету по мере необходимости между серверами, и их виртуальные диски - между хранилищами.
Затруднение возникает с контейнерами LXC, т.к. их миграция возможна только в выключенном состоянии. Есть идея конвертировать контейнеры в виртуальные машины, но нужно подобрать оптимальный по времени и трудозатратам способ сделать это. Среди контейнеров есть серверы БД размером более сотни гигабайт, у которых долгий простой очень нежелателен.
Просматриваются варианты:
1. Для каждого контейнера создать и сконфигурировать виртуалку с эквивалентным набором сервисов. Способ оптимальный по получаемому результату, но потребует большого объема работы для каждого контейнера и значительного времени на перенос данных.
2. Для каждого контейнера создать виртуалку, и подключить образ RAW-диска к ней как дополнительное блочное устройство, после чего запустить контейнер уже не напрямую в proxmox, а в этой виртуалке. Способ рабочий и приемлем в качестве временного решения, но нестандартная сложновложенная конфигурация получившихся объектов виртуализации не радует. Но теоретически потом возможен откат к обычной конфигуации. Кроме того, потребуется выделение дополнительного ip-адреса для каждой виртуалки.
3. Попробовать подключить raw-файл контейнера как root-раздел виртуальной машины, а раздел /boot и подкачку вынести на отдельный виртуальный диск, который будет загрузочным.
Последний способ был бы оптимальным, но проблема в том, что в raw-файлы LXC отформатированы сразу в EXT4 и там нет таблицы разделов, а стандартный инсталлятор Debian не позволит создать файловую систему напрямую на блочном устройстве, чтобы файл виртуального диска потом можно было бы подменить, не сломав конфигурацию загрузчика. Это затрудняет использование RAW-файла таким способом, без предварительно копирования его в новый файл с созданием таблицы разделов там. Хотелось бы услышать какие-то идеи, как проще всего можно было бы преодолеть это затруднение.
Или возможно есть какие-то другие "обкатанные" способы преобразовать контейнер в виртуалку в proxmox?

Comments

[Дмитрий]

Попробовал реализовать третий способ. Нормально работающей системы после этого получить не удалось. Последовательность действий:

1. создал контейнер test-ct (шаблон debian-11)
   
2. создал минимальную виртуальную машину Debian 11 с двумя виртуальными дисками, разбиение следующее: /dev/vda1 - /boot, /dev/vda2 - подкачка, /dev/vdb1 - корневой раздел
   
3. подменил образ диска /dev/vdb образом диска контейнера
   
4. загрузился в консоль восстановления установщика debian, подмонтировал /dev/vdb в каталоге /mnt/root, воссоздал его подкаталогах иерархию монтирования /dev/vda1 (/boot), а также /proc, /sys, /dev и сделал chroot в этот каталог
   
5. настроил в /etc/fstab (который у LXC-контейнеров пустой) монтирование /dev/vda1 как /boot и /dev/vdb как корневой файловой системы
   
6. настроил в /etc/interfaces сетевой адаптер ens18 вместо eth0
   
7. загрузил пакеты linux-image-amd64, initramfs-tools, grub2
   
8. выполнил update-initramfs -u
   
9. выполнил grub-install /dev/vda
   
10. выполнил update-grub
    

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

[Дмитрий]

Третий способ работает с privileged-контейнерами. Последовательность действий для конвертации в виртуалку (предполагается, что контейнер - Debian-based):
- создть минимальную виртуальную машину Debian 11 с двумя виртуальными дисками, разбиение следующее:
- подготовить виртуальную машину-донор с двумя виртуальными дисками, разбитыми следующим обоазом: /dev/vda1 - /boot, /dev/vda2 - подкачка, /dev/vdb1 - корневой раздел
- подменить второй виртуальный диск (/dev/vdb) виртуальным диском контейнера
- перезагрузиться, указав в загрузчике опцию ядра root=/dev/vdb вместо root=UUID=xxxxx
- подключить сеть, настроив сетевой адаптер вручную, либо отредактировать /etc/network/interfaces (нужно только заменить имя сетевого адаптера eth0 на актуальное) и перезагрузиться еще раз, чтобы сеть поднялась автоматически
- подмонтировать вручную /dev/vda1 как /boot
- привести файл /etc/fstab к виду

/dev/vda1       /boot   auto    defaults                0       2 
/dev/vdb        /       auto    errors=remount-ro       0       1
/dev/vda2       none    swap    sw                      0       0

- установить ядро линукса linux-image-amd64 и зависимые пакеты (команда apt install linux-image-amd64)
- установить загрузчик grub2 (команда apt install grub2)
- выпополнить команды

grub-install /dev/vda
update-grub

Answer 1

[Alexey Dmitriev]

В варианте с БД мне кажется единственный вариант избежать длительного простоя - это настраивать репликацию БД в новые ВМ и потом переключать работу сервисов на новые БД.

Answer 2

[Sanes]

Подготовьте окружение и перенесите данные.
Чтобы в дальнейшем не было боли, напишите для вашего окружения скрипты (Bash/Python) или сценарии (Ansible).

Answer 3

[Drno]

Выделить ночь для миграции. Предупредить всех о тех работал
Выключить и мигрировать.
Самый простой вариант

Comments

[Sanes]

Еще и самый безопасный. Выключать по-любому. Как минимум блокировать запись.