Устранение неполадок с не отвечающим хостом Hyper-V с помощью VM Manager

Хотя Microsoft System Center Virtual Machine Manager (VMM) обычно является надежной платформой для управления инфраструктурой виртуализации организации, иногда вы можете столкнуться с ситуацией, когда хост Hyper-V указан как «Не отвечает». Когда это происходит, вы можете сделать несколько вещей, чтобы исправить не отвечающий хост Hyper-V.

Убедитесь, что хост работает

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

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

Ищите подсказки в VMM

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

Чтобы начать работу, откройте рабочую область Fabric в консоли администратора VMM. Затем щелкните правой кнопкой мыши хост Hyper-V, с которым у вас возникли проблемы, и выберите команду «Свойства» в контекстном меню, как показано на изображении ниже.

Когда появится лист свойств хоста, выберите вкладку Статус листа свойств. На вкладке «Состояние» отображается иерархическая диаграмма состояния работоспособности. На этой диаграмме обычно указывается причина, по которой узел Hyper-V считается неработоспособным. Например, на следующем изображении этот конкретный узел не перестает отвечать на запросы, но в диаграмме состояния работоспособности отображается предупреждающее сообщение, поскольку агент VMM, работающий на узле, устарел.

Проверить WinRM

По моему опыту, когда у VMM возникают проблемы со связью с хостом Hyper-V, проблема часто связана с WinRM. Убедитесь, что TCP-порты 5985 и 5986 не заблокированы на машине Hyper-V. Вы также можете убедиться, что прослушиватель WinRM работает, открыв PowerShell на узле Hyper-V и введя следующую команду:

WinRM Enumerate Winrm/config/listener

Вы можете увидеть, как это выглядит на изображении ниже.

Еще одна вещь, которая иногда может случиться, заключается в том, что процесс, в котором работает WinRM, может иметь проблемы. Если вы подозреваете, что это так, вы можете переместить WinRM в выделенный процесс. Для этого используется команда:

Sc config winrm type=own

Как видно на следующем снимке экрана, эту команду нужно запускать в окне командной строки, а не в PowerShell.

Если у вас по-прежнему возникают проблемы с WinRM, Microsoft рекомендует увеличить значения по умолчанию на вашем узле Hyper-V. Вот команды Microsoft, используемые для этого:

Winrm quickconfig winrm set winrm/config @{MaxTimeoutms="1800000"} winrm set winrm/config/Service @{MaxConcurrentOperationsPerUser="1500"} winrm set winrm/config/winrs @{MaxConcurrentUsers="100"} winrm set winrm/config /winrs @{MaxProcessesPerShell="100"} winrm set winrm/config/winrs @{MaxShellsPerUser="100"}

Эти команды нужно будет ввести в окно командной строки, но есть и одна команда PowerShell, которую вам нужно будет ввести:

set-item "WSMan:localhostPluginWMI ProviderQuotasMaxConcurrentOperationsPerUser" 400

Обязательно перезапустите WinRM и WMI после ввода этих команд или перезагрузите сервер.

Хотя WinRM часто является виновником, когда VMM неправильно сообщает, что хост Hyper-V не отвечает, существуют и другие возможные причины. Одна из наиболее распространенных причин заключается в том, что виртуальные машины, работающие на узле, потребляют слишком много аппаратных ресурсов, что лишает операционную систему узла и агент VMM необходимых им ресурсов.

Иногда бывает сложно определить объем аппаратных ресурсов, которые могут безопасно потребляться виртуальными машинами, работающими на узле Hyper-V. Существует тонкая грань между максимизацией плотности вашей виртуальной машины и потреблением такого количества ресурсов, при котором у операционной системы хоста начинаются проблемы. Один из возможных вариантов — просмотреть системные требования Windows Server и убедиться, что вы зарезервировали немного больше ресурсов для хост-ОС, чем указано в системных требованиях как требуемых для Windows.

Я также видел, как хост Hyper-V становился вялым или полностью переставал отвечать, потому что на хост-сервере было мало места на диске. При управлении сервером Hyper-V существует естественная тенденция сосредотачиваться на пространстве хранения, используемом виртуальными машинами. Однако большую часть времени виртуальные машины находятся на общем томе кластера (или, по крайней мере, на выделенном массиве RAID или в хранилище Windows), а не на диске C:. Если на диске C: заканчивается свободное место, хост может начать работать хаотично или даже перестать функционировать.

Все еще не отвечает Hyper-V? Проверить сервисные аккаунты

Я знаю еще об одной проблеме, из-за которой хост Hyper-V перестает отвечать на запросы диспетчера виртуальных машин. Диспетчер виртуальных машин использует учетные записи служб. Если учетная запись службы, которую использует VMM, была удалена из группы локальных администраторов узла Hyper-V, это может привести к тому, что диспетчер виртуальных машин не сможет взаимодействовать с сервером узла Hyper-V. Аналогичные проблемы могут возникнуть, если агент вручную удален с хоста Hyper-V, потому что сервер Virtual Machine Manager решит, что он просто потерял возможность связи с хостом.