Каким будет оптимальный способ конвертировать контейнеров LXC в виртуальную машину KVM в proxmox?
Имеется кластер виртуализации под управлением Proxmox, в котором работает большое количество виртуалок, а также контейнеров LXC. Также есть система хранения данных, выполняющая роль разделяемого хранилища, на котором хранятся виртуальные диски контейнеров и виртуалок. Возникла необходимость миграции всего комплекса в другое помещение, желательно с наименьшим возможным простоем или в идеале без него. В связи с этим было решено развернуть второе временное хранилище в новой локации, и переносить сервера по одному, мигрируя виртуалки на лету по мере необходимости между серверами, и их виртуальные диски - между хранилищами.
Затруднение возникает с контейнерами LXC, т.к. их миграция возможна только в выключенном состоянии. Есть идея конвертировать контейнеры в виртуальные машины, но нужно подобрать оптимальный по времени и трудозатратам способ сделать это. Среди контейнеров есть серверы БД размером более сотни гигабайт, у которых долгий простой очень нежелателен.
Просматриваются варианты:
1. Для каждого контейнера создать и сконфигурировать виртуалку с эквивалентным набором сервисов. Способ оптимальный по получаемому результату, но потребует большого объема работы для каждого контейнера и значительного времени на перенос данных.
2. Для каждого контейнера создать виртуалку, и подключить образ RAW-диска к ней как дополнительное блочное устройство, после чего запустить контейнер уже не напрямую в proxmox, а в этой виртуалке. Способ рабочий и приемлем в качестве временного решения, но нестандартная сложновложенная конфигурация получившихся объектов виртуализации не радует. Но теоретически потом возможен откат к обычной конфигуации. Кроме того, потребуется выделение дополнительного ip-адреса для каждой виртуалки.
3. Попробовать подключить raw-файл контейнера как root-раздел виртуальной машины, а раздел /boot и подкачку вынести на отдельный виртуальный диск, который будет загрузочным.
Последний способ был бы оптимальным, но проблема в том, что в raw-файлы LXC отформатированы сразу в EXT4 и там нет таблицы разделов, а стандартный инсталлятор Debian не позволит создать файловую систему напрямую на блочном устройстве, чтобы файл виртуального диска потом можно было бы подменить, не сломав конфигурацию загрузчика. Это затрудняет использование RAW-файла таким способом, без предварительно копирования его в новый файл с созданием таблицы разделов там. Хотелось бы услышать какие-то идеи, как проще всего можно было бы преодолеть это затруднение.
Или возможно есть какие-то другие "обкатанные" способы преобразовать контейнер в виртуалку в proxmox?
Попробовал реализовать третий способ. Нормально работающей системы после этого получить не удалось. Последовательность действий:
создал контейнер test-ct (шаблон debian-11)
создал минимальную виртуальную машину Debian 11 с двумя виртуальными дисками, разбиение следующее: /dev/vda1 - /boot, /dev/vda2 - подкачка, /dev/vdb1 - корневой раздел
подменил образ диска /dev/vdb образом диска контейнера
загрузился в консоль восстановления установщика debian, подмонтировал /dev/vdb в каталоге /mnt/root, воссоздал его подкаталогах иерархию монтирования /dev/vda1 (/boot), а также /proc, /sys, /dev и сделал chroot в этот каталог
настроил в /etc/fstab (который у LXC-контейнеров пустой) монтирование /dev/vda1 как /boot и /dev/vdb как корневой файловой системы
настроил в /etc/interfaces сетевой адаптер ens18 вместо eth0
После выполнения указанных действий система загружается, но не до конца (сваливается в безопасный режим, т.к. не может смонтировать все файловые системы).
Третий способ работает с 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)
- выпополнить команды
В варианте с БД мне кажется единственный вариант избежать длительного простоя - это настраивать репликацию БД в новые ВМ и потом переключать работу сервисов на новые БД.
Подготовьте окружение и перенесите данные.
Чтобы в дальнейшем не было боли, напишите для вашего окружения скрипты (Bash/Python) или сценарии (Ansible).
Простой
Простой
Простой
Средний
Средний
