ok.. some of you in the office would have heard me whine when vmware fusion recently started taking my whole machine down occasionally. The joy of it being the whole machine is that ive lost my firefox profile, and managed to turf my osx preferences twice since this started happening..

Through meticulous checking i tracked down that the problem started “the day i blogged about how much i love vmware fusion”. i spent a lot of time wondering if i rm’d the post if it would fix the problem…

While still pondering the rm blog_post angle, i decided to try less likely to succeed avenues.. so i started checking through the vmware forum, and at the same time started rolling back versions.. (it really was super stable till my blog post – which coincided with version 43733. (the bug being around in subsequent 48339 and the more current 50460.)

The forums looked scary, cause i eventually found a few postings with people complaining about it happening and VMWares response was “we know tis has been happening to some people since day1, we can just never replicate this.. please send us debug info so we can fix this”… blergh! helpful to know they are on it, useless for my having to reboot everytime i pause a vm (several times a day in the pre-BlackHat madness).

I decide to spend some time reading through the rest of the forum posts and make a note that the admins of the vmware forum are possibly saints for their patience in handling “u sux0r, im going back to parallels” posts, but eventually find a posting where someone complains about fusion on encrypted drives.. hmmm… i run my images out of a fileVaulted directory too..

in the mean time i had figured (through painful reboots) that going back to ver 43733 really did go back to stable, so i made a quick post to the forum at about 03h00 “u sux0r.. i hate u! im going to give this one last try on a non encrypted drive and then ill hate u more!”. By 03h10 VMWare replied with “oh… yeah.. if u using filevault – add this to your machines .vmx: mainMem.useNamedFile = “FALSE”

This works (with slower pause/unpause) times, but moving the guests to a non-encrypted drive solve both issues..

Of course most of the original bug posters replied with a “hey.. this _does_ solve it!” and VMWare replied with a “oh.. you are all running filevault?” oh…

so im back to being a happy camper.. and im sure in a few days ill not recall if i should blame apple or vmware for the mmap on encrypted volume lameness and ill go back to being a vmware fanboy once more…