Правильное объединение снимков осуществляется через их удаление в консоли управления Hyper-V от самого старого к самому новому и перезагрузкой виртуальной машины. Если по каким-то причинам сделать это не возможно, то потребуется объединять снимки вручную.
Перед тем как приступать к каким-либо действиям, сделайте резервную копию виртуальной машины.
- Изменяем расширение снимков виртуальной машины с *.avhd на *.vhd;
- Щёлкаем правой кнопкой мыши по гипервизору в диспетчере и открываем оснастку "Изменить диск" / "Edit Disk";
- Далее кнопкой "Обзор" выбираем снимок сделанный позже всего (самый свежий снимок);
- Указываем "Объединить" / "Merge"; Щёлкаем по "К родительскому виртуальному диску";
- Потом открывается информационное окно, в котором будет виден родитель объединяемого файла.
- Нажимаем "Готово" и процесс слияния будет запущен.
Если снимков несколько — повторите теже самые действия.
Авторские права © защищены и принадлежат Компании "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 происходит следующее:
- Виртуальная машина ставится на паузу
- Создаётся .avhd(x) файл
- Сохраняется резервная копия конфигурации (.xml)
- В конфигурацию вносятся изменения (подключается .avhdx файл)
- Виртуальная машина запускается
- Содержимое R AM сохраняется в Saved state файлы. Если в это время ОС пытается произвести запись в блоки R AM которые ещё не были сохранены, запросы перехватываются и результаты сохраняются.
- Checkpoint готов.
Пауза на шаги 1-5 действительно небольшая:
А вот сохранение содержимого ОЗУ в Saved state файлы и занимает основное время .
Процессы применения и удаления Checkpoint’ ов я думаю интуитивно понятны, поэтому пойдём дальше.
Экспорт Checkpoint – одна из редко используемых, но действительно полезных функций.
Вы можете сделать экспорт CP, а затем импортировать его на другом хосте.
При этом имя импортированной VM будет соответствовать имени CP:
Вы можете автоматизировать создание CP запуская что-то подобное из Task Scheduler:
Если вы хотите использовать более “говорящие” имена, воспользуйтесь возможностями SnapshotName, вот пример для ежедневных:
.. и ежечасных Checkpoint’ ов:
Выглядит это следующим образом:
Автоматически удалять Checkpoint’ ы можно вот так (в примере я удаляю те, которые старше 5 дней):
Вот пример командлета, который удалит Checkpoint’ ы которые старше одного часа:
Но не всегда время создания Checkpoint’a является фактором на основе которого принимается решение об удалении.
Например, вам может понадобится удалить все Checkpoint’ ы в имени которых содержится test , но оставить все остальные, не зависимо от их возраста :
Давайте подведём итоги:
- CP снижают производительность не только дисковой подсистемы VM, но и производительность хранилища – причём чем больше CP, тем больше снижается производительность;
- Создание CP для VM в выключенном состоянии предпочтительнее, т.к. Во-первых не будет расходов места на запись RAM, а во-вторых при откате на CP “чистая” загрузка VM предпочтительнее;
- Чем больше VM использует RAM, тем желательнее делать ее CP в выключенном состоянии;
- После восстановления CP сетевые соединения VM будут также сброшены, поэтому чем выше сетевая нагрузка VM, тем желательнее делать CP в выключенном состоянии;
- Если CP создаются для не выключенных VM, их лучше разместить на том же хранилище на котором расположены .vhd(x) файлы этих VM;
- Если VM работает в связке с другими VM (например AD DS и Exchange) то делать CP и восстанавливать нужно всю связку;
- CP не заменяют резервные копии, кроме сценария когда CP экспортируются;
- Начиная с 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
Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.
