VMware fusion - suspend a boot camp partition

[secureboot]

I don't seem to be able to suspend a boot camp partition - is this normal? Anything I can enable to make this do-able?

[rcardona2k · Accepted solution]

This is normal behavior to prevent suspending should you decide boot into native Boot Camp 'behind' Fusion's back. There is a setting in the Fusion Boot Camp partition configuration file to override this behavior. Caveat: consider this as handing you rope to hang yourself with. Used properly, through, the override should work.

[admin]

Right.

In case anyone doesn't understand what rcardona2k is implying there, I'll spell it out: if you run the Boot Camp partition as a virtual machine and then suspend it, and then reboot your Mac into native Windows using Boot Camp, then boot back into Mac OS and run the VM from its suspended state, you will cause major filesystem corruption on the Boot Camp partition, as the disk will have changed out from underneath the filesystem and the filesystem won't know about it and the data structures in memory will not correspond to what should be on disk. Very bad news. This is why we don't allow you to suspend a Boot Camp VM, and if you hack the settings to make it possible, this is what you need to be very careful to avoid.

[admin]

Also to expand on this a little further, this warning also applies to virtual disks/machines you manually create via vmware-rawdiskCreator. They don't have this sanity check, so be careful with them too!

[martona]

Here's a thought: Couldn't you render the Boot Camp partition temporarily unbootable from the physical computer as part of the suspend process? This way if a suspend is active and I try to get into the OS, I could be given an informative error message - something that I could "fix" by, say, rewriting the MBR, should an emergency arise.

Until then I guess we'll just have to be very careful after hacking suspend.disabled in the .vmx file.

[rcardona2k]

You're suggesting getting an informative message, after POST from say, from the MBR? You're playing with fire with this suggestion by re-writing the MBR. In today's world that's considered bad, virus-like behavior. The MBR bootstrap is a horrible x86 legacy artifact, there's not enough room to do this, such that you need to swap the OS loader. Not only that you're risking losing the entire volume if something goes bad. VMware has enough complexity where they could get blamed for losing your data.

IMO, they've done it correctly. The price of accessing a physical host partition (Boot Camp) is disabling the advanced virtual disk features of Fusion, because a physical partition is not virtual. Truly advanced users that understand what their doing, can enable it by proving they can edit a .vmx file. Unfortunately editing the .vmx alone is doesn't mean you understand the consequences.

[tbruylan]

Of course, VMware could be so cool as to write a custom MBR that allows booting Windows just like normal but contains extra code that checks whether or not the Windows instance was suspended or not and can block boot camp native booting if necessary? This way, it is not necessary to rewrite the MBR every time and the check can be implemented in such a way that in doubt, the user needs to use VMware Fusion (in Mac OS X boot) to resolve any issues...

Just my thoughts...

[WoodyZ]

I'm not speaking for VMware however I seriously doubt they ever consider touching the MBR if not for the very reason rcardona2k previously mentioned I'm sure they have their own very good reasons not to!  The bottom line is, if you want to use Raw Disks then do not suspend then as one is just asking for trouble even if one know what one is doing as it is to easy to forget you suspended it and by the time you realize it, it's to late!

[tbruylan]

I understand their reasons not to allow this by default, but I also see that VMWare products allow us to do a lot of very cool things that distinguishes them from the rest of the competition in the virtualization market. Adding this extra feauture is technically possible and not even very complex (although more difficult than most of us might think). (For example, GRUB bootloader saves (if enabled) the last choice, so it remebers it for the next boot. This requires GRUB writing one number somewhere on the harddisk at boot time.) I am sure that VMWare software contains much more complex techniques than having a bootloader that refuses to boot a suspended boot camp VM.

Another approach would be to invalidate the suspend state, so that Windows will boot natively, but also removes the suspended state. This of course would cause loss of the suspend state (which might also not be such a good idea).

In conclusion: I think it is perfectly possible for the VMWare developers to technically implement a "blocking" feature that disables native booting a suspended boot camp VM. Because this functionality is not (yet) present, I agree that disabling the suspend option altogether is the safest approach. This is also the reason why I will not patch my VMX file to re-enable suspend. I know for sure that I will make the mistake of booting a suspended VM at some point in time

Let's not discuss any further, as I think we both kind of agree on the matter: Having a safe way to suspend boot camp VMs would be very nice

PS: I'm not talking about modifying the MBR every boot, but rather creating a special purpose MBR or boot-loader (the code that is loaded by the MBR) that is able to see if a VM was suspended or not. This can be as simple as creating a file on the NTFS partition of Windows that says: "do_not_boot_natively". File present? Do not boot natively. This file creation can happen in Windows, by for example VMWare Tools.

[ColoradoMarmot]

Let's walk through a couple of scenarios:

To remove the suspend state, you'd essentially be hard-powering off the windows environment while it was running.  That risks corruption of both data and the system.  VMWare doesn't want the 'fusion corrupted my boot camp partition' media coverage.

VMWare's server-based product with those 'cool feature's run as a type 1 hypervisor, so they are in full control of that memory image, which is what allows migrating them between physical hosts.  Fusion and workstation are type 2 hypervisors, and do not have that level of control (e.g. they aren't running at all when boot camp boots), so there's no way to take that kind of control.

The only other alternative would be to convert a fusion suspended VM memory image into something like a windows hiberation memory image, copy that out to the boot camp partition, and then modify the boot environment to know to restore from hiberation mode.  Aside from the difficulties in properly converting that memory image, the hardware available to the OS has changed (virtual to physical), so different device drivers would magially have to be deployed into that hiberation image.

Technically possible, perhaps.  Reasonable/stable/safe/realistic?  No way.  There's lots better things for Fusion's engineers to spend their time doing (like 3D acceleration for all clients, improved shared folder performance, etc) that impact far far more users.

Simply put, if you need to suspend a VM, don't use boot camp.  It's not that big a deal.

[tbruylan]

Yes, you are right. That's why I suggested not removing any suspend state (because it would definately cause corruption), but rather just refuse native-boot if in suspend state.

Anyway, if GFX hardware acceleration would work like with a native boot-camp install, then I would not even use boot-camp. The reason I installed Windows as a boot-camp partition is to be able to boot natively in order to be able to use the full potential of the graphics acceleration (for gaming). Otherwise, I wouldn't even bother booting natively. So I certainly agree with your statement that the VMWare engineers should spend their time improving this aspect of Fusion and Workstation

Tim.

[ColoradoMarmot]

I hear you - gaming is about the only thing that I can't completely run inside a VM.   I ended up creating a VM separate from the boot camp partition (which I don't virtualize) for all the other stuff.