VMWare Fusion: Convert an existing file-based VM container to a physical partition?

[Klickster]

VMWare Fusion 2.02 - Is there a how-to for the process of taking an existing VM which is file-based and porting it to an empty partition (rawdisk partition I assume)? Essentially I want to take my existing XP SP3 and W2K SP4 images (which are "packages" residing on my Mac's HFS+ partition) and put each one on it's own partition. Then I want to tell VMWare to use the partition-based disk images instead of the file-based disk images.

I googled quite a bit and found rawdiskcreator and methods to make a physical partition into a file-based VM container - but the only thing I found for reverse was V2P which is unnecessary since the image is not being moved a different machine. I just want to use a partition instead of a file for my VM.

And I want to avoid having to reinstall XP and W2K from scratch on the new raw-disk partitions.

TIA!

Todd

[admin]

There is no easy way to do this. V2P is still relevant - you're moving from a virtual machine to a physical one; even though it's on the same physical computer, the larger challenges (missing drivers, etc.) are the same. Even though it's a pain, you will probably have more success creating a new partition from scratch.

Also, Apple does not support Win2k as a Boot Camp partition, so setting that up will probably be difficult.

What's your motivation for doing this? Simply moving to a physical partition will not (as many people expect) result in better disk performance -- it's actually likely to be worse.

[Klickster]

Etung - thank you for your quick and informative response.

i was hoping to move the images off the HFS+ partition for several reasons:

1- to eliminate backing up these images when I run CCCloner for routine backups of the boot partition. I use static virtual disk images so those take tons of time to back up.

2- to eliminate HFS+ filesystem overhead (atime updates and journaling) - theoretically if the VM is on a raw partition then the extra "work" that HFS+ insists on doing is elimated and performance should be increased (of course it remains to be proven - but that's what experimentation is for!). But it seems from what you said it actually might cause a hit (curious why this would be - is it that VMWare isn't optimized for accessing data directly from a partition vs. a file on HFS+?)

3 - I figured that if I placed these on separate partitions I could use diskutil or similar to create something like a ".dmg" (possibly even with compression) without actually compressing the original - thereby keeping the performance gains (even if minor) gleaned from using static-size images.

About W2K - I wasn't planing on using BootCamp to access this partition - kinda defeats the purpose of virtualization...or does VMWare leverage BC APIs to access the partition? - I read somewhere that a guy was using Ubuntu 8.10 on a BC partition with ReFit and was able to get it to work just fine via a raw-disk image in VMWare. I'm sure that Apple and VMWare don't support booting Ubuntu from a BC partition - but of course it works

Anyway, it sounds like it's more trouble than it's worth - instead I will just move the VMs to a separate HFS partition with atime and journaling disabled (which might help a little) and this will allow me to use diskutil to back up those partitions to a compressed .dmg file without deflating the virtual disk itself

VMWare should serously consider improving raw-partition disk access performance for folks that would like to avoid their VMs being housed as a container under HFS+ or NTFS; The filesystem within the VM has enough of it's own overhead to deal with

I suspect the temporary Parallels 4.0 performance wins are a result of using some fancy low level code that improves disk throughput.

Thanks for your time and help!

[admin]

1- to eliminate backing up these images when I run CCCloner for routine backups of the boot partition. I use static virtual disk images so those take tons of time to back up.

Simply getting the virtual machines off the boot partition would solve this. You can store and run virtual machines on secondary partitions, external drives, or even network drives (though of course the last will probably be slower and you're in trouble if your link goes down).

2- to eliminate HFS+ filesystem overhead (atime updates and journaling) - theoretically if the VM is on a raw partition then the extra "work" that HFS+ insists on doing is elimated and performance should be increased (of course it remains to be proven - but that's what experimentation is for!). But it seems from what you said it actually might cause a hit (curious why this would be - is it that VMWare isn't optimized for accessing data directly from a partition vs. a file on HFS+?)

There's not much for us to optimize in terms of accessing files* - we use standard OS X APIs for both normal file-based virtual machines and for raw disk access, just like any other program. However, there are a few factors which make a normal virtual disk faster than raw partition access on OS X. With a normal file, OS X can cache the contents in memory; raw disks do not get cached. For raw disk partitions, the virtual interface has to match the physical interface, but with a file-based virtual disk, we have more flexibility -- an Easy Installed XP virtual machine will use a (more efficient) SCSI interface, whereas a raw partition will use an IDE interface. Finally, OS X is optimized for file access, but raw disk access paths are not given much attention.

• this is not to say there isn't room for improvements in virtual disk performance, just that there isn't some super-sekkrit API to do this as far as we know. We may be able to improve in other ways.

3 - I figured that if I placed these on separate partitions I could use diskutil or similar to create something like a ".dmg" (possibly even with compression) without actually compressing the original - thereby keeping the performance gains (even if minor) gleaned from using static-size images.

I'm not sure what you're getting at here - are you proposing putting a preallocated virtual disk on a sparse disk image? It's not clear this would be any faster, and IMO would likely be slower. We've had problems in the past with Apple bugs and keeping virtual machines (really, any file which happens to be accessed in the way we do these files) on disk images.

About W2K - I wasn't planing on using BootCamp to access this partition

The ability to boot natively is IMHO the only real major reason you'd want to create a raw disk partition instead of using a normal file-based virtual machine. See .

does VMWare leverage BC APIs to access the partition?

From my (admittedly limited, I've never looked into this) understanding, there's no such thing as Boot Camp APIs in the sens you're using them. There are APIs to access raw partitions, which we use, but I would not describe them as Boot Camp APIs (they're not specific to Boot Camp, when you run Windows natively via Boot Camp they're not involved, etc.)

Anyway, it sounds like it's more trouble than it's worth - instead I will just move the VMs to a separate HFS partition

Yes, this would be my recommendation.