Как восстановить виртуальные машины Hyper-V при копировании на другой хост в windows server 2008R2

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

В наличии папка с конфигурационными файлами виртуальной машины и снепшотов (xml) и файлы виртуальных дисков и снапшотов vhd и avhd.

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

Цель: подключить виртуальную машину со всеми снепшотами.

Итак, для начала создаем новую виртуальную машину с именем DeleteMe в папке c:\VMs.

Рисунок 1. Создание виртуальной машины

Далее создаем через консоль Hyper-V Manager несколько снепшотов. Обратите внимание на имя файла для HDD на IDE Controller 0 и параметры сети.

Рисунок 2. Настройки виртуальной машины.

Посмотрим, что же мы получили с папке c:\VMs после выполнения этих операций.

Для новой виртуальной машины создана папка с именем виртуальной машины. Внутри этой папки расположены файлы жестких дисков и снепшотов и папки с конфигурацией виртуальной машины Virtual Machines и с конфигурацией снепшотов Snapshots.

Рисунок 3. Папка C:\VMs\DeleteMe.

Рисунок 4. Папка C:\VMs\DeleteMe\Snapshots.

Рисунок 5. Папка C:\VMs\DeleteMe\Virtual Machines.

Итак, исходная конфигурация готова.

Пора «терять» виртуальную машину.

Для простоты эксперимента остановим управляющий сервис гипервизора через консоль Hyper-V Manager и скопируем всю папку DeleteMe.

Дополнительно подстрахуемся при помощи Volume Shadow Copy. Использование Volume Shadow Copy для диска, на котором расположен файл конфигурации виртуальной машины и на системном разделе – неплохой вариант восстановления правильной конфигурации или всей виртуальной машины, которая была случайно удалена. Но вот по поводу использования Volume Shadow Copy для раздела, где расположены диски и снепшоты виртуальных машин – тут меня терзают сомнения. Copy on Write приведет к дополнительным издержкам при записи. Особенно, если для хранения Shadow Copy используется не отдельный выделенный диск, а свободное место на том же разделе.

Итак, подстелили соломку, включили управляющий сервис гипервизора и удаляем виртуальную машину через консоль Hyper-V Manager.

Рисунок 6. Удаление виртуальной машины DeleteMe.

После этого сравним содержимое папки C:\VMs\DeleteMe до и после операции.

Количество файлов уменьшилось. Ровно в 2 раза. It’s fantastic! Используя Hyper-V Manager Вы можете удалить половину файлов в сложной структуре папок одной командой!!!

Обратите внимание на значение полей Location и Contains.

Рисунок 7. Папка C:\VMs\DeleteMe до и после удаления виртуальной машины.

Почему удалена половина файлов? Почему файлов было 12? Не скажу. Жду Ваши предположения в комментариях J

Итак, пора приступать к восстановлению.

Останавливаем управляющий сервис гипервизора. Копируем содержимое папки DeleteMe обратно. В боевой ситуации этот шаг соответствует восстановлению/переустановке сервера или подключению дисков к другому серверу.

Вот и начинается самое интересное… Как объяснить службе гипервизора, что необходимо прочитать конфигурацию виртуальной машины из некоторого файла в файловой системы. За внутренности работы Hyper-V отвечает папка скрытая C:\ProgramData\Microsoft\Windows\Hyper-V. В ней содержится файл управления ролевым доступом к Hyper-V InitialStore.xml, а также папки Virtual Machines и Snapshots. Основной фокус в том, что при создании виртуальной машины через Hyper-V Manager в этих папках создаются NTFS hardlinks на соответствующие конфигурационные файлы. Таким образом, задача сводится к созданию hardlinks.

Создаем hardlink при помощи оманды mklink в административной командной строке.

Рисунок 8. Создание hardlink для конфигурационного файла виртуальной машины.

Запускаем управляющий сервис гипервизора и видим, что в консоли ничего не появилось…

Все пропало… Гипс сняли, а бриллиантов то там давно и нету…

Зато в журнале событий есть письмо от расстроенного гипервизора:

Рисунок 9. Ошибка загрузки конфигурации виртуальной машины.

Проверьте ACL объекта hardlink для виртуальной машины, созданной при помощи Hyper-V Manager. В нашем hardlink отсутствует SID виртуальной машины с разрешениями Full Control.

SID виртуальной машины по странному стечению обстоятельств подозрительно похож на GUID, из которого состоит имя конфигурационного файла виртуальной машины.

Останавливаем управляющий сервис гипервизора.

Модификацию ACL выполняем при помощи cacls.

Рисунок 10. Модификация ACL для hardlink конфигурационного файла виртуальной машины.

Обратите внимание на имя Security Principal NT VIRTUAL MACHINE\<GUID>.
Запускаем управляющий сервис гипервизора.

Открываем консоль Hyper-V Manager. О, чудо!!! Виртуальная машина тут.

Но без снепшотов и с потерянной сетью. Обратите внимание, что диск подключен к правильному avhd файлу. Т.е. виртуальная машина уже находится в последнем активном состоянии, но без возможности удалить или применить нужный снепшот.

Рисунок 11. Конфигурация виртуальной машины.

Заглянем снова в журнал событий.

Рисунок 12. Ошибка загрузки снапшотов.

И снова закинул старик свой невод…Потемнело синее море…Давно старик не стирал свой невод…

В смысле опять останавливаем управляющий сервис гипервизора.

Необходимо создать hardlink для каждого снепшота и добавить разрешение Full Control для SID виртуальной машины в каждый hardlink.

Рисунок 13. Создание hardlink и изменение ACL для снепшота.

Запускаем управляющий сервис гипервизора и о чудо…

Рисунок 14. Консоль Hyper-V Manager. Виртуальная машина с подключенными снапшотами.

Для того, чтобы счастье не только было видно в консоли, но и можно было использовать, осталось предоставить SID виртуальной машины доступ Full Control к папке с конфигурационными и дисковыми файлами виртуальной машины.

Рисунок 15. Изменение ACL папки DeleteMe

Вуаля. Теперь можно изменить конфигурацию виртуальной машины, сменить активный снепшот и начать поиск решения для автоматического выбора правильного сетевого интерфейса для виртуальной машины…