Situation:
Hackintosh with single Hard Disk, with a functional dual-boot configuration between Mac OS X and Windows (using a boot loader such as PC-EFI + Chameleon).
My Hackintosh use to have two hard drives. One with Mac OS X, one with Windows. I could dual-boot by hitting the F12 button during POST to select a boot device.
While under Mac OS X, I could also use VMware Fusion to load and run Windows from the physical disk it was on (loaded as a Boot Camp partition).
I recently purchased a new hard drive for my Hackintosh that I wanted to replace both the older disks with. The new drive is a Western Digital 640 Gig SATA2 disk w/ 32 Megs cache (WD "Black").
While I was able to clone Mac OS X and Windows to the new drive, I found that VMware could no longer load Windows.
Why?
When VMware Fusion is told to use the "Boot Camp partition", it creates a copy of the physical disk drive's MBR and partition table as a file on disk, then creates a virtual disk for the virtual machine that simply points to the physical Windows partition and the file with the copy of the MBR and partition table. The virtual disk file lists the complete partition layout on the physical disk, but prevents access to all other physical partitions.
The physical MBR with PC-EFI tries to load the hidden 200 Meg FAT32/EFI partition (which contains the boot menu for Mac OS X or Windows). But the copy of the MBR fails since the virtual machine does not have access to the FAT32/EFI partition, so the virtual machine hangs with an error and cannot continue.
I found one supposed fix here:
http://forum.netkas.org/index.php?topic=163.0 (check out Reply #5)
It mentions that since the only two things writable are the MBR copy itself (the file name "Boot Camp partition-pt.vmdk" under your Library), and the actual Windows partition, that you should be able to boot your Windows XP CD under VMware, load up the Recovery Console, and tell it to write a new MBR to disk. Because the change is only written to the virtual disk (remember, it is only a copy of your real MBR), it will not have any impact on your ability to load Mac OS X or Windows when you are booting your computer.
There were some mistakes in the post, and there were a few things extra I had to do.
The user mentions running "chkdsk /r /f" - that command does not work under the Recovery Console, but "chkdsk c: /p" does. It may not be needed though.
After running chkdsk, I ran fixmbr and answered "yes" to the question about overwriting what was already there. This will update the "Boot Camp partition-pt.vmdk" file.
After I rebooted the virtual machine, I no longer got a PC-EFI error, but Windows didn't boot either!
There are other ways to boot Windows besides the MBR on a disk, such as Grub.
From a recommendation in another post, I downloaded Super Grub Disk, booted from it in the virtual machine, and told it to load Windows.
While I was in Windows, I opened Disk Management, and set the Windows partition as Active.
Once I did that, I could then load Windows under VMware Fusion again, and the dual-boot configuration still worked. Windows under VMware, Windows with a real boot, and Mac OS X with a real boot.
I know this may not be a common configuration, but it allows me to access my Windows install and programs without having to reboot my Hackintosh. I can run the same install of Windows in a real environment or a virtual one.
Misc stuff:
My "Boot Camp partition.vmdk" looked like this:
# Extent description RW 1 FLAT "Boot Camp partition-pt.vmdk" 0 RW 409639 ZERO RW 390625000 ZERO RW 262144 ZERO RW 605468752 ZERO RW 262144 ZERO RW 252973864 FLAT "/dev/disk0s4" 0 partitionUUID BE8B0309-77AD-4D83-B32F-3AC06B6CBC64 RW 260071 ZERO
The Windows XP virtual machine would point to "Boot Camp partition.vmdk" as its virtual disk, and that file pointed to two other locations.
RW 1 FLAT "Boot Camp partition-pt.vmdk" 0 points to the file that has a copy of the real MBR and partition table.
RW 252973864 FLAT "/dev/disk0s4" 0 partitionUUID BE8B0309-77AD-4D83-B32F-3AC06B6CBC64 points to my physical Windows partition.
All other lines are basically specifying the other partitions on disk (FAT32/EFI, HFS+, and Empty space) as seen in the original partition table, and denying access to them.