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?

[zhenyuzhao]

I am pretty certain that this is a relapse of an old bug that was fixed but somehow creeps back since later release of version 12.2 (somebody mentioned that it was fine with 12.1). I am a long time VMware Fusion user since version 8 and I have just upgraded from version last year. If I could have waited a bit longer to upgrade, I wouldn't have this trouble. Well. It is going to be awkward to explain to my boss why he has to spend another $200 for another upgrade. It doesn't look splendid on VMware, does it?

[dearvoid]

Fusion 13 Release Notes gives a workaround: "To resolve the issue, restart VMware Fusion". See https://docs.vmware.com/en/VMware-Fusion/13.0/rn/vmware-fusion-130-release-notes/index.html

[Bigdave1357]

I opened a support case for this and then, wouldn't you know it, my machine stopped showing the issue.

I was contacted by VMWare after a while to archive the support case to which I agreed, since I couldn't provide the necessary diagnostic information.

Then my machine started to show the problem again! How did it know!

However, after a couple of days of use after upgrading to 13.0.1 I am pretty confident that this problem is now fixed.

If others can confirm that it has been fixed by installing 13.0.1 we can close this topic.

[wb9tpg1]

I'm interested if v13 solves this issue.  If it still persists I'm switching to Parallels.  

Can anyone who's upgraded comment? 

[Technogeezer]

If you search the forum, there are reports that 13.0.1 may have fixed this issue. It’s worth a try (using the 30 day eval feature) before you switch.

[Bigdave1357]

Having used it for a little while now, I can confirm that Fusion 13.0.1 does NOT fix the problem.

It does however,  seem to dramatically reduce the frequency of occurrence.

I now see 100% vmnet-natd only when there has been some sort of installation work going on within a Windows guest VM. Installing device drivers for a new USB device, applying Windows updates or general software updates such as for Visual Studio - all of these can, but not always, trigger the problem.

Generally, I can use Fusion without seeing 100% for days on end.

So it is a very worthwhile and welcome improvement. But not a fix.

Keep an eye on the CPU meter now and then, or listen out for device fans, or just watch out when you're updating a Windows VM and you should be fine.

However, VMware, if you're listening, it's not fixed.

[needtothinkofan]

Agree 13.0.1 still has this problem - seems less frequent- but occurs with both Windows 10 and Linux guests in macOS host

[Captain_Clam]

Been a problem for me for a while.  Currently using Fusion 12.2.5 on macOS Ventura 13.6.1.  Sometimes just launching Fusion results in this.  Sometimes I wake up a sleeping VM (Windows or Linux) and find it has no network access.  In these cases, I disconnect the network adapter and run:

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

 It's an annoyance that at best wastes time.  It drains my battery and impacts the performance of macOS.

[Captain_Clam]

---

@wb9tpg1 wrote:

I'm interested if v13 solves this issue.  If it still persists I'm switching to Parallels.  

Can anyone who's upgraded comment? 

---

If you're on Apple Silicon (don't know about Intel), Parallels now looks to be a GUI wrapper around macOS's lightweight virtualisation framework.  If you don't mind a little extra effort, this free app (also a wrapper around the built-in virtualisation) might be just as good: https://eclecticlight.co/virtualisation-on-apple-silicon/.  It can even run two macOS VMs concurrently, unlike Parallels.

[Bigdave1357]

I've been running 13 for some time and now 13.5.

It's not a complete fix. I have definitely seen it since upgrading. However, I would say that the number of occurrences is now vanishingly small. Not zero, but maybe once or twice since 13 has been released.

Still frustrating when it happens, but I can live with it.

[Captain_Clam]

I'd say it happens to me almost every day.  It's become more annoying in the last year.

[RobertD6]

On VMware fusion 13.5.0 MacOS 14.1.1 I'm now seeing it happen more frequently than last month.

After about 30 to 60 minutes of the Windows VM power on it ends up in the full CPU usage mode even though the Windows VM itself is idle and not consume barely any CPU.

Would be great if VMware or someone figures out a workaround to finally address this, I'm fine adding scripting at each VM power on or resume if some pattern can be established.

[sjordi]

as it has been said, it may be the ethernet board.
I totally stopped using most Ethernet boards that intregrate a RealTek 8153 and switched to the RealTek 8156B and the problem disappeared. Unfortunately the 8153 is the most common one as it's very cheap, but all the traffic overload is on the machine CPU and leads to hangups, vmnet-natd spinning like crazy.

The 8156B integrates a dedicated CPU for all traffic matters and doesn't overcharge the machines.
No problems anymore since I switched.

Search amazon for RTL8156B to pick your ethernet adapter.

[Captain_Clam]

I have no idea what chip I'm using.  I couldn't tell you what the WIFI in my 2019 16" MBP is using, and the wired is according to my system information:

Dell D3100 USB3.0 Dock:

  Bus: USB
  Vendor Name: DisplayLink
  Product Name: Dell D3100 USB3.0 Dock
  Vendor ID: 0x17e9
  Product ID: 0x436e
  USB Link Speed: Up to 5 Gb/s
  Driver: com.apple.driver.usb.cdc.ncm
  BSD Device Name: en16
  MAC Address: 9c:eb:e8:30:15:56
  AVB Support: No
  Maximum Link Speed: 2.5 Gb/s

Not that I want an additional dongle or could expect my employer to buy one when I've already got working network connections.  It would be better for VMWare to fix the bug.

[Captain_Clam]

Actually, I've noticed that this issue can occur without any VMs running.  I was using VMWare Fusion last night and suspended my VMs without exiting the app before closing my laptop.  This morning about an hour or so after starting work, I noticed my fans running during a video call and that vmnet-natd was using 100% CPU.  Thinking back, I think I've seen it do this before with no VMs actively running for at least a day before noticing the problem.

[Captain_Clam]

I've run out of battery three times in the last week because of this problem.  Without any warning, I can lose 30-40% of my battery in under an hour.

I've also had several instances of where I've been downloading large files in an Ubuntu 22.04 VM and the downloads just seem to stop.  This seems to be related to vmnet-natd suddenly having high cpu utilisation because restarting via vmnet-cli without stoping the VM fixes the downloads.

This has been a problem for a long time now.  I suppose that now VMWare is owned by Broadcom that their typical bad customer experience will apply and there's now even less chance of this ever being fixed.  Broadcom will probably just want to milk any existing customers for as long as possible.  Maybe time to find a different hypervisor vendor.