Although Microsoft’s System Center Virtual Machine Manager (VMM) is generally a reliable platform for managing an organization’s virtualization infrastructure, you may occasionally encounter a situation in which a Hyper-V host is listed as “Not Responding.” When this happens, there are several things that you can do to fix your unresponsive Hyper-V host.
Verify that the host is functional
The first step in resolving the problem is to take a step back and make sure that the Hyper-V host is functional. While this might sound odd, the goal behind this step is to definitively determine whether the Hyper-V host is having problems or if VMM is merely having issues with managing the host.
The easiest way to check the host is to connect to the problem host using Hyper-V Manager (PowerShell can also be used). Try viewing a virtual machine’s settings. See if you can create, start, stop, and delete a virtual machine. If you can do those things, then the Hyper-V host is more than likely OK, and it’s actually VMM that is experiencing problems. If, on the other hand, you find that the host truly is unresponsive, you should reboot the host and begin troubleshooting Hyper-V if necessary.
Look for clues within VMM
If you confirm that the Hyper-V host is functioning as intended, then the next step is to look for clues within VMM that will point to the source of the problem. This is easier to do than it sounds.
To get started, open the Fabric workspace within the VMM Administrator console. Next, right-click on the Hyper-V host that you are having problems with and select the Properties command from the shortcut menu, as shown in the image below.
When the host’s properties sheet appears, select the properties sheet’s Status tab. The Status tab shows a hierarchical health status chart. This chart will typically tell you what is causing the Hyper-V host to be reported as unhealthy. For example, in the next image, this particular host has not become unresponsive, but there is a warning message listed on the health status chart because the VMM agent running on the host is outdated.
Check WinRM
My experience has been that when VMM has trouble communicating with a Hyper-V host, the problem is often related to WinRM. Make sure that TCP ports 5985 and 5986 haven’t been blocked on the Hyper-V machine. You can also verify that the WinRM listener is functioning by opening PowerShell on the Hyper-V host and entering the following command:
WinRM Enumerate Winrm/config/listener
You can see what this looks like in the image below.
Another thing that can sometimes happen is that the process that is running WinRM can have problems. If you suspect that to be the case, you can move WinRM into a dedicated process. The command used for doing so is:
Sc config winrm type=own
As you can see in the next screenshot, this command needs to be run within a command prompt window, not PowerShell.
If you continue to have problems with WinRM, Microsoft recommends increasing the default values on your Hyper-V host. Here are Microsoft’s commands used for doing so:
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"}
These commands will need to be entered into a command prompt window, but there is also one PowerShell command that you will need to enter:
set-item "WSMan:\localhost\Plugin\WMI Provider\Quotas\MaxConcurrentOperationsPerUser" 400
Be sure to restart WinRM and WMI after entering these commands or to reboot the server.
Although WinRM is often the culprit when VMM incorrectly reports a Hyper-V host as being unresponsive, there are other potential causes. One of the most common causes is that the virtual machines running on the host have consumed too many hardware resources, thus depriving the host operating system and the VMM agent of the resources they need.
It can sometimes be tough to know the amount of hardware resources that can safely be consumed by virtual machines running on a Hyper-V host. There is a fine line between maximizing your virtual machine density and consuming so many resources that the host operating system begins to have problems. One potential option is to look at the Windows Server system requirements and make sure that you reserve slightly more resources for the host OS than those listed within the system requirements as being required for Windows.
I have also seen a Hyper-V host become sluggish or completely unresponsive because the host server was low on disk space. When managing a Hyper-V server, there is a natural tendency to focus on the storage space that is being consumed by the virtual machines. Most of the time, however, virtual machines reside on a cluster shared volume (or at least on a dedicated RAID array or Windows storage space) and not on the C: drive. If the C: drive begins to run low on space, the host can start behaving erratically or even cease to function.
Still have unresponsive Hyper-V? Check service accounts
I know of one more problem that can cause a Hyper-V host to become unresponsive to Virtual Machine Manager. Virtual Machine Manager relies on the use of service accounts. If the service account that VMM is using has been removed from the Hyper-V host’s local administrators group, it can cause Virtual Machine Manager to become unable to interact with the Hyper-V host server. Similar problems can occur if the agent is manually removed from the Hyper-V host because the Virtual Machine Manager server will think it has simply lost the ability to communicate with the host.
Featured image: Shutterstock
