No one asked but enough people have talked about it that I thought I would follow up on the "bootcamp vs running a VM" discussion with an explanation of what is going on under the hood (this is Fusion specific, but most of the important details are the same) that makes this work.
I’ll say upfront that this is not completely technically accurate and I have left out some bits on purpose. Please don’t nitpick with comments like: “ITS NOT PARTITION 2 YOU IDI0T!!!”
Short version:
Virtualization software like Fusion or Parallels can use either a file-based virtual disk, or a raw disk partition as source of the virtual disk. From the point of view of your Windows install, when you boot from Bootcamp then shut down and later boot from Fusion, it looks just like you moved the hard drive between computers.
Long version:
Think of the VMware Fusion software as a “player”. It plays virtual machines. A virtual machine is just a directory with a configuration file and bunch of virtual disk files. The config file tells the player “this VM has 2GB of RAM, 1 CPU, and a fake sound card.” The other important part of the config file is that is tell the player: “When you need to access the disk for this virtual machine, use this file called disk1.vmdk instead”. With these bits, the player has everything it needs to power on and run a virtual machine.
That disk1.vmdk file is a substitute for a real hard drive on a physical computer. When you first boot up a virtual machine, that hard disk is blank. When you install Windows in your virtual machine, the “player” (aka Fusion, Parallels, Virtual Box) writes to disk1.vmdk. When there is any disk activity in the virtual machine, the reads and writes go to disk1.vmdk.
Like physical hard-drives, virtual disk files are portable. If you know what you are doing, you can move disk1.vmdk to another virtual machine, change it’s config file, and maybe even get it to run. If you really know what you’re doing, it is technically possible to do a sort of raw copy of the contents of disk1.vmdk to an actual hard drive and get boot a real computer from that real hard drive. When doing this, you’ll run into the same sorts of trouble you would run into when moving a real hard drive between real computers. Unless the real computers are identical, you run into driver problems, boot device problems, Windows activation problems, etc.
Ok, almost last step. Instead of the configuration file telling the player that “this vm’s hard disk is at disk1.vmdk, do all reading and writing there”, Both Parallels and Fusion also support a config file that says: “this virtual machine’s hard disk is on raw disk partition 2, do all reading and writing there.” Why is this significant? Because reading and writing to a partition is exactly what your Mac does when normally booting and running Windows. The “Bootcamp” feature of Mac computers is just a way to boot a second disk partition. It also has some Windows specific helper drivers and applications, because otherwise your Windows installation wouldn’t have a driver for the trackpad, built-in camera, or other Apple specific hardware.
Finally, last step. When you boot Windows in Bootcamp, you’re reading and writing to partition 2 instead of partition 1 (partition 1 contains your OSX installation). So, when you run through the new VM wizard in Fusion and tell it you want to use an existing Bootcamp setup, it just sets up the VM config file to point at partition 2 rather than a vmdk file inside the VM directory. From the point of view of your Windows install, when you boot from Bootcamp then shut down and later boot from Fusion, it looks just like you moved the hard drive between computers.
One last note, as I sort of mentioned above, it is sometimes not trivial to move a disk between computers. Fusion (and I assume Parallels) has to do some tricks under the hood to make these problems invisible to the user and to fool Windows Activation. Otherwise, Windows Activation would get upset all the time because it thinks you keep moving your copy of Windows between computers.