Недавно я подтасовал свой производственный проксмо-сервер после того, как (глупо) попытался соединить его с кластером, не убедившись, что обе системы были обновлены до одной и той же версии proxmox.

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

Я переустановил Proxmox на своем производственном сервере.

В этот момент я мог бы отреставрировать и восстановить с другого хоста proxmox обратно на производственный сервер, но резервное копирование и восстановление заняли много времени, и я знал, что мои данные ZFS все еще не повреждены, поэтому я подумал, что было бы более эффективно, если бы я мог просто восстановить пул ZFS.

Вот как я это сделал:

zfs list

Вернули идентификатор пула и список дисков виртуальных машин.

zpool import -f <zpool ID>

Флаг -f (сила) был необходим, потому что это была «новая» система.

zpool status

подтвердил, что пул был импортирован должным образом и был ОНЛАЙН.

В Хранилище под Центром обработки данных я нажал На Клид, ввел идентификатор пула и выбрал мой теперь ОНЛАЙН-ЛУЗ из выпадающего списка, добавив пул на производственный сервер.

На данный момент данные о пуле ЗФС были доступны, но все еще не было виртуальных машин. Я мог бы воссоздать каждую ВМ. Это казалось утомительным. Поскольку у меня была машина, работающая на другом хосте proxmox, казалось, что проще просто пересесть по конфигурациям VM.

Для этого я скопировал весь файл .conf в /etc/pve/qemu-server в мой производственный проксмокс-узл, а затем отредактировал каждый файл .conf, наносящую идентификатор хранилища в соответствии с идентификатором хранилища на моем производственном сервере. В моем случае это потребовало изменений:

scsi0: VM:vm-100-disk-0,size=60G

к

scsi0: local-zfs:vm-100-disk-0,size=60G

Если бы оба склада были одинаковыми, это было бы необязательно.

«Волшебно» появились ВМ. Однако они не будут загружаться. В то время как диски были прикреплены к VM, VM не видел их за загрузкой. Редактирование опций VM:Boot Order исправило это.