Ever been confronted by a Hyper-V error box like this?
This one isn’t a great example because the error is pretty clear. But the above error box illustrates the sort of information that is returned from the management layers of the Hyper-V management OS (which runs in the parent partition). What does it all mean? Where does it come from?
Understanding Hyper-V Management
Take a wander over to MSDN to re-familiarise yourself with Hyper-V’s architecture. It’s always good to revisit and refresh yourself with how Hyper-V works because this information can make troubleshooting much easier.
See what the page calls the root partition? That’s actually the parent partition, where you’ve installed the host’s OS, which then became the management OS when:
- You enabled Hyper-V
- The physical machine rebooted
- The type 1 hypervisor slipped itself in between Windows Server and the hardware
Let’s focus on 3 pieces that run in User Mode in the management OS:
- WMI: Everything that you do to manage Hyper-V should go through the Hyper-V WMI. All the MSFT tools do this: Hyper-V Manager, Failover Cluster Manager, PowerShell, and VMM. 3rd party tools should do the same. Doing otherwise can … cause issues. WMI is the interface to managing Hyper-V and the VMs on the host.
- VMMS: The Virtual Machine Management Service … manages Hyper-V.
- VMWP: There is one Virtual Machine Worker Process for each running virtual machine. It’s a small process called VMWP.EXE. It’s involved with all sorts of things for managing the VM: taking part in Live Migration, managing the state transitions of the VM (start, stop, shutdown, etc), Dynamic Memory, and so on.
Each module produces its own information and logs it in the Windows event logs. Open up event viewer and browse to Applications And Service Logs > Microsoft > Windows and you can see a series of folders for Hyper-V components:
As Ben notes, Hyper-V-VMMS is the place to start looking when there’s a problem with Hyper-V. It gives us the WMI interface into Hyper-V. And Hyper-V-Worker is a good place to look if you’re troubleshooting anything to do with the responsibilities of a Worker Process.
Understanding The Error
What you see in the error box is an accumulation of information from several sources. In fact, you’ll find some of this text in the event logs. To demonstrate this, I have:
- Created a virtual machine with a VHDX file
- Deleted the VHDX file
- Attempted to start the virtual machine
Below, I have expanded the resulting error to see much more information:
Let’s start with the text blocks that are highlighted in red, working our way from the bottom one to the top. These are errors related to the VMWP-managed state transition of the VM. As a result, these text blocks are errors that are logged by the Worker Process in Hyper-V-Worker.
The bottom error, which was the first to be logged by the VMWP, is here:
Note that the text is identical. This continues with the subsequent VMWP text blocks & error log entries:
Now onto the text block that I’ve highlighted in green. That you can find in the Hyper-V-VMMS log:
Read from top to bottom, the story is:
- The virtual machine could not start
- The IDE controller had a problem
- The VHDX file could not be found
- The folder that the VHDX is supposed to be in is OK, but Hyper-V could not find the specified file
The Lessons To Learn
There are 3 things to pick up from this post:
- Get familiar with Hyper-V’s architecture. I’d expect a mechanic to know how an engine works, so a Hyper-V engineer should understand at least the basics of this subject.
- Understand that the error dialog presents information from various modules involved in the requested action.
- When confused, the Hyper-V-VMMS log is a pretty good place to start digging for treasure.