простой подходит, главное условие не перезагружать ВМ

А инсталляции не на ZFS случаем?

Вот лучше думаю запустит in-memory со сбросом на диск, лучше перестраховаться, да сервисы in memory возможно будут тупить, но зато будет на диске

Можно было бы снапшот сделать, и его через zfs send отправить на другой сервер, импортнув его в танк

память через zfs send разве переезжает ?

По крайней мере при миграции создавался subvolume @ migrate

к сожалению нет
└─nvme1n1p3                                          259:3    0 843.8G  0 part
 └─md2                                                9:2    0 843.6G  0 raid1
   ├─VM--DATA-vm--100--disk--0                      253:2    0    50G  0 lvm
   ├─VM--DATA-vm--101--disk--0                      253:3    0    50G  0 lvm
   ├─VM--DATA-vm--102--disk--0                      253:4    0    50G  0 lvm
   ├─VM--DATA-vm--105--disk--0

Тогда да, надо как-то найти способ снять снимок рамы (скорее всего через monitor, там много таких упоротыъ опций) и загрузить бэкап и снимок. Но блин, это дичь какая-то, консистентность по пизде

Я бы сделал способ с живой миграцией поверх туннеля, всё-таки, только надо потом не объебаться и правильно удалить кластерные данные

с рамой таки консистентность ок будет. но будет долгий фриз во время снятия снапшота.

А расхождения между файловыми дескрипторами?

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

можно ссылку на доку как сделать без shared storage, не могу найти
PVE свежий - 6.1

так же, как с live

тыкаешь кнопку миграции и поехало

главное условие совпадение процессоров

иначе вм после переезда ребутнется

да, тут проблемка

почему ? по дефолту вм назначается проц kvm64

если на host не меняли, то проблем нет