Mon Nov 29, 2010
A description of the issues I encountered moving my VBox environment from one host to another.
Source host Dell Studio XPS Core i7 running Vista Home Premium x64, VBox 3.2.10. Target host HP TouchSmart tm2 Core i5 running Win7 Home Premium x64.
I installed VBox 3.2.10 on the target host (same as on the source host) then copied the .VirtualBox directory from the source to the target via a USB HDD.
VBox configuration files contain absolute VDI path names: copy the .VirtualBox directory to the same location on the target to ensure the path names are same on both hosts. If you don’t do this you’ll need to edit the VBox XML configuration files on the target.
I use the default location for VBox files so had to create the same srackham user on the target as on the host (VBox files stored in
C:\Users\srackham\.VirtualBox on both hosts).
Here are the procedures I used and the issues I encountered.
Adjust network settings
My guest VMs use the Bridged networking mode and found I had to open VBox Settings on each target VM and change the Intel 82567LF-2 Gigabit Network Connection wired adaptor to the Intel WiFi Link 1000 BGN WiFi adaptor option (because the target host had a WiFi network connection whereas the source host had a wired network connection).
Note: The Microsoft Virtual WiFi Miniport Adaptor was also presented as an option but it did not work.
Unable to boot Windows VDIs on target host
The Windows VMs failed to boot on the target host.
About 3 seconds into the Windows guest boot sequence (just after the splash screen appears) a Blue Screen Of Death appears briefly (to quick to ready anything), then the VM reboots and the cycle repeats.
It took me while to find the solution, but it turned out to be simple: enable virtualization in the host BIOS (the factory setting of the HP TouchSmart tm2 BIOS System Configuration->Virtualization Technology option is Disabled, I set it to Enabled and the problem went away).
Another, more complicated, solution is to change the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm\Start registry entry to 4 as detailed in this blog:
If the Intelppm registry entry does not exists change the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor\Start registry entry instead.
You need to boot the Windows guest in Safe Mode_ – to do this press F8 when the Windows guest is booting to select _Safe mode.
Apparently the reason for this crash is because the intelppm.sys driver is attempting to perform an unsupported operation inside of the virtual machine (like upgrading the physical processors microcode, changing power state on the physical processor) – looks like the Intel Core i5-430UM processor does not support the same operations as the Core i7 processor. I guess there must be some processor ID stored in by Windows that is used at boot time. I was unable to find any definitive documentation as to the actual purpose of the intelppm.sys.
- Similar problems have been reported in the past:
- Apparently there is also an amdppm.sys driver (used on other processor architectures) that has a corresponding amdppm registry entry and can also cause problems.
- Section 12.3.4 of the 3.2.10 VirtualBox User Manual describes how to record bluescreen information from Windows guests.
- Interestingly there was no intelppm registry entry in one of the WinXP VMs an it never exhibited the problem.
- On Windows 7 Professional the Start registry value was set to 3 not 1.
- Booting Win7 Pro x64 guest for the first time on the target host Intel Core i5 CPU device driver software was successfully installed – presumably Windows had sensed a CPU change.
The second solution is apparently more general in that it will work irrespective of the target host CPU virtualization capabilities, see replies to my post to the VBox forums: http://forums.virtualbox.org/viewtopic.php?f=6&t=36398
Duplicate Name Exists errors
I sometimes got a Duplicate Name Exists error when starting WinXP guest on the new host. This error occurs if two PC with the same Windows computer name exist in the same workgroup – but not so in this case as I was not running the same VM on the source host. The problem goes away after rebooting.