Как удалить контрольные точки hyper v

Правильное объединение снимков осуществляется через их удаление в консоли управления Hyper-V от самого старого к самому новому и перезагрузкой виртуальной машины. Если по каким-то причинам сделать это не возможно, то потребуется объединять снимки вручную.

Перед тем как приступать к каким-либо действиям, сделайте резервную копию виртуальной машины.

1. Изменяем расширение снимков виртуальной машины с *.avhd на *.vhd;
2. Щёлкаем правой кнопкой мыши по гипервизору в диспетчере и открываем оснастку "Изменить диск" / "Edit Disk";
3. Далее кнопкой "Обзор" выбираем снимок сделанный позже всего (самый свежий снимок);
4. Указываем "Объединить" / "Merge"; Щёлкаем по "К родительскому виртуальному диску";
5. Потом открывается информационное окно, в котором будет виден родитель объединяемого файла.
6. Нажимаем "Готово" и процесс слияния будет запущен.

Если снимков несколько — повторите теже самые действия.

Авторские права © защищены и принадлежат Компании "Sky"
SKY — IT-решения для бизнеса, 2012–2019 г.

Hyper-V: не удаляется контрольная точка.

Недавно обнаружил , что у одной из виртуальных машин Hyper-V есть контрольная точка, которую я не создавал. Такое иногда бывает при резервном копировании ВМ.

Данная контрольная точка была видна только в оснастке Hyper-V на хосте, в консоли SCVMM ее не было видно.

При попытке удалить эту контрольную точку стандартными средствами, обнаружил, что в меню нет пункта «Удалить».

Для удаления подобной контрольной точки microsoft советует следующее, но, как оказалось, удалить ее можно с помощью Powershell. Чтобы удалить контрольную точку, не потребовалось даже выключать виртуальную машину.

Для удаления контрольной точки в окне Powershell вводим:

Get-VMSnaphot -VMName | Remove-VMSnapshot

Начнется слияние диска:

После его завершения, контрольная точка будет удалена.

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

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

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

По-умолчанию, в Windows Server 2012R2 CP хранятся в папке %systemroot%ProgramDataMicrosoftWindowsHyper-VSnapshots

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

Когда вы создаёте 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 относительно читабельно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автоматически удалять 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

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