Vista 32/64 Error Message

[HamSammich2]

Using Fusion 1.0 retail on a Mac Pro with Boot Camp and Vista 64.

Starting the "Boot Camp Partition" brings up an error message saying:

"You are running a 64-bit guest operating system, but the virtual machine is configured to run a 32-bit operating system. To ensure that a 64-bit guest operating system will function correctly you must create a new virtual machine and be sure to select a 64-bit version of the operating system."

Now, here's the Catch-22. How do you create a new VM, when the new VM dialog box doesn't have a choice for Boot Camp Partition? I can't figure out how to do that, to modify the existing one or delete it, assuming you can do that without damaging the "real" Boot Camp partition.

Please help!

[Jimbode]

Have a look here:

http://www.vmware.com/community/thread.jspa?threadID=79604

for why this can happen.

And for a workaround have a look here:

http://www.vmware.com/community/thread.jspa?threadID=92524

[HamSammich2]

Thanks, but no joy. This is a mac Pro with two Xeons. The thread refers to iMacs and Meroms and hacking EFI. In any case, having used Parallels, I already know that VT-X is set properly.

[admin]

Now, here's the Catch-22. How do you create a new VM,

when the new VM dialog box doesn't have a choice for

Boot Camp Partition?

You can't, the dialog is misleading. You can try to edit the vmx file directly.

http://www.vmware.com/community/thread.jspa?threadID=93524

http://www.vmware.com/community/thread.jspa?threadID=91635

http://www.vmware.com/community/thread.jspa?threadID=89077

http://www.vmware.com/community/thread.jspa?threadID=88536

[HamSammich2]

Okay. So how do I edit the VMX file directly? And how do I remove and recreate the VM, if need be?

Seems to me a released app ought not have weird error messages. Either support for a function should simply be there or, if it's only semi-baked, the function should be disabled until It Just Works.

Mac users are pickier than most about user experience. They expect the fit and finish to be right. If instead of surprising and delighting them, the bits and pieces are irritatingeven if there's a good geeky reasonit turns them off.

[_doty_]

Now if I'm not mistaken, isn't this the same problem that is discussed in the following thread (http://www.vmware.com/community/thread.jspa?threadID=97592&tstart=0)?

If you take at my reply, which is third from the top, give that a try and you should be good to go. I made this fix to my vm bootcamp partition a few weeks ago and have not had any problems with it what so ever.

Good luck!

[admin]

Okay. So how do I edit the VMX file directly?

Quit Fusion. Find the file - by default, the bundle is something like ~/Library/Application Support/VMware Fusion/Virtual Machines/Boot Camp/your-device-name-here/Boot Camp.vmwarevm. In the Finder, ctrl-click and select Show Package Contents. Look for the file with the vmx extension, and open it with a text editor.

And how

do I remove and recreate the VM, if need be?

For Boot Camp virtual machines, just delete the vmwarevm file, it should be automatically recreated the next time you run Fusion.

Seems to me a released app ought not have weird error

messages. Either support for a function should simply

be there or, if it's only semi-baked, the function

should be disabled until It Just Works.

The "problem" is that Fusion uses the same code base as other VMware products, which have features not present in Fusion. While we've tried to scrub out references to nonexistent things, some slip through. It's sort of like saying released apps should not have bugs - true, but hard to achieve.

[HamSammich2]

>>While we've tried to scrub out references to nonexistent things, some slip through. It's sort of like saying released apps should not have bugs - true, but hard to achieve.<<

Thanks and understood. Just the same, this isn't a subtle or hidden issue. It comes right out and shouts at the uservery early in the game. It confuses, and discourages users from going further. And what's worse, it would seem to have presented itself 100% of the time in testing, on a flavor of Windows fer cryin' out loudnot Barfing Bonobo Schminix or something.

So the only excuse, as I see it as a former project manager (of construction projects, not software), would be if the condition were only fixable by gutting a big chunk of infrastructure at high cost. And if that were the case, better to sniff out the condition on installation and put in logic to prevent the user from trying to do whatever brings it on.

And barring all that.. why not README and flag the daylights out of it?

In any case, under EVERY circumstance, do not permit a user to do something that will persuade him his app is broken and either:

A) Lose productivity trying to solve the problem, or

B) Simply say "Screw it! It's not worth the trouible."

Sorry for the rant, and nothing personal, but you guys need to do a little better on things like this. Everyone knows you do the geek stuff well.

[admin]

It's not a supported configuration (since Apple doesn't support 64-bit Boot Camp, at least at the time), so doesn't get tested.

[HamSammich2]

Got it. But strange. Leopard's not a released OS yet, but I trust you're at least testing against it.

Same should apply for a Windows flavor, even if it's slightly premature.

Thanks for the help, anyhow.

I will give you guys credit for slowly getting the hang of the Mac community and for embracing internet openness.

You started this endeavor with a distinctly cold, distant "Olde IBM" kinda vibe. And though your website is still chilly, confusing and largely impenetrable, the mere fact of your online presence is welcome.

So is your promptness, courtesy and competence. Kudos. A lot of people will be watching. So don't screw up!

[HamSammich2]

Eric, thanks.

Edited the file and it works just fine. One question, though: Why, when using the Boot Camp partition, does Fusion demand a SuDo password?