Под капотом: настройки реестра отключения Hyper-V

Копаться в реестре на компьютерах с Windows может быть рискованно, но вмешательство в реестр системы Windows Server может привести к остановке всей вашей сети. Тем не менее, бывают случаи, когда может быть полезно внести изменения непосредственно в реестр на сервере, например, чтобы настроить параметр, который не отображается в графическом интерфейсе, или включить какую-либо функцию, скрытую по умолчанию. В этой статье подробно описаны несколько интересных параметров реестра, связанных с завершением работы Hyper-V на хостах под управлением Windows Server 2012 и Windows Server 2012 R2. Эти параметры реестра возникли в ходе обсуждения с коллегами реальных ситуаций, с которыми они столкнулись, когда либо администрировали свои собственные среды Hyper-V, либо оказывали помощь в качестве консультантов клиентам, использующим Hyper-V в своих организациях. Надеемся, что некоторые из приведенных здесь историй могут оказаться полезными в ваших собственных ситуациях, связанных с Hyper-V. Как обычно, главного героя в этих двух несколько выдуманных историях зовут Боб.

Нет чистого отключения виртуальных машин

Боб пришел в замешательство. Он настроил свои виртуальные машины 1-го поколения с «Завершением работы гостевой операционной системы» в качестве действия автоматической остановки для каждой виртуальной машины, но по какой-то причине его виртуальные машины иногда не завершались корректно, когда он выключал Windows Server 2012 R2. хост, на котором они работали. Это стало очевидно, когда он перезапустил хост и обнаружил, что виртуальные машины необходимо перезапускать с нуля.

При дальнейшем изучении этой ситуации Боб обнаружил следующее событие в журнале системных событий на хосте:

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

Как долго Hyper-V ожидает корректного завершения работы виртуальной машины, прежде чем отключить ее? Значение по умолчанию для этого — 120 секунд, и оно хранится в следующем параметре реестра на хосте:

HKLMSoftwareMicrosoftWindows NTCurrentVersionVirtualizationShutdownTimeout

В итоге Боб увеличил значение ShutdownTimeout на своем хосте со 120 до 240 секунд, чтобы дать виртуальным машинам больше времени для завершения процесса выключения Hyper-V, чтобы они могли успешно завершить работу до того, как хост начнет процесс выключения. Однако это был скорее обходной путь, чем решение, поскольку он не смог определить причину, по которой виртуальные машины так долго выключались, когда хосту была выдана команда выключения. После дальнейшего исследования с помощью Performance Monitor Боб определил, что проблема была связана с подсистемой хранения на хосте, которая выступала в качестве узкого места, поскольку была перегружена операциями записи ввода-вывода, связанными с одновременным отключением всех виртуальных машин. После обновления подсистемы хранения на хосте для повышения производительности Боб смог восстановить исходное значение параметра ShutdownTimeout, и больше никаких проблем не возникало.

Кстати, изменения в указанном выше параметре реестра вступят в силу только в том случае, если вы перезагрузите хост.

СОВЕТ. У Altaro есть полезная статья о том, как использовать групповую политику для управления временем ожидания ShutdownTimeout на хостах Hyper-V.

Редукция выключения Hyper-V для кластерных хостов

Некоторое время спустя Боб столкнулся с аналогичной ситуацией, связанной с кластером хостов Hyper-V, где все узлы работали под управлением Windows Server 2012 R2. Проблема заключалась в том, что ему нужно было отключить один из узлов кластера для обслуживания, и он использовал Live Migration для переноса виртуальных машин с узла перед его выключением. При этом он обнаружил, что Live Migration не завершится до того, как узел начнет отключаться.

Заглянув еще немного внутрь, Боб обнаружил следующий параметр реестра на каждом узле хост-кластера:

HKLMClusterShutdownTimeoutInMinutes

По умолчанию значение этого параметра составляло 25 минут на каждой из его машин, что звучало как много времени, но, по-видимому, было недостаточно для завершения динамической миграции виртуальных машин на узле. Боб задался вопросом, почему присутствует это конкретное значение 25 минут, и нашел свой ответ в этой статье MSDN, в которой объясняется, что значение по умолчанию для параметра ShutdownTimeoutInMinutes определяется путем деления физической оперативной памяти в ГБ на 64 и умножения на 100.

Боб удвоил значение ShutdownTimeoutInMinutes на каждом узле до 50 минут. После этого Live Migration удалось завершить без проблем, а хост, который нуждался в обслуживании, можно было корректно отключить и обслужить. И снова изменение этого параметра реестра вступило в силу только после того, как Боб перезагрузил узлы в кластере.

В дополнение к рассказу Боба можно спросить, почему он не сохранил состояние виртуальных машин, а выключил их? Интересно, что ответ заключается в том, что сохранение состояния виртуальной машины часто занимает больше времени, чем ее выключение. Например, если у вас есть хост-кластер с 128 ГБ ОЗУ на каждом узле, а файлы виртуальных машин хранятся в сети SAN, то сохранение виртуальных машин означает, что в вашей сети хранения данных выполняется множество операций копирования файлов, что в конечном итоге может занять значительное время. количество времени. Но если вы просто выключите все виртуальные машины, то это будет происходить в основном параллельно, и единственная информация, которая будет записана в хранилище, — это информация о состоянии виртуальной машины, которая еще не была зафиксирована в хранилище, и этот процесс обычно выигрывал. не займет много времени, чтобы завершить. И, конечно же, могут возникнуть проблемы, если вы попытаетесь сохранить состояние виртуальной машины, функционирующей как контроллер домена, как объясняется во второй статье от Altaro.