Q: How do I enable theFailover Cluster Hyper-V virtual machine monitoring capability?
A: Windows Server 2012 Failover Cluster introduces a new capability for Hyper-V virtual machines (VMs), which is a basic monitoring of a service within the VM which causes the VM to be rebooted should the monitored service fail three times. For this feature to work the following must be configured:
- Both the Hyper-V servers must be Windows Server 2012 and the guest OS running in theVM must be Windows Server 2012.
- The host and guest OSs are in the same or at least trusting domains.
- The Failover Cluster administrator must be a member of the local administrator's group inside the VM.
Ensure the service being monitored is set to Take No Action (see screen shot below) within the guest VM for Subsequent failures (which is used after the first and second failures) and is set via the Recovery tab of the service properties within the Services application (services.msc).
Within the guest VM, ensure the Virtual Machine Monitoring firewall exception is enabled for the Domain network by using the Windows Firewall with Advanced Security application or by using the Windows PowerShell command below:
Set-NetFirewallRule -DisplayGroup "Virtual Machine Monitoring" -Enabled True
After the above is true, enabling the monitoring is a simple process:
- Launch the Failover Cluster Manager tool.
- Navigate to the cluster - Roles.
- Right click on the virtual machine role you wish to enable monitoring for and under More Actions select Configure Monitoring...
The services running inside the VM will be gathered and check the box for the services that should be monitored and click OK.
- You are done!
Monitoring can also be enabled using the Add-ClusterVMMonitoredItem cmdlet and -VirtualMachine, with the -Service parameters, as the example below shows:
PS C:\Windows\system32> Add-ClusterVMMonitoredItem -VirtualMachine savdaltst01 -Service spooler
After two service failures, an Event ID 1250 is logged in the System log. At this point, the VM will be restarted, initially on the same host, but on subsequent failure it will restart on another node in the cluster. This process can be seen in the video below at either my website video or at this YouTube video.