After the update to 12.5 (from 12) I lost my VMnet0 bridged adapter.. and I can't add it back.
Yesterday I uninstalled / reinstalled Workstation and I got it back but today it's gone again. I'm not running AV, I don't have any (other) VM adapters, (wired) internet works fine on the host system..
I have received a couple of support bundles from you. (Thanks for your greatest support! Really Appreciate!!) With everyone's help, we found one way to reproduce the issue is "Manually removed VMnet 1 or/and VMnet 8 in Virtual Network Editor, then reboot the host, the vmnet0 will missing" So I want to know anybody removed the VMnet1 or/and VMnet8 on your Workstation? If you did not remove VMnet1 or/and VMnet8 but also reproduced the Bridged network issue, please let me know as well. Thank you very much.
i too have this problem on windows 7 x64 and windows 10 x64.
i had workstation 12.1 installed on both systems and upgraded both installations to 12.5.
network was working fine on both systems, but stopped working after a reboot.
now my bridged vmnet0 is gone and i get this exact error message.
yes, i had removed vmnet1 and vmnet8 on both systems, as i only use vmnet0 bridged network.
Thank you Guys for confirming. We have a workaround which works in house. Could you guys try it out and give me your feedback? Appreciate.
1. Uninstall the 12.5
2. Reboot the host.
3. Install the 12.5
4. Reboot the host.
5. Open Virtual Network Editor, give the admin privilege to the Editor by Click the Change Settings button. (Skip this step if you login the Host OS as administrator and there is no “Change Settings” button)
6. Do not remove VMnet1 and VMnet8, instead, select VMnet1, uncheck “Connect a host virtual adapter to this network”, select VMnet8, uncheck ”Connect a host virtual adapter to this network”.
7. Run ifconfig, there is no VMnet1 and VMnet8 adapter.
8. Run a VM check the bridged network is working
9. Reboot the Host, run a VM to check the network again.
This workaround is purposed for the user who wants to use Bridged Network only and does not want to see the NAT and Hosted only network adapter on the host.
I tried the following which in some cases would then allow me to bridge the adapters but this config would always be lost after a reboot of the host:
1) Tried performing a Restore Defaults from within the Virtual Network Editor - This for me always failed to resolve the issue.
2) Tried doing a Repair of the installation of 12.5 - Again for me this failed to resolve the issue.
3) I tried removing VMNet1 and VMNet8 - Again this failed to resolve the issue.
4) I tried a complete uninstall of 12.5, restart then a re-install - This resolved the issue but the config would be lost after a restart whereby I could no longer bridge
With all of the above, even when I managed to get the issue temporarily resolved I found that the VMs wouldn't communicate reliably with the host and I'd get Media Disconnected as the status for the NICs within the VMs.
In the end as I said in my original post, I completely removed 12.5, restarted, installed 12.1.1 then removed and re-added the NICs on each VM before I got a running system.
One thing that did work for me was to remove the VMware Bridge service within the config of the hosts NIC, restart and then re-add the service. I could then bridge but again this would be lost after a restart.
Yes, the biggest problem is "Remove the VMnet1 and VMnet8" will break your bridged network.
To apply user's habit of remove the VMnet1 and VMnet8, the workaround I provided is keep the VMnet1 and VMnet8 and uncheck the "Connect a host virtual adapter to this network", so you would not hit the bug and you would not have VMnet1 and VMnet8 on your host and the most importantly, the bridged network will work after reboot.
unfortunately, this did not resolve my issue.
i did everything according to your list, but after the reboot in your 9th step, vmnet0 was gone again
this is weird. as vmnet0 was gone again, i started to play around with different settings.
i deleted all network connections in the virtual network editor and created a new vmnet0.
i could not configure it to bridged, as the error would pop up, so i configured it to NAT.
after closing and reopening the virtual network editor, i could change the newly created vmnet0 from NAT to bridged :smileyconfused:
but this works only until the next reboot..
Hi Tony and all,
it seems that I have managed to achieve a working configuration (in fact, I am typing this in one of my VMs where I have my browser running).
I did follow Tony's instructions, but it did not solve the problems. Here are the steps I took and my assumptions:
An always present vnet0: during my examinations, I wanted to trace what config changes happen when removing / adding the vnet0 adapter, so I removed the vnet0 adapter, saved the configuration, added it back and saved again. Because when first adding the adapter, it created it as host only and I had to switch it to bridged, now whenever the bridged doesn't work, it defaults back to the host-only version and it's also visible as a non-privileged user - there always as host-only. Only when I run it with admin permission will I know if it's working or not - when it stays as host-only, it won't work, when it switches to bridged it will work.
While the always present vnet0 adapter is handy, it does not resolve the issue. However, it made playing around much faster.
One of the things I do after installing new software is to analyze what components are automatically started and then to set all that to manually which doesn't have to be run as part of the boot. E.g. for starting vmware, I have a script which will start the services and then resume my default vm. Since I was only using the bridged network adapter, the dhcp and nat services were not part of that script.
And this is what got my configuration to work - manually starting the dhcp service.
Now, since I don't assume that all the others with this problem follow a similar approach (setting services to manual), I assume it is the combination of both - having vmnet0 always present and starting the according service. I leave it to the VMware specialists to figure out what is the core problem. I did run a trace what happens when the DHCP service is started, but found nothing conclusive. It does a couple of updates in the registry to the winsock2 configuration, but that didn't make sense to me.
Bottom line - if Tony's instructions don't solve the problem for you, create the persistent vmnet0 adapter and make sure the DHCP service runs.
Hope this helps someone in some way,
Thanks for your feed back. Ralf and Andy,
I hope to confirm one thing, after you applied the workaround, did your VM able to connect to vmnet0 as bridged network? The workaround would not make the vmnet0 always visible in Virtual Network Editor(VDE), you have to give admin privileges to get it visible.
So, there are two different issues.
1. Invisible vmnet0 is expected when VDE does not have admin privileges.
2. After applied the workaround, if you give the VDE admin privileges, but the vmnet0 is still invisible and vm cannot use bridged mode, please let us know.
For current 12.5 version, we do not recommend you delete any default network adapter, any changs to these default network adapters (vmnet0,vmnet1,vmnet8) would trigger the vmnet0 stop working issue. And restore default would not help. I think you have to apply the workaroud again. Thank you.
Hi Tony, thanks to you and VMware in general for troubleshooting this issue and pointing out a solution. It is a very positive experience to witness such a fast reaction.
I do not recall if the vmnet0 was visible when running VDE in Admin mode when it was not working, because I almost immediately had the always visible vmnet0. Speculating, I would say it was probably not, but is more of a side-effect than the root cause.
Since in my case, I can turn the non-working configuration into a working one by just starting up the DHCP service, I assume it is some sort of initialization that is performed by this service and which only happens if certain conditions are met (present in the standard configuration).
So, besides your recommendation about not removing any network adapters, I would also add: "keep all services on automatic".
I would play around a bit more, but unfortunately require my VMs today to work. So, it's "never change a running system" for now. :smileylaugh::smileysilly::smileylaugh:
I had the same problem.
I'm running windows 10 professional 64 bits
VMware-workstation-full-12.1.1-3770994 works fine and no problems with virtual network editor
But if I upgrade it to VMware-workstation-full-12.5.0-4352439 I'm loosing my setting on virtual network editor.
Same problem if I uninstall the VMware-workstation-full-12.5.0-4352439 and reinstall it from nothing.
After installing I couldn't see VMware bridge protocol and I couln't install it.
Did you remove vmnet1 and VMnet8 in 12.1.1? If you have tried my workaround in this thread but failed to resolve the issue, could you send me a copy a support bundle?
To collect support bundle, there are couple of ways:
1. From Workstation UI: Go to Help -> Support -> Collect Support Data... and upload the support bundle zip file. (If you have any issue to run the UI, you can use method 2)
2. For Workstation Player/Workstation Pro: Go to Player/Workstation Pro installation path: C:\Program Files(x86)\VMware\VMware Player (VMware Workstation), find the vm-support.vbs and double click it.
Upload the vmsupport-2016-*-*.zip to the forum, or if you do not want to upload to here, you can send it to me directly. My email is: twang at vmware.com
Thank you for your understanding and appreciate it.
It is confirmed that Workstation 12.5 bridged networking is 100% broken. Doesnt matter if you upgrade, fresh install, intel or broadcom NICs, etc. Bridged networking does NOT work after reboot. Its not antivirus, its not leftover data on the system.
Reverting to 12.1.1 resolves all issues immediately. This is the fastest way to get on with your lives.
I tried everything including upgrade from 12.1.1, uninstall and complete cleanup of all old VMware registry entries and folders. I even tried installing using the local admin profile to eliminate possible UAC issues. Nothing works once you reboot.
Those of us that rely on programs such as this for our daily work do not have time to do your QA testing for you, which seems to be a bigger trend with lots of software companies these days. The way I see it VMware once again owes me 2 hours of my life back for trying to get another broken product that was released to the public without proper QA testing working.
I use Win10x64 fully patched. Intel Xeons and NICs on one system, AMD and Broadcom on another. Same issues with both.
Really sorry for the inconvenience brought to you, hope this workaround works for you:
Install WS12.5 and change the regkey:
Start REG_WORD 0x00000003(3)
change from 3 to 0x00000002(2).
Finally restart your host