Hyper-V Guests Improperly Shut Down when Host is Restarted

Question

I have a Server 2019 Hyper-V host which has two Windows Server guest VMs. Both VMs are configured to shut down when the host shuts down:

However, any time the Host is restarted or shut down, the guest OSes experience an unexpected shutdown and record event ID 6008 in the System event log ("The previous system shutdown at 2:11:33 PM on ‎7/‎26/‎2019 was unexpected"). When the shutdown process begins on the Hyper-V host, the following events are immediately logged to the Microsoft-Windows-Hyper-V-VMMS/Admin log:

Event ID:  14100
Logged:    7/26/2019 2:11:46 PM
Source:    Hyper-V-VMMS
Text:      Shut down physical computer. Stopping/saving all virtual machines...

Event ID:  19060
Logged:    7/26/2019 2:11:46 PM
Source:    Hyper-V-VMMS
Text:      <VM NAME #1> failed to perform the 'Shutting Down' operation. The virtual machine is currently performing the following operation: 'Shutting Down'. (Virtual machine ID <VM #1 GUID>)

Event ID:  19060
Logged:    7/26/2019 2:11:46 PM
Source:    Hyper-V-VMMS
Text:      <VM NAME #2> failed to perform the 'Shutting Down' operation. The virtual machine is currently performing the following operation: 'Shutting Down'. (Virtual machine ID <VM #2 GUID>)

What's strange about these events is:

1. There's no gap of time between the "stopping/saving VMs" event and the subsequent "VM failed to shut down" events.
2. They're logged within seconds of the VM reporting when it was unexpectedly shut down.

Why is this happening and what can I do about it?

Changing the VM shutdown options to Save or Turn off are not an option in this environment. I doubt it matters, but the guest VMs are running Server 2008 R2 and Server 2016.

Solution

This is a known issue and a fix is purportedly planned for September 2019

According to this post in the Microsoft Hyper-V server forum, this is a known issue in Windows Server 2019. The thread starter describes the same circumstances that you have, including the event text:

'ADFS' failed to perform the 'Shutting Down' operation. The virtual machine is currently performing the following operation: 'Shutting Down'.

According to the poster "simdoc," Microsoft is aware of this issue:

I opened a premier support request on this. It took them several weeks to reproduce it because they had limited access to physical servers (seems like that should be improved for Hyper-V issues). The bottom line is I was told they would fix this in the August update. (Posted by user "simdoc" on Monday, July 1, 2019 2:29 PM)

The poster "Nicolas Rojas," who is identified as an employee of Microsoft indicates the fix will be released in September 2019:

A fix for this issue Host shutdowns unexpectedly turns VMs off when configured to shutdown on a WS 2019 host is planned to release in September 2019 update package for Windows Server 2019. (Posted by "Nicolas Rojas Microsoft" on July 4, 2019 3:13 PM)

---

In the meantime I suggest you reconsider using the "Save" option for VMs on shutdown of the Hyper-V Host or manually (e.g. via script) shut down the VMs before planned restarts of the host. Any of these options have to be better than letting the VMs have their power cut without warning.

Comments

[Eric Siron]

I gave you an upvote but I advise caution on the thinking that "Any of these options have to be better than letting the VMs have their power cut". After resuming from a saved state, the VM knows nothing except that its clock has changed. In-flight operations proceed like nothing ever happened. Some things, especially servers that belong to a multi-tier system, do better at recovering from known failure. Until we get a fix, it's best to script or manually control the shut down cycle.

[I say Reinstate Monica]

Good advice. Obviously it will be up to each admin to determine what's best for their specific environment as your comment elucidates.

[Rasmus]

I just did a fresh installation of Hyper-V 2019 Server released as the September update. Today (18/10-19) i experienced vm unexpected shutdowns after the host was bootet. So it dosnt seem to have been fixed yet (?).