Boot Camp Error and Activation

[JohnZonie]

Using a 2009 Mac Pro, OSX 10.6.2 with Boot Camp, Fusion 3.0.1. Installed Windows 7 Professional 64-bit. Then accessed the BootCamp partition via Fusion and installed VMWare Tools. Went back to BootCamp and activated Windows. Then back to OSX and accessed the BootCamp partition and everything seemed fine.

After going back to BootCamp and then back to Fusion, I noticed the Fusion Virtual Machine Library now has two Boot Camp Partition entries, one indicating "Powered Off" and another indicating "Error". I accessed the Powered Off one. After waiting to Fusion to prepare the Boot Camp Partition to run as a VM (again - this happened when first run), I was able to access the VM but Windows was no longer activated. I had seen this happen before I had activated but chalked it up to an activation interaction. After activating, I am now not so sure.

I know I can go through the 30-digit number dance with MSFT and get it activated again but I don't have confidence this BootCamp Error won't happen again.

What do you need to help resolve this issue?

Thanks.

[rcardona2k]

If you have a MacPro with multiple drives there are known problems with the way OS X names the drives and how Fusion resolves this. For more background consult this thread . The issue is not unique to Windows 7 and can happen with other guest OS's in Boot Camp.

[JohnZonie]

Thanks for the link. I do indeed have multiple drives in my Mac Pro.

If what WoodyZ says is true, and it probably is, then this is a serious design flaw that renders Fusion unusable for reliable Boot Camp access from OSX. Relying on d(i)sk enumeration without checking the partition name (BOOTCAMP) seems a major error. This is very disappointing to me as a 2+ year Fusion user.

Do VMWare personnel have any comments on this? Can this be corrected in a future update?

[WoodyZ]

If what WoodyZ says is true, and it probably is, then this is a serious design flaw that renders Fusion unusable for reliable Boot Camp access from OSX. Relying on d(i)sk enumeration without checking the partition name (BOOTCAMP) seems a major error.

Yes what I said was true and it is beyond ridiculous that VMware hasn't resolved this issue yet!

Do VMWare personnel have any comments on this? Can this be corrected in a future update?

VMware is and has been aware of this for nearly 3 years and while they continue to say they intend to fix it they certainly didn't with the 3rd major release and that said about the only thing VMware will have to say is something to the effect that is is against VMware policy to discuss time lines, blah, blah, blah, etc... So don't hold you breath waiting to get this fixed.

[JohnZonie]

VMware is and has been aware of this for nearly 3 years and while they continue to say they intend to fix it they certainly didn't with the 3rd major release and that said about the only thing VMware will have to say is something to the effect that is is against VMware policy to discuss time lines, blah, blah, blah, etc... So don't hold you breath waiting to get this fixed.

This is appalling! I'd be interested in hearing a definite statement from VMWare. Is this FAD (functions as designed) or a bug to be addressed? If the former, I guess I need to consider alternatives; if the latter, when?

[WoodyZ]

VMware is and has been aware of this for nearly 3 years and while they continue to say they intend to fix it they certainly didn't with the 3rd major release and that said about the only thing VMware will have to say is something to the effect that is is against VMware policy to discuss time lines, blah, blah, blah, etc... So don't hold you breath waiting to get this fixed.

This is appalling! I'd be interested in hearing a definite statement from VMWare. Is this FAD (functions as designed) or a bug to be addressed? If the former, I guess I need to consider alternatives; if the latter, when?

Let me make it clear that the "So don't hold you breath waiting to get this fixed." are my words not VMware's however VMware has addressed this issue by acknowledging it is a issue and they are working on fixing it although they're not going to say when it will be fixed/ready as they have already acknowledged it and have also effectively said their policy prohibits saying any more about it.

As far as an alternative you don't have a lot of choices and while I quit using the Boot Camp partition as a Virtual Machine because of this issue I don't recall this being an issue with Parallels and while I'm actually using Parallels as my primary virtualization product on the Mac I also do not have a current Boot Camp partition to confirm it's not an issue with it under this product however you certainly could download the trial and give it a go.

[JohnZonie]

Hi Woody,

I got the Parallels trial, linked to the boot camp partition and all seemed good. After a couple of reboots, the disk enumeration changed. Unlike Fusion, Parallels puts up an error message (apparently they use the same enumeration approach that Fusion does) but Parallels gives you the opportunity to select another disk! After selecting the other disk (same name as the first but with a different enumeration), I was able to access the boot camp partition without incident or impacting activation. A few subsequent reboots no longer result in the error. I don't know if this was coincidence or Parallels keeps track of the disk enumerations used.

Bottom line - Parallels seems to work fine with boot camp in a multiple disk environment. Since we've heard nothing from VMWare, I guess I'll get Parallels for reliable boot camp partition access.

Thanks for putting me on to this.