Hyper-V Quick Tip: Nested Hyper-V VM Fails to Load Network and Mouse

Q: I enabled nested virtualization for a previously functional Hyper-V virtual machine, but now it doesn’t have network connectivity and I cannot use the mouse inside the console. What happened and how can I fix it?

So, you’ve decided to kick the tires on nested virtualization, but it seems like just the act of enabling the processor feature caused the guest to break. You know that the virtual machine worked just fine prior to making that switch, and you haven’t even enabled Hyper-V in the guest yet!

Known symptoms:

• Synthetic network adapters do not function; the virtual machine has no network connectivity
• You cannot use the mouse in the Hyper-V console
• Enhanced session services do not function
• In Device Manager, the status for “Microsoft Hyper-V Virtual Machine Bus” has a problem. The exact code may vary. I have seen:
  • Code 10 (This device cannot start)
  • Code 39 (Windows cannot load the device driver for this hardware. The driver may be corrupted or missing)

All of these symptoms point to a single problem: VMBus won’t start. Without VMBus, a Hyper-V virtual machine becomes a minimally-capable system. No synthetic devices, no mouse, etc.

A. Ensure that your Hyper-V host operating system upgrade level is at least as recent as your virtual machine.

I am equivocating somewhat on the usage of the term “upgrade level”. You do not necessarily need to be at the same build level. Your host just needs to be able to expose virtualization feature sets that are new enough to not cause problems for the guest’s VMBus. As much as I’d like to give you a certain way to predict that, I’m not sure that any foolproof way exists (other than for Microsoft’s teams to include something in patch notes).

Regardless of any other condition, the underlying cause for all of these symptoms is that Hyper-V in the host cannot properly communicate with the integration services/components in the guest. In the past, we’d have you check that you had installed the integration services and reinstall if necessary. Now, of course, all supported operating systems ship with at least a basic level of these components and usually have at least basic acceleration features.

However, the onset of rapid release cycles and open membership in the Insiders’ programs have changed things, sometimes dramatically. Usually, we still get enough functionality to prevent the above symptoms, even when versions don’t match well. However, enabling exposure of virtualization features makes a more fundamental change that  In my case, I was running an Insider build of Windows 10 (build 17127) on top of the normal LTSC Windows Server 2016. It worked fine when I started it on a host running a recent Insider build of Windows Server (17709).

Note: You can Live Migrate a virtual machine in this condition, but it will not automatically correct the problem. The normal techniques used to start a driver in a running Windows session did not work for me, either. You will still need to power cycle the virtual machine.

Have you experienced this problem but found a different solution? Let us know in the comments below!

More Hyper-V Quick Tips from Eric

Safely Shutdown a Guest with Unresponsive Mouse

How Many Cluster Networks Should I Use?

How to Choose a Live Migration Performance Solution

How to Enable Nested Virtualization