Hyper-V Checkpoints

Snapshot-Frames1Checkpoint’ы (ранее Snapshots) предназначены для быстрого возвращения виртуальной машины к одному из предыдущих состояний.

“Предыдущее состояние” включает в себя содержимое vHDD, vRAM и конфигурации ВМ.

Максимальное количество Checkpoint’ов (далее CP) 50. При попытке сделать 51й CP вы получите такую ошибку:

Screenshot at Mar 13 10-13-56

По-умолчанию, в Windows Server 2012R2 CP хранятся в папке %systemroot%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots

Вы можете изменить расположение из консоли Hyper-V:

Screenshot at Mar 13 10-27-50

Когда вы создаёте CP работающей VM, в этой папке будет создан .xml файл с конфигурацией VM и подпапка в которой будут сохранены файлы .bin и .vsv – так называемые Saved State files.

Если вы делаете CP когда VM выключена,  Saved State файлы созданы не будут.

Разностный VHD(X) будет создан в той же паке где находится “родительский” VHD(X).

Имена .xml , .bin , .vsv , .avhd(x) и подпапки будут соответствовать GUID’y Checkpoint’a.

И если имя .avhdx относительно читабельно:

Screenshot at Mar 13 10-48-28

То имена папок со Snapshots (обратите внимание, папки до сих пор называются по-старому) уже неочевидны:

Screenshot at Mar 13 10-50-21

Узнать GUID Checkpoint’a можно с помощью PowerShell (обратите внимание, снова используется старый термин Snapshots):

Screenshot at Mar 13 10-58-24

В процессе создания Checkpoint для включённой VM происходит следующее:

  1. Виртуальная машина ставится на паузу
  2. Создаётся .avhd(x) файл
  3. Сохраняется резервная копия конфигурации (.xml)
  4. В конфигурацию вносятся изменения (подключается .avhdx файл)
  5. Виртуальная машина запускается
  6. Содержимое RAM сохраняется в Saved state файлы. Если в это время ОС пытается произвести запись в блоки RAM которые ещё не были сохранены, запросы перехватываются и результаты сохраняются.
  7. Checkpoint готов.

Пауза на шаги 1-5 действительно небольшая:

Screenshot at Mar 13 11-34-23

А вот сохранение содержимого ОЗУ в Saved state файлы и занимает основное время.

Процессы применения и удаления Checkpoint’ов я думаю интуитивно понятны, поэтому пойдём дальше.

Экспорт Checkpoint – одна из редко используемых, но действительно полезных функций.

Вы можете сделать экспорт CP, а затем импортировать его на другом хосте.

При этом имя импортированной VM будет соответствовать имени CP:

Screenshot at Mar 13 12-02-46

Вы можете автоматизировать создание CP запуская что-то подобное из Task Scheduler:

Если вы хотите использовать более “говорящие” имена, воспользуйтесь возможностями SnapshotName, вот пример для ежедневных:

.. и ежечасных Checkpoint’ов:

Выглядит это следующим образом:

Screenshot at Mar 13 12-35-35

Автоматически удалять Checkpoint’ы можно вот так (в примере я удаляю те, которые старше 5 дней):

Вот пример командлета, который удалит Checkpoint’ы которые старше одного часа:

Но не всегда время создания Checkpoint’a является фактором на основе которого принимается решение об удалении.

Например, вам может понадобится удалить все Checkpoint’ы в имени которых содержится test, но оставить все остальные, не зависимо от их возраста:

Давайте подведём итоги:

  1. CP снижают производительность не только дисковой подсистемы VM, но и производительность хранилища – причём чем больше CP, тем больше снижается производительность;
  2. Создание CP для VM в выключенном состоянии предпочтительнее, т.к. Во-первых не будет расходов места на запись RAM, а во-вторых при откате на CP “чистая” загрузка VM предпочтительнее;
  3. Чем больше  VM использует RAM, тем желательнее делать ее CP в выключенном состоянии;
  4. После восстановления CP сетевые соединения VM будут также сброшены, поэтому чем выше сетевая нагрузка VM, тем желательнее делать CP в выключенном состоянии;
  5. Если CP создаются для не выключенных VM, их лучше разместить на том же хранилище на котором расположены .vhd(x) файлы этих VM;
  6. Если VM работает в связке с другими VM (например AD DS и Exchange) то делать CP и восстанавливать нужно всю связку;
  7. CP не заменяют резервные копии, кроме сценария когда CP экспортируются;
  8. Начиная с Windows Server 2012 CP можно применять для контроллеров домена, за счёт использования VM-GenerationID.

Теперь, когда, как я надеюсь, вам понятна техническая сторона Checkpoint’ов разберёмся в каких случаях будем их применять, а в каких нет.

  • В средах, где нужно гарантировать и SLA, и функциональность Checkpoint’ов нужно предусмотреть это на этапе проектирования хранилища.
  • Для лабораторных задач и тестирования CP достаточно удобны, но не забывайте делать CP для всех “жёстко” связанных VM.
  • В нормальной продуктивной среде необходимости в Checkpoint’ах быть не должно. Описание грамотного процесса управления внесением изменений в продуктивную среду выходит за рамки этой статьи, но вы можете сделать CP, экспортировать их и импортировать в изолированную тестовую среду для проверки изменений, которые  вы собираетесь вносить в продуктивную среду.

В любом случае, CP лучше делать когда VM выключены.

Официальный материал на TechNet – https://technet.microsoft.com/ru-ru/library/dn818483.aspx

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.