VMBus fails to load (device cannot find enough free resources Code 12) on a Windows Server 2008 x86 virtual machine under Hyper-V

There is one particular scenario where you could be faced with this when booting a VM using Hyper-V. The most obvious way you can immediately notice it is that when using Virtual Machine Connection to remotely control a virtual machine, you do not have mouse integration.

(Note that in Windows Server 2008 RTM, Hyper-V Beta integration components are in-box. You will see similar lack of mouse integration on future releases of Hyper-V where you have updated the physical machine but not updated the virtual machine image. Once we have a new release of Hyper-V available, I’ll post more on that.)

The issue is very specific to where you have a Windows Server 2008 x86 (not x64) virtual machine originally built using Virtual PC or Virtual Server.  It should not apply to Windows Vista SP1 (currently not supported in Hyper-V Beta). Opening Device Manager (Start devmgmt.msc) inside the virtual machine will provide the first sign that you are hitting the issue. As you can see in the screenshot below, under the Computer node, it says “Advanced Configuration and Power Interface (ACPI) PC”.

1

If you scan further down Device Manager to the bottom of the “System Devices” and double-click on VMBus (which has a yellow exclamation mark against it), you will see in the device status area that the device cannot find enough free resources that it can use. (Code 12).

2

The reason for this is similar to the issues stated in yesterdays blog post about having the correct HAL installed. For VMBus and other components necessary for synthetic device support in Hyper-V to load correctly, the HAL running in the virtual machine must be an APIC HAL. Fortunately, Windows Vista and Windows Server 2008 have a new boot option to force HAL detection during boot, which is off by default. The easiest way (command line junkies excused) to change this setting is through the “msconfig.exe” tool. If you select the boot tab and then hit advanced, you’ll notice a checkbox marked “Detect HAL”. After selecting this checkbox and hitting OK, you must reboot the virtual machine.

3

Once the virtual machine is restarted, open up device manager again. This time you will notice that under the computer node, it now reads “ACPI x86-based PC”.

4

A few final comments. First, the “Detect HAL” checkbox is sticky, and causes boot to be very slightly longer (so slight in fact, I can’t notice a difference using a stop-watch). If you do not intend returning this virtual machine back to Virtual Server or Virtual PC, you could turn the checkbox off and reboot.

To clear up a point from my previous post, I said that “In theory it is possible to swap the HAL, but not in a Microsoft supported manner (except on Vista and Windows Server 2008 – that’s a post for another day)”. Hopefully that is a little clearer now. You may be wondering, if you clear the checkbox, and while the virtual machine is configured with an APIC HAL, what happens if you take the VHD back to Virtual Server or Virtual PC?  In this case, the boot will not complete, even in safe mode. The way to resolve this is to ensure the check box for Detect HAL is checked before shutting down the virtual machine under Hyper-V. 

You can also set or clear the checkbox in a slightly smarter way if you don’t have a Hyper-V machine available to boot the virtual machine to toggle the checkbox directly while the VM is running. The answer is in BCDEditt. You could loopback mount the VHD and use bcdedit to alter the boot configuration store offline. I haven’t tried it with a mounted VHD, but the parameters would look something like “bcdedit /set {current} detecthal yes” replacing {current} with an appropriate store. There's something to investigate and a blog post for another day…

Cheers,
John.