3 people found this helpful
Hi MattKimler ,
Could you try to restart the networking service by the follow command:
'sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop' and
'sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start'
then renew IP address inside VM by ipconfig/renew?
I had /exactly/ the same issue happen with a Fedora Linux VM after applying macOS 10.13.3 this evening. Very annoying. I have done two restarts since the upgrade, so I don't know think that restarting these services is going to have a lasting affect.
When option Network "Share with my Mac" the NAT access doesn't work anymore.
I have to set the Wifi bridge mode to access internet.
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start
These steps worked for me.
I have a similar issue. But it has triggered now and then in the past, with earlier versions of macOS and Fusion too.
Extremely annoying when it happens. Any idea why?
For me it works for a while, then suddenly stops with the same message as you. I will try the workaround next time. But it does of course not replace a true fix.
I also had the same problem.
After stopping and restarting vmnet-cli, I also had to disable and re-enable the adapter.
I experience this problem on a daily basis with Windows 10 guests and MacOS 10.12 (Sierra) guests.
I'm running Fusion 10.1.1 on Mac OS 10.13.3.
Stopping and restarting vmnet-cli fixes the problem.
It seems that VMware has significantly reduced the development resources for Fusion awhile ago, and it shows in the quality of the product. Very disappointing.
I started running into this issue with the update to Fusion 10.1.2. In bridged mode - Internet sometimes worked, but once I switched to NAT - not only did I lose Internet on the Windows side, the Mac side seemed to go belly up as well.
Finally stopped and restarted services as given above and VM side now set on NAT with no issues. Curious as to what was/is the issue.
The same issues happens for me at least once a day. My typical workflow involves 2 linux VMs managed by vagrant and 1 win7 VM.
I have to run my fix_vmnet.sh every time to get back to work. Nothing strange, at least for me, in my console log when the vmnet crash occurs.
Thank you for the answer, this fixed the NAT problem I had with:
VMWare Fusion: 10.1.2 (8502123)
macOS High Sierra: 10.13.5
VMGuest: Windows 10
Thank you! This worked!!
I've had this issue intermittently for months now and *usually* some combination of rebooting/relaunching app would restore connectivity, but no luck tonight though...
From my testing, it's obvious.
They introduced a bug in Fusion 10.1.* that breaks the DHCP service on suspend-resume. Reverting to older versions of fusion fixes the issue regardless of the OSX version.
VMWare, get your act together, revert the offending change to the DHCP service, networking subsystem or whatever (regardless of the arrogant and no doubt senior developer who committed the offending changes), issue a point release including "Fixed: NAT networking doesn't work properly" in the release notes, and lets be done with the issue. Honestly, it's made me very intrepid about upgrading fusion, as who knows what they'll break next.
In a product sold commercially to the general public (even if they have a technical background) the need to run restart scripts to make the product work as advertised is completely ridiculous. Issues like this wouldn't go unresolved in our company for even a month, let alone a year.