Windows Server 2019 vs. VMware Snapshots with quiescing: элегантное решение проблемы

Привет!

У виртуальных машин Windows Server 2019 с эмуляцией EFI на VMware есть проблема с Application-Aware снапшотами. Выглядит это так: снапшот делается, доходит до 100%, висит минут 5, а потом вываливается в ошибку Failed to quiesce the virtual machine.
 

Расследование показало, что причина такой ошибки – конфликт службы VSS Windows Server 2019 и VMware Snapshot Provider, который и отвечает за application quiescing. Эта штука готовит виртуальную машину к снапшоту: останавливает работу приложений и операции записи, чтобы после восстановления из снапшота все данные были консистентны.

Microsoft утверждал и утверждает, что Application-Aware Snapshots прекрасно поддерживаются ОС. Действительно, в Hyper-V такой проблемы не возникает. VMware скромно предложила своим пользователям просто выключить quiescing (ну и что, что снапшот не будет консистентным на уровне приложения). Либо отказаться от системных дисков с GPT-разметкой и эмуляции EFI (в 2020-м году!). 

Сегодня я покажу, как красиво обойти эту проблему и получить консистентный application-aware snapshot виртуальных машин Windows Server 2019, и заодно напомню поддерживаемый Microsoft способ установки Windows Server на виртуальную машину.

Кто виноват?

Начнем с начала. При создании виртуальной машины на VMware ESXi в VM Options по умолчанию стоит эмуляция BIOS. И, пока нет особых требований по безопасности или размеру системного диска, такой сценарий вполне уместен. Но как только нам нужно настроить Secure Boot или количество vCPU превышает 128, потребуется создавать ВМ с эмуляцией UEFI. Хотя бы потому, что там есть:

• Secure Boot – защита от загрузки с посторонних носителей.
• Поддержка шифрования (требуется поддержка TPM, но в ESXi 6.7 та же беда).
• Поддержка дисков свыше 2ТБ (сомнительно, но бывает).
• Поддержка большого числа процессоров.

Если устанавливать Windows на ВМ VMware, как мы привыкли это делать (создаем ВМ, подсовываем ISO, ручками грузимся, next, next...), то при GPT-разметке системного диска рядом с EFI-разделом и разделом с системой появляется раздел Recovery.

Вспоминаем матчасть:

Раздел Recovery – защищенный раздел на системном жестком диске, который используется для восстановления заводских настроек системы в случае проблем. При установке Windows Server на GPT-диск в Recovery записывается среда Windows Recovery Environment (WinRE). Производители компьютеров, как правило, дополняют этот раздел своими кастомными настройками и драйверами, заточенными под конкретное железо.

Стоп! 

Но мы же не с железом работаем, а с виртуальной машиной. Никаких откатов ни на какие заводские настройки не требуется. В конце концов, если нужно вернуть ВМ в исходное состояние, мы ее просто переразворачиваем. Следовательно, раздел Recovery на ВМ не имеет смысла и не особенно нужен.

Раздел Recovery защищен от изменения и случайного удаления: он «не замораживается». В результате между VSS VMware Snapshot Provider и Microsoft Windows VSS возникает конфликт: провайдер VMware пытается сделать снапшот всех разделов диска, а Windows Server не дает ему это сделать. Эту радостную новость нам сообщают логи:

Что делать?

Лечится это просто. Можно устанавливать Windows на ВМ с помощью командлета Convert Windows Image. Собственно, именно такой сценарий установки рекомендует и поддерживает сам Microsoft (этот скрипт есть на RTM образе Windows Server 2016 в каталоге с образом Nano Server, но это другая и не менее интересная история ;) ).

Скрипт автоматически создаст шаблон с обновленной sysprepped Windows Server, необходимыми драйверами и даже ролями. Такой подход интересен тем, что процесс установки и настройки ОС можно автоматизировать, так как скрипт поддерживает unattend.xml. Кроме того, этот вариант предоставляет свободу для инженерного творчества: от предварительного запуска ВМ на Hyper-V с установкой через Invoke-Command до создания кастомного сервиса через правку реестра. 

На выходе у нас получится толстый VHD-диск, который можно подсунуть VMware, запустить ВМ, поставить VMware Tools и сконвертировать в шаблон. В результате у ВМ будет GPT-разметка внутри, пригодная для запуска на EFI ВМ и без Recovery раздела by design. В качестве бонуса: в моем примере я сразу создам паравиртуальный адаптер для обеспечения перфоманса. А главное – для такой виртуальной машины без проблем можно будет сделать application-aware снапшот.

Теперь все подробно по шагам.

Извлечение драйверов

1. Скачиваем образ с репозитория.
2. Монтируем образ.

   

3. Запускаем cmd.exe и переходим в корень смонтированного образа
4. Запускаем установщик с ключиками:

   setup64.exe /A /P <целевой каталог распаковки>

5. На втором шаге мастера повторяем путь для распаковки:

   

6. Драйверы лежат здесь: VMWToolsExtractVMwareVMware ToolsVMwareDrivers

Подготовка обновлений Windows Server 2019

1. Скачиваем кумулятивные обновления отсюда. Там же найдете подробное описание патча и известных проблем, которые в нем имеются.
2. Важно: обновление может потребовать дополнительного обновления Servicing Stack Update. Смотрим раздел How to get this update и находим номер обновления, которое мы должны скачать через MS update catalog:

   

3. Скачиваем Windows Server 2019 Cumulative Update и Servicing Stack Update.

   

   

4. Открываем полученные файлы архиватором и извлекаем CAB-файлы с номером обновления:

   

Установка образа

1. Запускаем PowerShell с повышенными привилегиями.
2. Устанавливаем модуль

   Install-Module -Name Convert-WindowsImage

3. Создаем хэш-таблицу для Convert-WindowsImage:

   $ConvertWindowsImageParam = @{
   	# Путь к образу Windows Server 2019
   	SourcePath = "C:worken_windows_server_2019.iso"
   	# Формат виртуального диска
   	VHDFormat = "VHD"
   	# Размер Виртуального диска
   	SizeBytes = 40GB
   	# Разметка диска - GPT
   	DiskLayout = "UEFI"
   	BCDinVHD = "VirtualMachine"
   	# Тип виртуального диска
   	DiskType = "Fixed"
   	# Редакция - Windows Server 2019 Standard (Desktop Expirience)
   	<#
   	Номера редакций:
   	1 - Windows Server 2019 Standard (Core)
   	2 - Windows Server 2019 Standard (Desktop Expirience)
   	3 - Windows Server 2019 Datacenter (Core)
   	4 - Windows Server 2019 Datacenter (Desktop Expirience)
   	#>
   	Edition = @("2")
   	# Включение Remote Desktop
   	RemoteDesktopEnable = $True
   	# Установка дополнительных компонентов
   	Feature = @("TelnetClient","WindowsServerBackup","NetFx3")
   	# Установка обновлений (указать путь к распакованным файлам CAB)
   	# Обновления должны быть указаны в порядке установки: сначала SSU, затем кумулятивный
   	Package = @("C:workWindows10.0-KB4523204-x64.cab","C:workWindows10.0-KB4534321-x64_PSFX.cab")
   	# Путь к каталогу с драйверами
   	Driver = @("C:workVMWToolsExtractVMwareVMware ToolsVMwareDrivers")
   	}

4. Запускаем установку Windows Server 2019 и идем пить кофе:

   Convert-WindowsImage @ConvertWindowsImageParam

   

   

Установка занимает до 30 минут.

В данном примере на выходе получается полностью подготовленная ОС в состоянии Sysprepped, но ничто не мешает нам использовать для кастомизации Unattend.xml (Customization specifications немного озадачиваются при виде sysprep-шаблона и ВМ не разворачивается).

Подробнее о ключах этого замечательного кмдлета тут и в Get-Help самого кмдлета.

После этого можно загрузить диск на ESXi, создать ВМ и поставить VMware Tools. И разворачивать виртуальные машины, не беспокоясь о проблемах с quiescing snapshots.

А что делать, если уже есть “дефектный” шаблон?

Достаточно просто удалить раздел Recovery через diskpart.exe и подвинуть разделы EFI и системы для красоты разметки (но можно и не делать этого). Поддерживается ли это? На виртуальной машине – безусловно!

1. Запускаем cmd.exe.
2. Запускаем diskpart.
3. Получаем список дисков:

   list disk

4. Выбираем диск:

   select disk n

   где n – номер диска.

5. Выводим список разделов:

   list partition

6. Смотрим номер раздела Recovery (n) и выбираем его:

   select partition n

7. Снимаем защиту с раздела:

   gpt attributes=0x8000000000000000

8. Удаляем:

   delete partition

9. Profit!

ВМ готова к Quescing Snapshots!

Вместо заключения

Данный подход — лишь один из вариантов деплоя Windows Server и решения проблемы KB60395. Разумеется, в данном случае мы можем сделать тонкий VDH и затем с помощью утилиты quemu-img сконвертировать виртуальный диск для OVF-архива, который ESXi прекрасно понимает. Такой сценарий вполне уместен, например, в случае, когда виртуальный диск нужно передать по сети. Понимание истории вопроса и настоящей сути проблемы всегда дает возможность найти подходящее для конкретной инфраструктуры решение. Техническая реализация — поле для интересных экспериментов и фантазии, которая безгранична.

Автор: Евгений Парфенов

Источник