12.2.0 High CPU vmnet-natd

[Bigdave1357]

Looks like this old bug is back in 12.2.0

After upgrading a couple of days ago I see vmnet-natd process sitting at 100% even when there are no guest OS running. Shutting down Fusion completely and starting it up clears the problem. But I'm not sure what triggers it.

Anyone else seeing this? Anyone have a better workaround or fix?

[Eb21]

Exactly the same problem on a MacBook Pro 16"... It drains a lot of battery and causes fans to start spinning as soon as I launch Fusion. I hope a wmware fix asap. Thanks.

[MarcinB1]

I can see same problem here. I hope that VMware will resolve the problem quickly.

[Bigdave1357]

The problem doesn't occurr all the time for me. It seems to happen only when I leave my machine running a guest OS and the host goes to sleep. At that point the vmnet-natd goes 100% and after a few minutes the fans kick in. The machine is not fully asleep - just the display turned off with this task preventing full sleep.

Waking the machine with mouse or keyboard and then shutting down Fusion completely (all guests and then Fusion itself) stops the task and everything returns to normal. I can then restart Fusion and proceed as normal.

[brianmcbride81]

I am seeing this as well. Also, after upgrading just now Internet Sharing for the Network Adaptor no longer works. Any updates from VMWare on this issue?

[Bigdave1357]

I've seen no feedback from VMware on this issue. It's presumably a widespread problem and one would hope they will fix it with an upcoming patch.

I can work around it - I just make sure that after a session using a VM, I make sure to shut it down and then shutdown Fusion. It's annoying to have to do this, but thankfully that's the only impact for me.

[doemaas]

Tried 12.2.1 but vmnet-natd is still going unexpectedly awall and grabs 100% CPU, reverting back to 12.1.2.

[Bigdave1357]

Same here. Yesterdays new release doesn't make any difference. NAT process is still hogging 100% CPU.

I'm living with it, by shutting down Fusion itself after shutting down a guest. Not ideal. Please get it fixed VMWARE!

[Eb21]

Unfortunately also with update 12.2.1 the bug is still there...

[wb9tpg1]

I've had this bug for a while now and managed to change my configuration to make it go away.   Thought I'd pass along what I did.

I had shared folders enabled where I was sharing a folder on my MacBook with the Win10 VM.  I was getting the high CPU issue everyone was reporting.

I decided to move the shared folder off my MacBook to a NAS I have on the network.  I created the NAS folder and moved all the content to that folder.  Then turned off the 'Shared Folder' option and finally deleted the now empty folders.    Both the MacBook and the Win10 VM mount the new folder on the NAS so it looks similar to how I had it configured.

I've not had a single high CPU issue since the change.  I'm a happy camper.   Your milage may vary.  Good Luck

Gary

[DLuvzBacon]

how do you revert back?

[doemaas]

Just delete your Fusion app and install another downloaded version (https://customerconnect.vmware.com/downloads/details?downloadGroup=FUS-1221&productId=1040).

[binnenfuchs]

Maybe it helps to check if there are leftovers from another Fusion installation. I had the same high CPU usage by vmnet-natd and I ran

sudo kextcache -clear-staging

sudo kextcache -invalidate

Remaining data from Fusion in /Library/StagedExtensions was removed, no more high CPU usage trouble so far on Macbook Pro with Big Sur 11.6.2 and VMware Fusion 12.2.1

[doemaas]

@binnenfuchs you're lucky! Those kext operations unfortunately do not seem to work for my environment. Certainly worth a try.

[aleguarneri]

VMWare Fusion 12.2.1 gave the same problem today on Monterey 12.0.1

Uprading to Monterey 12.1 seems to have fixed the issue, FYI.

Alessandro

[Bigdave1357]

I have 12.1 and the problem is still occuring.

[doemaas]

I have a VM (on Fusion 12.2.1, Big Sur 11.6.2) that is causing this with 2 interfaces connected to the predefined ‘Share with my Mac’. When I move the first interface to the bridged wifi it all works fine, the vmnet-natd stays healthy and everything works as expected. Because I ran to all kind of other issues in relation to my local restricted network behind this bridged wifi config, I then changed it back to the ‘Share with my Mac’. And, unexpectedly the vmnet-natd is still behaving nicely en keeps behaving nicely. I suspect the vmnet-natd issue is related to using the two ‘Share with my Mac’-interfaces and some timing or interference with the natd process.   

[Bigdave1357]

Hi doemaas,

I've been experimenting a lot and I cannot link this to any one specific scenario. I've been using both Shared and Bridged operating modes, multiple interfaces, just a single interface. The bug seems to bite regardless of my configuration. The trigger point for me seems to be when my host goes to sleep. I can virtually guarantee that if I let this happen with guests running, when I come back and wake the machine, vmnet-natd will be at 100%. Whilst that is a reliable trigger, it is not the only one. Sometimes, for no reason, it will happen. I can be actively using just a single guest, with a single network interface, in either Bridged or Share mode and vmnet-natd will just suddenly jump to 100%.

Every time I see this behaviour, the network connection within the guest VM will drop. The only solution is a complete restart of Fusion: suspend each guest OS, close their visor windows, quit Fusion itself, restart, re-open the guests, resume operation. It only takes a few minutes, but it is very, VERY tedious.

[doemaas]

@Bigdave1357 you're right, my approach didn't work for a colleague of mine. 

For reference, you can 'reset' the vmnet-natd process by utilizing:

sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop

sudo  /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start

Strangely enough, since I changed my setup and changed it back to the original, the issue is completely gone. Surviving reboots, suspension, sleep. Before that, I had the same experience as you.

Frustrating! 😞

[Bigdave1357]

That's interesting!

So you're suggesting that maybe adding a network interface and then removing it will settle down the VM?