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?

[doemaas]

My case is one with a VM having 6 interfaces, 2 of them are 'Share with my Mac' (vmnet8 I believe) interfaces where the vmnet-natd actually has some work to do. 4 others are private and have a special config. What I literally did was change one interface to Bridged Wifi, reconfigured the VM network settings to actually send traffic over this interface and the other 'Share' one. That worked well, without vmnet-natd going to near 100% CPU. I then changed the same interface back from Bridged to 'Shared with my Mac', reconfigured the VM network settings again and let the traffic flow. All's fine now already for more than 24 hours. Lucky I guess and amazing! 🙂   

[doemaas]

Another day, other results. It was great while it lasted but the vmnet-natd ping of death is suddenly back again and I can't get rid of it anymore. Don’t know what changed. Don't care anymore. I’m giving up, I'm done, this is unworkable, no more VMware Fusion for me anymore. 🛑

[Bigdave1357]

My sympathy. vmWare don't seem to be interested in fixing this at the moment.

I'm living with it for now.

[brianmcbride81]

I ended up downgrading to 12.1.x for the time being until VMware fixes this. 

[RobertD6]

I just started experiencing this VMWare fusion issue on my MBP after upgrading to Monterey.  

I was not experiencing it at all before that upgrade.

[Technogeezer]

@Mikero we've had quite a few folks here that are experiencing various networking issues with Fusion 12 on macOS versions that use the Apple Hypervisor Framework. This vmnet-natd high cpu is just one of them (and I've experienced it at least once, but it's mysteriously vanished as quickly as it happens). There are also a number of other issues such as networks not working in the guest, and networking failing but restoring when Fusion is restarted.

Are these issues that VMware is aware of and is investigating? It doesn't appear to be a one-off situation.

[Bigdave1357]

I don't know if the vmnet-natd high CPU issue, or any of the other issues are being actively investigated.

I don't have a paid support agreement and my previous complementary support expired a while ago, so I've not been able to register any of this as an official support case.

I'm hoping that someone else will see this and do that.

[Technogeezer]

I don't have paid or complimentary support either - which is why tagged the VMware product manager - he's usually listening to this board.

Let's sew what he has to say.

[sjordi]

Same for me.

Even worse as after a while I lose all my Ethernet connections on my Macbook pro (native, not into the VMs).
The IP is still correct, but I have to switch to WiFi to be able to connect to the Internet.

Killing the vmnet-natd process stops the CPU overload and the fan spinning like crazy, but doesn't reset Ethernet connections

Usually, the only thing I can do is to actually reboot the Mac to be able to get back online.
Very frustrating.

VMFusion Pro 12.2.1

Steve

[Bigdave1357]

Had high hopes that 12.2.3 might fix this even though nothing was mentioned in the release notes.

Ran a few tests and it was looking good.

However, left Fusion running overnight, with a single Windows guest idling.

Wake up this morning - fans running on the host MacBook, natd process sitting at 100% as usual.

COME ON VMWARE - GET THIS FIXED ALREADY!

[brianmcbride81]

Yeah this is getting VERY old. There are vulnerabilities with older versions of fusion that our security scanning software is picking up on. I’m getting pressure to get things updated but can’t because of this bug.

[gigs94]

.....and we are still waiting for a fix.

[Bigdave1357]

I'm starting to think that vmWare have given up on Fusion.

The bulk of their revenue probable comes from users running Windows guest operating systems. And they seem not to care about pushing forward with that functionality, even though Parallels seem to still be putting in solid effort. I know that Microsoft have not yet released an OEM version of Windows 11 for ARM, but vmWare's response to the whole Apple Silicon things seems to me to be a bit limp.

And so my conclusion - there's no love for Fusion from vmWare - at the moment - and they're not even fixing serious bugs like this one which they certainly would have addressed in the past.

I hope things change. Otherwise I'll be voting with my feet and going Parallels.

[Bigdave1357]

I reckon this is related to the display drivers.

I've recently switched to an Apple Studio Display and noticed a dramatic drop in occurrence of this problem. Almost to the point where I thought it was fixed, but then I did get one or two recently. I've temporarily switched back to a Thunderbolt Display for reasons, and just in one day this has occurred four times.

vmWare have had a lot of issues with 3D acceleration over the years and I've seen problems come and go, so I wouldn't be surprised that this is related to the networking port on the back of my Thunderbolt Display, in some way.

[VirtualMac2009]

The issue of high CPU arises with VMware Fusion Pro 12.2.4 (20071091) on macOS 12.5.1 (21G83) Monterey, when opening Eudora 6.2.4 on Mac OS X Server 10.6.8 (10K549) Snow Leopard on iMac 27-inch Retina 5K display 4.2 GHz (model identifier iMac18,3 mid 2017).

[Technogeezer]

@VirtualMac2009 The issue is more widespread than on the versions you report. It's a nagging problem with NAT networking across pretty much any Fusion 12, macOS 11/12 and guest OS version. The tech preview has the same issue.

I've sent feedback on NAT networking issues to VMware as part of the tech preview, and I believe others have reported this as well to VMware. From what I understand they are investigating.

I'd work with bridged networking until VMware gets this sorted out.

[sjordi]

From what I found on the web, the problem is not VMWare or the OS. But it happens only with RealTeak RTL8153 ethernet boards that we find everywhere (because they're cheap). All the high power work is handed to the Mac CPU.
It looks like the RTL 8156 works much better as it has an onboard CPU to handle all the Ethernet traffic instead of outsourcing it to the Mac. Then VM_nat is not a problem.

[Technogeezer]

---

@sjordi wrote:

From what I found on the web, the problem is not VMWare or the OS. But it happens only with RealTeak RTL8153 ethernet boards that we find everywhere (because they're cheap). All the high power work is handed to the Mac CPU.
It looks like the RTL 8156 works much better as it has an onboard CPU to handle all the Ethernet traffic instead of outsourcing it to the Mac. Then VM_nat is not a problem.

---

Perhaps, but the high cpu issue and subsequent drop-out of NAT networking isn't limited to any one particular configuration. I'm personally having the issues both on Intel and M1 Macs with their standard networking cards - which are not RealTek chips. macOS / Fusion versions prior to Fusion 12 and macOS 11 worked fine on the Intel Mac hardware, so in my mind it's something with the refactored networking stack VMware's using to comply with Apple's changes. 

[Bigdave1357]

I agree. My analysis reflects a similar set of findings. This is a bug within Fusion 12 that has been recently introduced. It's prevalence may vary with hardware and other environments, including the type of ethernet hardware in use. But it's still a bug that needs fixing. I've not yet found any effective way to mitigate. The only solution, when the bug bites, is to suspend all guest VMs, shutdown Fusion to stop vm-nat and then restart everything.

[Mikero]

Just wanted to give a heads up that we hear you all and that this is under investigation by our networking team.