>да вот же он, типичный 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рена практики. от слова совсем.