Mac NVRAM corruption caused by VMWare Fusion

[nickbrandwood]

Hi,

I wanted to know if this was happening to anyone else or just me.

I frequently have issues with the NVRAM of the Mac host, that refuses to boot without a nvram reset via holding down key combination.

It took me a while to understand the cause, which I have now tracked down to not having completely suspended or shutdown a Fusion virtual machine prior to powering off, for example due to the battery running out.

I have only experienced this with Linux guests, as they are the only ones I use.

vmware : Professional Version 8.1.1 (3771013)

host : MacBook Pro (Retina, 15-inch, Mid 2015) running OS X Yosemite 10.10.5

Is this a known issue? I haven't found anything on the forum or via Google.

Thanks,

nick

[Mikero]

That's weird... I checked with our team and I don't think we explicitly write stuff to NVRAM (formerly PRAM).

Do you frequently run the system until it dies, or is that just one way to trigger the situation?

[nickbrandwood]

thanks for your quick answer. Its not something I do deliberately, but maybe I've left the laptop on my desk to go to a meeting without the power cable it can happen and as I have it configured to not sleep automatically. Everytime that this has happened and I have had to do a NVRAM reset (maybe five or six times over the last 3 months) reset Fusion was open and a linux VM running. I will do a couple of tests to make absolutely sure, one without fusion and the other with.

If there is any debugging information you would like to have to collect during this test, please let me know.

Thanks,

Nick

[Darcyz]

Hi Nickbrandwood

Welcome to Fusion Community. Really appreciate for your post.

I will try to reproduce your issue.

Could you help me to check the steps:

A. Create A Linux VM and keep is running(not suspended, not power off)

B. Waiting until battery running out

C. Charge the host and invoke the Linux VM

D. Check the boot screen whether need to do the NVRAM retest.

Regards

[nickbrandwood]

I replied via email, but I guess it didn't find its way to the forum:

step C is when you recharge the Mac and try to turn it on the you will get a black screen.

It will not boot (show the apple logo) unless you do a NVRAM reset.

Did the same thing this morning. Hadn't happened in a while but had started using fusion again last week. Friday I closed the Mac without shutting down the VMWARE, this morning black screen, NVRAM reset to get it to start. battery wasn't even flat.

[wila]

Hi,

Are you perhaps running your VMs full screen?

--

Wil

[nickbrandwood]

yes, I am.

[wila]

Hi,

Just to make sure.

Is it possible that just the VM comes up black but that your Mac host OS is booting up fine?

Eg. when this happens and you press Ctrl+Command do you get the mouse hand?

or have you tried swiping to the left (swipe with 3 fingers)?

or can you get out of full screen by pressing Command+Ctrl+F ?

If any of that gets you back to the host OS then you can just shut down and restart the guest OS and no need to mess with NVRAM resets.

--
Wil

[Darcyz]

Hi Nick,

Actually I cannot reproduce your problem.

I agree with Wila, could you let me know the result in single window mode?

Regards

[nickbrandwood]

Hi Wila, next time it happens I will try to swipe or command+ctrl, but I presume that if the battery is run out then the machine is powered off and the applications are no longer running, and note that when the machine returns from standby or power off, I am normally presented with the Mac login screen, not the VM running full screen.

Note that the only way to get the mac to respond is it to power on with the keypress combination. 

thanks again.

[wila]

Hi,

Hmm interesting that the login isn't showing.

Your report does make me think about a monster thread from a while back about sleep/wake failures.

See: Fusion 6.0.2 and OSx Mavericks 10.9.1 - Sleep Wake failure unless I shutdown or suspend my Win7Pro V...

From what I understand VMware never managed to reproduce that issue in house  (and thus hasn't been able to address it)

While it doesn't seem to be the same issue, there's some tips in there near the end that might help mitigating (extending the sleep using a pmset command etc.. I think mentioned somewhere on page 5)

As for VMs automatically shut down uhmm.. I wouldn't be too sure about that.

The thing I do down here is present the battery status to the guest (See VM Settings -> Advanced -> Pass power status to guest) and have the guest OS itself suspend using the normal guest OS mechanisms.

For me that works, but I usually don't have my machine off for longer periods of time, well not much longer as 10 hours that is

--

Wil

[nickbrandwood]

Hi Wila,

Have also set the "pass power status to VM". (answer 12) from the thread you mentioned. This seems to have fixed the issue, as a work around.

Thanks,

[Bynt]

Hello Nick!

It's interesting, what you've written down about your boot problems. Did you got fixed them already?

Maybe I've had the same problem: While starting up my MBP it regularly took about 50 seconds until the Apple-logo appeared. Within the system there were no complications. When I deleted Fusion 8 from the Mac, the problem disappeared.

I think it could be something written wrong in the boot partition.

Maybe you can give me an advice, if you got fixed the problem.

Thanks and regards

Tim

[JuanGuapo]

Respectfully, I've seen the very same behavior Nick has mentioned, and with the same vintage of MBP (Mid-2015 15" MBP, 2GB VRAM, 16GB RAM, 1TB SSD). Like the OP, I have had to do an NVRAM reset to get the MBP back to normal again. I removed Fusion completely for about three months and used an old Windows laptop as a workaround, no issues reappeared during that three month window.

I recently loaded up Fusion again, hoping to see if they resolved the problems with it. It looks like the problem semi-resolved itself in v8.5.x but still pops up every so often if I've run Fusion during my last session on the Mac. As a result, I'm back to using my old Windows laptop as a workaround, and have more-or-less stopped running Fusion altogether. I'd try Parallels but it's just not worth another license if I have an old Windows machine nearby to use. I may try VirtualBox during the summer.

Running Disk First Aid on my MBP, no errors found; my MBP passes all hardware tests. I'm running macOS Sierra 10.12.4. The client OS' are as follows...

Windows 10

Windows 8.1

Linux Mint 14 Cinnamon

I do run the clients full screen, often on a second DVI monitor while I'm working.

[dariusd]

This is a very interesting thread.

VMware Fusion does not contain any facility to write to the host NVRAM, nor does it ever write to the boot volume.  (In fact, it does not require that the boot volume ever be mounted.)  VMware Fusion does contain a facility to communicate with the host's System Management Controller (SMC), however that facility remains unused unless running macOS as a guest OS in a virtual machine so it cannot be implicated in the problems reported here.

VMware Fusion does not install any persistent drivers on the host -- the host drivers are only loaded when VMware Fusion is launched -- so our drivers can't cause a slowdown during host boot or a failure to boot unless something is configuring our drivers to launch earlier than they normally would.  VMware Fusion contains no facility to configure itself in that way such that it is launched earlier during boot.  (VMware Tools for Mac OS does install persistent drivers, but those would only ever be installed inside the guest OS.  No-one installed VMware Tools on their host, did they?)

I am very confused.  :smileyconfused:

Looking at the symptoms alone -- failure to boot until NVRAM is zapped, or boot slowdowns -- I would be inclined to think that something is corrupting the host OS's kernelcache, which it builds itself and maintains on the boot volume.  I'd start off by launching Console.app on the host and looking for any messages related to kextd or kernelcache.  See if kextd has ever reported problems building your kernelcache and if it explains what went wrong.  We've sometimes seen Mac host systems which have run out of disk space on their boot volume, causing kextd to fail and leading to some surprising consequences.

I'd also run an integrity check and general inspection of the boot volume.  Launch Terminal.app, run diskutil list to see the list of volumes, and find the Apple_Boot volume.  Figure out the partition name by taking the disk name and appending an "s" and then the partition number for the Apple_Boot partition.  On my MBP, it's partition 3 under /dev/disk0, so its full name is /dev/disk0s3, and I'll use that through the following instructions.  Run diskutil verifyVolume /dev/disk0s3 to check the integrity of the boot volume.  Next, run diskutil mount /dev/disk0s3 to mount the boot volume, and then diskutil info /dev/disk0s3 to see the filesystem information.  It'll show the amount of free space, which is 73.0 MB on my MacBook Pro running macOS 10.12.3.  (Yikes... That's surprisingly little free space...)  Finally, diskutil unmount /dev/disk0s3 will unmount the volume, and we're done.

Another random troubleshooting step: Next time your host is failing to boot, instead of clearing NVRAM, try booting into the recovery environment by holding down Command+R.  I'm interested to find out whether that works without requiring an NVRAM zap, or whether the NVRAM zap (Command+Option+P+R) is really the only way to get anything to boot on that Mac.

Thanks,

--

Darius

[JuanGuapo]

Normally, I had to reset the SMC (not only NVRAM) to resolve the problem. After six months without Fusion, bootcamp-only, no issues; meanwhile, if/when I installed Fusion Pro, I saw the very same issue as the OP.