При конфигурации Windows Server есть нюансы. У ансибла есть слабая сторона по части эскалации привелегий. Открываем доку: A user must have the SeDebugPrivilege to run a become process with elevated privileges. Б — безопасность.
Впрочем, классический дуализм Эскобара)))
Терраформ далеко не со всеми решениями работает корректно: SC VMM он плохо деплоит)
Итого — у каждой задачи свой набор инструментов из огромного зоопарка))
Скрипт-блоки — прелесть. Но с модулями удобнее (хоть и не всегда, так как порой логика исполнения ресурсов кривая).
Про некорректное сравнение: DSC в какой-то степени деревянный. Но зато работает на любом утюге с пошиком.)) А еще у нас есть SCCM и Terraform, которые тоже приводят систему к нужному состоянию. Но DSC все же примитивнее их всех)
Можно. Но не эффективно, так как предполагает дополнительное действие при создании шаблона. Инженер может забыть выполнить действие при создание шаблона и это выльется в неприятности. Робот надежнее.
Да и не нужен этот раздел на ВМ)
Так, но не достаточно (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 — и везде свои сценарии, зависящие от особенностей каждого дистрибутива.
Впрочем, классический дуализм Эскобара)))
Итого — у каждой задачи свой набор инструментов из огромного зоопарка))
Про некорректное сравнение: DSC в какой-то степени деревянный. Но зато работает на любом утюге с пошиком.)) А еще у нас есть SCCM и Terraform, которые тоже приводят систему к нужному состоянию. Но DSC все же примитивнее их всех)
А вот управлять процессом можно с любой удобной ОС — на любую ОС.
Список всех фич получается так:
В вашем случае параметр будет иметь вид:
Да и не нужен этот раздел на ВМ)
Действия после — использование нюансов конкретных гостевых ОС. Но в первом приближении, как минимум:
— Удалить компонеты интеграции исходного гипервизора и установить IC целевого (в сценарии Hyper-V -> VMware службы интеграции сами «лягут». В Linux — убираем модули, ставим IC и пересобираем initramfs.
— Почистить установленные устройства в случае с Windows Server. В Linux — пересборка initramfs с необходимыми и достаточными модулями ядра (тут нет четкой грани с предыдущим пунктом)
Ну и держим в голове, что различные дистрибутывы Linux по разному реагируют на такой переезд (хотя, мигрируют они очень интересно). Мы на бою тестировали RHEL/CentOS, SLES и Ubuntu — и везде свои сценарии, зависящие от особенностей каждого дистрибутива.