With the newly released version of VMware Fusion 12.0 I'm having the same problem I did with the Technical Preview in macOS Big Sur Beta 6.
When starting a Windows 10 x64 virtual machine, I receive the following error message:
Could not connect 'Ethernet0' to virtual network '/dev/vmnet8'.
More information can be found in the vmware.log file.
Virtual device 'Ethernet0' will start disconnected.
Has anyone found a solution to restoring internet availability in the guest virtual machine?
VMWare do not seem to contribute to these conversations and the release of 12.1 went completely unannounced (note the blog note on this appears before the announcement of V12 which is therefore in the wrong date order. It seems they do not want you to know about 12.1).
I appreciate your feedback and I will sit tight until we find out how the Health Check option works and someone verifies that 12.1 fixes the ethernet0 issue. I need the VMs to work.
I had discovered a very interesting thing when I change the subnet of my network from the old 188.8.131.52/24 to a new subnet 192.168.2.0/24 the issue resolve! and when I return back the old subnet and reboot the VM the issue comes back.
the problem I need to be on the old subnet and I can't change it to any new network. Anyone has a solution to refresh the old VMware data so I can keep my old network?
I am using the latest version of Big Sur and Vmware
Thanks in advance
Big Sur isn't compatible though, so why is it claimed to be?
Issue still not resolved on macOS 11.0.1 (not beta) - so I think all the customers who bought this on the premise that this was compatible with Big Sur need to be refunded.
Yes, VMware are not responsible for regressions in macOS - but they are responsible for correctly advertising their products, which they haven't done.
Just had my first call with VMware tech support (after waiting several weeks to get started). It appears to be a known issue/bug and has been escalated to engineering to resolve, the support tech tried a bunch of things with no luck so they're collecting the logs and will need more time to fix the issue.
To be clear, I'm talking about the inability to connect Ethernet0 when the VM starts or when it's running.
Tech was initially focused on any VPN client I have on my machine since there are known issues with Fusion 12 while using a VPN. I was not using a VPN but had clients installed, we uninstalled them but it did not help. Folks having the same issue can try uninstalling all VPN clients to see if their issue is resolved. Note: I also uninstalled my Bitdefender antivirus since it has a built-in VPN client (which sucks, but that's another story).
In case it's helpful to others, there are a few commands we ran on the command line which the tech thought might resolve these issues. They didn't but I'll share them here in case others want to try it:
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start
Tech also tried switching the adapter from NAT to bridged mode, then connect the adapter (failed), then switched back to NAT mode and connect the adapter (failed).
Seems like we need to wait for the product developers to fix this bug...
version 12.1.0 doesn't fix it for me, I no longer get the pop up stating it cannot connect to the vmNetX connection, no errors at all actually but despite the interfaces showing up in the vm nothing connects. I have many vm's and some work, some dont.. none did at first but I was able to get freebsd, windows, and apple based vm's working again by replacing the vmxnet3 driver specified in the .vmx file for the guest vm with e1000 again regressing back from 10gb to 1gb, but at least those vm's are back to working. My linux based vm's that don't specify a driver file I have worked endless days without ability to get them working. Again had many linux vm's for Cisco, Aruba/HPE, etc and most of them started working again after going e1000 (nothing else works) and the "other linux/64-bit" vm's without the driver showing never complain but can never talk no matter what physical NIC I connect to them to, no matter the combination. None of these use NAT or VPN, just simple NIC configs all working prior to upgrade to Big Sur and VMware 12 Pro.
Have posted this in a couple threads, and not sure if it works for everybody, but it did for me. I have been working on this issue for a while and could not get it figured out. Then with one click I was back on my VPN. In the Mac settings go to Security and Privacy and go to Firewall and turn on Firewall options. Then turn off Stealth mode. With that one click I was back up and using the VPN.
I agree that we need to be refunded. Only reason some of us upgraded to Fusion 12 is becuase to their claim that 12.x is BigSur compatible. I raised a support ticket, and they want me to work with my VPN providers and others to fix their software issue. No software vendor is going to entertain a support ticket because something else is not working. I'm asking for a refund from VMWare and now they refuse to respond. VMware might listen if many of us raise this issue or go for a legal path.
I learned a lesson by not taking advantage of the free trial, it would have been obvious Fusion 12.1 networking is broken on Big Sur. My support case is still open, very nice support technician who helped me but they said there is a known bug in the product affecting others too, something related to VPN causing issues with Fusion 12. Not sure if it's a high priority fix for them though, weeks have passed. None of my VMs have any networking capabilities, the adapters won't connect. I bought Parallels since I couldn't wait any longer and it works fine. There are free alternatives too.
Doubt anyone will get a refund because they do offer a free trial.
Since the very first release of Fusion I always bought the upgrade without thinking. Silly me. I suspect it will get fixed one day
how is that supposed to resolve the nat issue?
that will only wipe out your network connections until they are automatically recreated.
anyways, I did a lot of tests, icnluding this, same issue inside the guest, internet yes, vpn from host not.
i am facing the same issue not able to connect VMware Fusion's VMs on vmnet5
i have used below command but it doesn't help and still issue is the same.
sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist && sudo killall -9 configd
i have MacOS and Just few days back updated the OS with BigSur 11.1 was the last update but still can connect on Private network vmnet5.
All of my VMs are without network access under Big Sur and Fusion 12.x. Strangely, networking seemed to work just fine for a day or two after upgrading to Big Sur. But sometime today, it changed and none of my VMs work any more. This is a real problem because one of the Windows apps I need phones home to a licensing server at every launch. It's mission critical and now useless.
$ sudo rm /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist && sudo killall -9 configd
$ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --configure
Stopped NAT service on vmnet8
Stopped all configured services on all networks
Backed up existing network settings to backup file "/tmp/vmware.SpI1rT"
Restored network settings
$ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --stop
Stopped all configured services on all networks
$ sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --start
Enabled hostonly virtual adapter on vmnet1
Started DHCP service on vmnet1
Started NAT service on vmnet8
Enabled hostonly virtual adapter on vmnet8
Started DHCP service on vmnet8
Started all configured services on all networks
Unfortunately, even after all that...
Here's what shows up in vmware.log when I try to connect the network adapter:
2021-01-02T23:19:13.541-08:00| vmx| I005: TOOLS received request in VMX to set option 'synctime' -> '1'
2021-01-02T23:19:13.541-08:00| vmx| A000: ConfigDB: Setting tools.syncTime = "TRUE"
2021-01-02T23:19:13.548-08:00| vmx| I005: VMXVmdb_SetCfgState: cfgReqPath=/vm/#_VMX/vmx/cfgState/req/#24c/, remDevPath=/vm/#_VMX/vmx/vigor/setCfgStateReq/#1a8/in/
2021-01-02T23:19:13.557-08:00| vmx| I005: TOOLS received request in VMX to set option 'synctime' -> '1'
2021-01-02T23:19:13.557-08:00| vmx| A000: ConfigDB: Setting tools.syncTime = "TRUE"
2021-01-02T23:19:13.567-08:00| vmx| A000: ConfigDB: Setting tools.upgrade.policy = "upgradeAtPowerCycle"
2021-01-02T23:19:13.583-08:00| vmx| A000: ConfigDB: Setting ethernet0.connectionType = "nat"
2021-01-02T23:19:13.590-08:00| vmx| A000: ConfigDB: Setting ethernet0.addressType = "generated"
2021-01-02T23:19:13.590-08:00| vmx| A000: ConfigDB: Setting ethernet0.generatedAddress = "00:0C:29:EA:12:C7"
2021-01-02T23:19:13.621-08:00| vmx| A000: ConfigDB: Setting ethernet0.virtualDev = "e1000e"
2021-01-02T23:19:13.660-08:00| vmx| I005: Vigor_EthernetScheduleReconnect: reconnect delay = 7 seconds, reconnectEthVector = 0x1
2021-01-02T23:19:20.686-08:00| vmx| I005: VNET: 'ethernet0' enable link state propagation, lsp.state = 5
2021-01-02T23:19:20.686-08:00| vmx| I005: DictionaryLoad: Cannot open file "/Library/Preferences/VMware Fusion/config": No such file or directory.
2021-01-02T23:19:20.686-08:00| vmx| I005: VNET: MACVNetMacosGetRealAdapterType: network type for adapter 0: 8
2021-01-02T23:19:20.686-08:00| vmx| I005: VNET: MACVNetMacosGetVnetProperties: vnet properties: vnet=vmnet8, nat=yes, dhcp=yes (ignored), subnet=192.168.67.0, mask=255.255.255.0, firstAddr=192.168.67.1, lastAddr=192.168.67.127, isIPv6=no, IPv6Prefix=fd15:4ba5:5a2b:1008::, IPv6PrefixLen=64
2021-01-02T23:19:20.686-08:00| vmx| I005: VNET: MACVNetPortVirtApiStartInterface: Waiting on semaphore for adapter: 0
2021-01-02T23:19:20.689-08:00| host-51220| I005: VNET: MACVNetPortVirtApiStartHandler: starting interface for adapter: 0, status: 1009
2021-01-02T23:19:20.689-08:00| host-51220| W003: VNET: MACVNetPortVirtApiStartHandler: unable to create virtual intrface for device: 0, status: 1009
2021-01-02T23:19:20.689-08:00| vmx| I005: VNET: Semaphore signalled for adapter: 0, timeoutMs=5000, waitMs=3
2021-01-02T23:19:20.689-08:00| vmx| W003: VNET: MACVNetPortVirtApiStartInterface: Failed to create interface for adapter: 0, handlerStatus: 1009
2021-01-02T23:19:20.690-08:00| vmx| I005: VNET: MACVNetPort_Connect: Ethernet0: can't start virtual interface
2021-01-02T23:19:20.690-08:00| vmx| I005: Msg_Post: Warning
2021-01-02T23:19:20.690-08:00| vmx| I005: [msg.ethernet.connectionType.connectFail] Delayed connect of network adapter ethernet0 has failed. Please connect it manually by editing virtual machine settings.
2021-01-02T23:19:20.690-08:00| vmx| I005: ----------------------------------------
2021-01-02T23:19:20.703-08:00| vmx| I005: Msg_Post: Error
2021-01-02T23:19:20.703-08:00| vmx| I005: [msg.vnet.connectvnet] Could not connect 'Ethernet0' to virtual network '/dev/vmnet8'. More information can be found in the vmware.log file.
2021-01-02T23:19:20.703-08:00| vmx| I005: [msg.device.badconnect] Failed to connect virtual device 'Ethernet0'.
2021-01-02T23:19:20.703-08:00| vmx| I005: ----------------------------------------
2021-01-02T23:19:20.924-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 2 rendering MKSWindow(s) of total 2.
2021-01-02T23:19:21.106-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 1 rendering MKSWindow(s) of total 2.
2021-01-02T23:19:25.274-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 2 rendering MKSWindow(s) of total 2.
2021-01-02T23:19:25.674-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 1 rendering MKSWindow(s) of total 2.
I would open a support case to add more priority to this issue. My case on this exact issue has been open since November and no progress. They told me it's a known issue but they have no timeline on when it will be resolved. It appears it's not very important to VMware to fix this known bug. How times at VMW have changed...
Same issue as reported here. Getting ready to open a ticket and hope that my purchase a few months back includes more than one support call, as I always seem to need more for the bugs. Has VMWare support had people enable diagnostic logging? It always seemed to provide support with useful info (not to say it allowed them to fix the issue).
Last I checked, VMware has filed this under "It's a macOS bug." As such, they may be in the boat of waiting for Apple to fix it. Which would be a tough situation to be in, as who's to say when it may get fixed by them? Or even if they consider it to be a bug at all?
I'd hope that they're looking for workarounds to hedge their bets...
Hello, Simply use Viscosity (https://www.sparklabs.com/blog/) : "Version 1.9 also introduces driverless TAP (bridged) connection support on macOS. This is something we are particularly enthusiastic about: if you use TAP (bridged) OpenVPN connections you'll no longer need to manually approve a kernel extension to load before you're able to connect. This will also make deployment much easier in enterprise environments. And best of all, our approach fully supports macOS 11." Without changing anything in Big Sure (11.1) configuration and Fusion Pro 12, my guest had access to a service behind the Host open vpn connection via Viscosity.This is ashamed that nobody from Vmware support could tell us this...Hope this will help.Greg
Had the same issue today when upgrading to BigSur official release. Solution for me was very easy: I went into the network settings of the VM and deactivated the network adapter, ticked Bridged Wifi, and attached it again. BigSur was then asking for permission. After that it worked fine...