"Попереднє стан" включає в себе вміст vHDD, vRAM і конфігурації ВМ.
Максимальна кількість Checkpoint 'ов (далі CP) - 50. При спробі зробити 51й CP ви отримаєте таку помилку:
Ви можете змінити розташування з консолі 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:
Давайте підіб'ємо підсумки:
Тепер, коли, як я сподіваюся, вам зрозуміла технічна сторона Checkpoint'ов розберемося в яких випадках будемо їх застосовувати, а в яких ні.
- У середовищах, де потрібно гарантувати і SLA, і функціональність Checkpoint'ов потрібно передбачити це на етапі проектування сховища.
- Для лабораторних завдань і тестування CP досить зручні, але не забувайте робити CP для всіх "жорстко" пов'язаних VM.
- У нормальній продуктивної середовищі необхідності в Checkpoint'ах бути не повинно. Опис грамотного процесу управління внесенням змін до продуктивне середовище виходить за рамки цієї статті, але ви можете зробити CP, експортувати їх і імпортувати в ізольовану тестову середу для перевірки змін, які ви збираєтеся вносити в продуктивне середовище.
У будь-якому випадку, CP краще робити коли VM вимкнені.
Сподіваюся озвучена інформація буде корисною, а якщо потрібна буде допомога - використовуйте форму на головній сторінці мого сайту.