Комментарии 12
Короткий, внятный и полезный результат многодневных переворачиваний автором терабайт данных туда-сюда с риском потери этих данных.
Побольше бы таких статей.
(вместо "как я добрался до клавиатуры и бегом тиснуть бред нетленку на хабре").
Эх, где же вы были раньше!
Столько боли, крови и бессонных ночей мне стоили причуды некоторых «АйТи-директоров» требующих периодических переездов с одних систем виртуализации на другие…
Столько боли, крови и бессонных ночей мне стоили причуды некоторых «АйТи-директоров» требующих периодических переездов с одних систем виртуализации на другие…
Я применял такой трюк:
1) на hyper-v поднимаем nfs шару
2) подцепляем nfs шару на esxi
3) мигрируем vmdk
4) долго ждём, но при этом VM продолжает работать
5) выключаем VM на esxi
6) меняем заголовок
7) стартуем VM уже на hyper-v
Так, но не достаточно (NetApp, кстати, использует такую схему: greatwhitetec.com/2015/05/04/shift-vms-between-hypervisors). Просто стартовать = получить проблемы. Именно на этом основываются почти все конвертеры — простое конвертирование. Причем, неприлично долгое и неэффективное. В статье я описывал процес конвертации In-Place. Разумеется, также весело конвертировать через quemu-img, но тут ель была разложить на пальцах процесс.
Действия после — использование нюансов конкретных гостевых ОС. Но в первом приближении, как минимум:
— Удалить компонеты интеграции исходного гипервизора и установить IC целевого (в сценарии Hyper-V -> VMware службы интеграции сами «лягут». В Linux — убираем модули, ставим IC и пересобираем initramfs.
— Почистить установленные устройства в случае с Windows Server. В Linux — пересборка initramfs с необходимыми и достаточными модулями ядра (тут нет четкой грани с предыдущим пунктом)
Ну и держим в голове, что различные дистрибутывы Linux по разному реагируют на такой переезд (хотя, мигрируют они очень интересно). Мы на бою тестировали RHEL/CentOS, SLES и Ubuntu — и везде свои сценарии, зависящие от особенностей каждого дистрибутива.
Действия после — использование нюансов конкретных гостевых ОС. Но в первом приближении, как минимум:
— Удалить компонеты интеграции исходного гипервизора и установить IC целевого (в сценарии Hyper-V -> VMware службы интеграции сами «лягут». В Linux — убираем модули, ставим IC и пересобираем initramfs.
— Почистить установленные устройства в случае с Windows Server. В Linux — пересборка initramfs с необходимыми и достаточными модулями ядра (тут нет четкой грани с предыдущим пунктом)
Ну и держим в голове, что различные дистрибутывы Linux по разному реагируют на такой переезд (хотя, мигрируют они очень интересно). Мы на бою тестировали RHEL/CentOS, SLES и Ubuntu — и везде свои сценарии, зависящие от особенностей каждого дистрибутива.
Ух. Что люди не сделают, лишь бы не конвертировать через qemu-img.
Из дополнительных особенностей — умеет ещё несколько форматов (qcow, например), сжатие и шифрование образов, работает везде, тащит минимум зависимостей.
Из дополнительных особенностей — умеет ещё несколько форматов (qcow, например), сжатие и шифрование образов, работает везде, тащит минимум зависимостей.
Понятнее и не напишешь. Спасибо!
qemu-img convert не рассматривали?
или интересен был только вариант с Windows?
Огромное спасибо за ясную и понятным языком написанную статью Единственное жаль, что не описаны диски VirtualBox. К нему я спокойно подключал и vhd, vhdx, и от vmware, а вот виртуалбоксовые нигде не подхватывались. Теперь при работе с виртуалбоксом стараюсь создавать диски совместимые с vmware hyper-v.
Годно, прикопал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С Hyper-V на VMware и обратно: конвертация виртуальных дисков