Here are my experiences migrating a Thinkpad T60 to a virtual machine in Parallels (the goal is not to lug multiple computers through airports).
My experiences mirrored those described here. In a nutshell, the plan is this:
- Backup the Windows machine with something that will back up everything. I personally use and recommend Acronis True Image. It can backup everything, and also supports backing up to and restoring from network shares, even from the recovery CD.
- Create a new Parallels virtual machine, and configure it as you'd like it.
- Boot from the backup software's recovery CD and restore the backup to the virtual machine.
- Remove the recovery CD and reboot the virtual machine.
At this point, if all were right with the world, you would be able to finish up with these steps:
- Ignore the "Add New Hardware" dialogs, and install the Parallels Tools (and hope they don't blue screen while installing the video drivers, as they always have done for me).
- Reboot - you're done!
Unfortunately, life is not that simple. When you reboot after restoring your backup, Windows will almost certainly refuse to boot. The root problem lies in the Windows device driver model. At the root of the Windows device tree is the hardware abstraction layer, implemented in "C:\Windows\System32\Hal.dll". Under the Device Manager, this determines what shows up as "Computer" near the top of the list. On nearly every modern computer, this will be listed as an "ACPI Uniprocessor Computer" (or multiprocessor, in the case of Core Duo, et al). The important part is it's based on ACPI.
While Windows these days can handle a lot of driver and hardware changes with ease, it cannot cope with a mismatched computer type. Unfortunately, Parallels does not provide an ACPI hardware profile - if you install a fresh Windows installation, the computer type is "Standard PC", and has an additional property tab dealing with IRQ mapping, etc.
What this means for restoring your Boot Camp or real PC backup is Windows has no idea how to talk to your hardware when it boots up, and will crash (so hard in fact, that Parallels reports an error in the VM and encourages you to submit a report to them - which I have). There are two ways of correcting this:
- Perform a "Repair Install" of Windows, which is detailed on many other pages. This requires a full Windows installation, and reapplication of any service packs and patches. Plus the inevitable cleaning out of the garbage that installs. Plan on several hours of your time.
- Correct the root problem - the "hal.dll" file mentioned above. All credit for this solution goes to "frank" - thank goodness for his post on the subject.
The repair install, while it will work, is a pain in the rear for many reasons, and it's pretty well documented. I'll cover replacing the hal.dll here, as it's a lot faster, and only mucks with that single file.
- Boot from a Windows XP CD.
- When prompted, press "R" to enter the Recovery Console.
- Select your Windows installation - likely the only one listed - and enter your password.
- Assuming your CD is "D" and hard drive is "C", type this command:
extract d:\i386\hal.dl_ c:\windows\system32\hal.dll
- Exit the recovery console, eject the CD, and reboot.
Voila! You should now be able to boot into Parallels with no problem.
As to the real solution - if I have understood this all correctly, the root problem is Parallels does not fully implement ACPI, and thus does not show up as an ACPI-compliant computer to Windows (this might also explain why Linux images don't fully power off after halting). Parallels needs to add/correct this, and then life should be much, much easier for those of us nuts enough to migrate real Windows installations into Parallels on a regular basis. 
Of course, I requested this a while back, but never heard anything of it.
All of this is based on my travails today and reading a lot of forums, web sites, etc, so please feel free to correct me where I'm wrong!
Last edited: Nov 18, 2006
