>да вот же он, типичный use-case bhyve!

это с личного нотника.
копировать-публиковать корпоративные данные я не имею права, и это непрофессионально.

>сколько лет в "нормальном себе гипервизоре" была ниасилена графическая консоль

то есть ты написал-осилил ее для другого гипервизора, и этим очень горд?
а... это был не ты.
ты вообще ничего не разработал....

>Про ее чудесатый uefi и особенности загрузки того "deb" помолчим

в чем проблема? прочитать по-аглицки?

https://github.com/churchers/vm-bhyve/wiki/Supported-Guest-E...

ну да, модифицированный grub, кастомный uefa.
cd /usr/ports/bla/bla
make install clean

для запуска linux используют жутковытый и нахрен не нужный в 99% initrd со столь же жутковатой конфигурацией grub, и ничего, котятки не мяукают.

>ничуть не удобнее vbox, если уж непременно вперлось freebsd.

ты опять не в теме.

в zfs, к примеру, реализован инкрементальный поток с тома-источника на систему-резерв.
zfs snap ...
zfs send ... | ssh xxx 'zfs receive ...'

при этом оно уже есть, и весьма рабочее.
тикает себе по крону.

>а теперь расскажите нам, как у вас устроена миграция

у нас - это где? в последнем проекте-кейсе, на предприятии?
где-то горячий резерв с синхронизацией, где-то действительно холодная копия + дамп актуальных данных
live migration на практике маркетинговая сказка. данных дохрена, сетевые шины относительно узкие, в рабочее время запросов дофига - живая типа миграция на деле превращается в мертвую, а в нерабочее остановить не проблема.

а отказы все равно продумываются-обрабатываются по другому.
и собственно все равно упирается в продуманность, расчет,
четкую методику и соотвествие деловым процессам.

тут одни приходили из операторов, тоже пытались впарить бохсы-шмоксы.
дал им одну систему на пробу, через неделю они мне ее нaепnули. вообще. 4 часа простоя.
при том что за два года ранее, до ихней живой миграции, было всего ~20 минут.

парень, у тебя много бла-бла и ниxрена практики. от слова совсем.