VMware Communities
Olaf_van_der_Sp
Enthusiast
Enthusiast

Cannot change network to bridged: No unbridged host adapters

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..

Any ideas?

Tags (1)
59 Replies
shanemccook
Contributor
Contributor

The workaround worked on my Window 7 x64 machine.  I haven't had an oportunity to try it on my Windows 10 x64.

Reply
0 Kudos
jreeveslcht
Contributor
Contributor

I also used the same workaround and was able to bridge VMnet0 as well as two custom networks (VMnet5, VMnet13) until the latest round of Windows Updates.  I then had to reapply the uninstall/reinstall workaround to get back up and running.

Host: Windows 10 Pro x64

VMWare Workstation 12.5

Intel Wireless AC 7260

Intel Ethernet I217-LM

Reply
0 Kudos
ILuvNips
Contributor
Contributor

Just wondering why the 12.5 update not been pulled and is still being offered as part of the update check and why is there still no fix in sight?

Reply
0 Kudos
Joe17
Contributor
Contributor

I have found a workaround to the issue:

Cause/how to reproduce:
  • Open VMworkstation
  • Open Virtual Network Editor and modify the VMnet configuration removing the NAT VMNet, or assign it to be bridged. (doing this is the only way to setup any VMNET to be bridged to a specific adapter)
  • Save the Configuration, everything will work fine, until you reboot
  • Reboot the PC
  • When Workstation is opened again all the bridged adapters will no longer be connected to physical adapters and re-assignment to physical adapters will not work.
The work around :
  • Open Windows Services (Admin tools -> Services)
  • Find the "VMware NAT Service" and change it to Auto and try to start it. It will fail to start; however the VMnets will now be re-connected to the physical adapters and the configuration will not be lost.  Set the service to Auto start and every time the PC reboots it will try to start it (but fail) and the VMnets stay connected to the physical adapters.
Note: Every time the Virtual Network Editor changes the configuration it will set the "VMware NAT Service" to Disabled (repeat Steps 1+ 2 to fix).

Reply
0 Kudos
eskimo682
Enthusiast
Enthusiast

The dreaded "The network bridge on device 'VMnet0' is not running.  The virtual machine will not be able to communicate with the host or with other machines on your network.".

Apparently this has not been solved yet? Can provide logs&al if needed. Some info:

1. No solutions have worked yet.

2. Nothing running.

3. "Enhanced Keyboard Driver" on

VMnetUserif regedit, no effect.

VMware NAT Service, no effect.

Rebuilding my entire network right now so this doesn't have high priority but I think I know when this went bad so I'll give some quick info in case it would be helpful:

MB: Asus Z170-K (Intel)

Windows 10 Pro, installed 2016.10.06 + updates

Installed VmPlayer 12.5.0.4352439 on 2016.10.11 (and at that point bridged networking was working fine)

2016.10.14 Windows update did some major lengthy update (Feature update, version 1607)

2016.10.15 Update for Windows 10 Version 1607 for x64-based Systems (KB3176936) - worked past midnight Smiley Happy

2016.10.15 Security Update for Adobe Flash Player for Windows 10 Version 1607 (for x64-based Systems) (KB3194343)

Bang - no more bridged network

Do not have a physical DVD player installed on this machine yet (will try that one out tomorrow, vmtools hunch -> edit: was a longshot, no effect)

Since people have had this issue a month ago it's not "only" the Windows update that is the culprit but that apparently was the deciding factor for me.

Reply
0 Kudos
RiP2
Contributor
Contributor

That registry fix didn't work after reboot.

Switched back to 12.1 xD

Reply
0 Kudos
yanw
VMware Employee
VMware Employee

Hi, RiP2:

 

   Have you removed the NAT(vmnet8) or Host-only(vmnet1) vmnet? And before the reboot, is there any windows update on your host? thanks

Reply
0 Kudos
yanw
VMware Employee
VMware Employee

If windows update is the culprit, would you please try to uninstall/re-install WS12.5 and have a try? thanks

Reply
0 Kudos
eskimo682
Enthusiast
Enthusiast

Ok, now things got really bad Smiley Sad.

I tried VMware-player-12.1.1-3770994 (on my backup Win10 partition) last night (skipped enchanced keyboard if it asked, don't remember). Then reinstalled 12.5 on the main win10 (skipping enchanced keyboard).

Now I'm getting the following if I try to use 12.1 (on a vm that has the bridged problem). And the 12.5 gets the same so I cannot even start without a bridged network anymore:

"This virtual machine is configured for 64-bit guest operating systems. However, 64-bit operation is not possible. This host supports Intel VT-x, but Intel VT-x is disabled."

and

"Binary translation is incompatible with long mode on this platform. Long mode will be disabled in this virtual environment and applications requiring long mode will not function properly as a result. See http://vmware.com/info?id=152 for more details."

Running a 64-bit host and a 64-bit vm. Haven't changed anything in the bios. Ok, time for hands off until I can read about everything.

Restored an old vm which runs ok on 12.1.

Unfortunately I don't have time for all this mess right now so I'll have a look in a few days. Clearly need to do this systematically and without deadlines. Even if it means installing Windows 7 somewhere temporarily...

Reply
0 Kudos
eskimo682
Enthusiast
Enthusiast

Ok, now I actually have some good info. Decided to have one last go today and now all the problems went away.

Went through all the Asus/Intel drivers and installed (new) versions of them (not necessarily the newest on the net but from the installation CD - thinking those on the CD are least likely to be broken). And no, I did not record each version number as I was grasping at straws at this point.

Possibly the latest Windows updates "upgraded" (or downgraded knowing MS Smiley Happy )  one of these and that's the culprit (for me)?

So these are for Asus Z170-K but I imagine some of the Intel/Realtek drivers are "generic".

Intel chipset 10.1.1.7  (pretty much guessing it is either this one)

Realtek Lan Driver 10.1.505.2015 (or this one)

Management Engine Interface 11.0.0.1157 (which I selected but it did NOT install - not shown as installed at least)

...and the less likely ones... (listing everything for reference)

Intel Rapid Storage 14.5.0.1081

Asmedia usb3.1 1.16.26.1

Asus AI suite 3 1.01.24

Hopefully this helps someone.

As for the really good news, since I have this exact same problem and plenty of copies of "bad" vm's to test with I can probably come up with the exact driver which helped by doing one by one on my backup WIN10. Well, helped me at least...

Now I need to get some work done... maybe in 1-2 days. Or maybe someone else can verify my hunch about the chipset/realtek drivers meanwhile?

Reply
0 Kudos
Kandooly
Contributor
Contributor

Hi,

None of workarounds worked for me to save settings of bridged VMnets. After 4 hours finally I found this way that seems do the trick:

Add below lines to registry for every VMnet that you want to stay in bridge mode and restart the host: (sample is for VMnet0 and VMnet1)

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 1

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLib\VMnetConfig\vmnet1]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Part 2

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetBridge\Adapters]

"Test"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet0]

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMnetLibSaved\VMnetConfig\vmnet1]


G!v3M35

Reply
0 Kudos
JanaZ
Contributor
Contributor

We have been bitten by this bug on multiple VMWare Workstation 12.5 installations. In fact, bridged networking eventually failed every system which we upgraded from 12.1.1. These include multiple Windows 10 Enterprise systems, several Win 10 Pro, Win 7, and two Server 2012 R2 systems. The network cards varied. Most were Intel (all server family), others were Broadcom, at least one Realtek, or in the case of laptops, wireless (primarily Broadcom and Intel adapters). In all, bridged networking failed completely on at least 15 different systems with version 12.5.

The fixes outlined above (reinstalling, removing drivers and dlls, etc.) all proved temporary at best. Sometimes VMnet adapters could be bridged again, sometimes not. When they could, the bridging usually only lasted until the next O/S reboot. We finally gave up and rolled back to version 12.1.

A note to those that do: You may well need to install the VMWare bridging service in the network adapter properties to have bridging work again in V 12.1. Sometimes it comes back by itself, other times not. No apparent correlation to Windows version or network adapter. Once bridging is restored in V 12.1, it keeps on working. Turn off the upgrade notifications if you tire of them each time you start Workstation.

Reply
0 Kudos
TheQuestion
Enthusiast
Enthusiast

JanaZ

We have been bitten by this bug on multiple VMWare Workstation 12.5 installations. In fact, bridged networking eventually failed every system which we upgraded from 12.1.1. These include multiple Windows 10 Enterprise systems, several Win 10 Pro, Win 7, and two Server 2012 R2 systems. The network cards varied. Most were Intel (all server family), others were Broadcom, at least one Realtek, or in the case of laptops, wireless (primarily Broadcom and Intel adapters). In all, bridged networking failed completely on at least 15 different systems with version 12.5.

The fixes outlined above (reinstalling, removing drivers and dlls, etc.) all proved temporary at best. Sometimes VMnet adapters could be bridged again, sometimes not. When they could, the bridging usually only lasted until the next O/S reboot. We finally gave up and rolled back to version 12.1.

A note to those that do: You may well need to install the VMWare bridging service in the network adapter properties to have bridging work again in V 12.1. Sometimes it comes back by itself, other times not. No apparent correlation to Windows version or network adapter. Once bridging is restored in V 12.1, it keeps on working. Turn off the upgrade notifications if you tire of them each time you start Workstation.

GOOD NEWS EVERYBODY!!!!



That's right, this news is so good that I'm using all caps and big font! Guess what. Just 24 hours ago (at the time of me writing this post), VMware released Workstation 12.5.1! :smileygrin:

And guess what has been bug fixed according to the release notes? And I quote:


  • Bridged networking not working If you delete VMnet8 and VMnet1 in the Virtual Network Editor, then bridged networking is no longer available after the host is restarted. This issue could appear after upgrading to Workstation 12.5.

    This issue is resolved.

Time to celebrate! :smileycool:  So if you haven't hit that "Check for Updates" button, then do it now because the issue has finally been fixed!


You can read the release notes for yourself here:


VMware Workstation 12 Pro Version 12.5.1 Release Notes

Reply
0 Kudos
sadiq1435
Enthusiast
Enthusiast

Hi Olaf

No need to uninstall workstation . You can just go the Network Virtual Editor and then click on Change Settings at the bottom of the screen . You will be logged in as administrator and click on Restore Defaults . you will get bakc the original configuration with the Bridged Adapter .

Regards

Sadiq

Reply
0 Kudos
chin2reddy
Enthusiast
Enthusiast

I had the same problem, just reset the network to default settings and Bridged network should show up. If it does not use the repair option while installing the setup.exe.

Reply
0 Kudos
bonnie201110141
VMware Employee
VMware Employee

Hello everyone,

Now Workstation 12.5.1 is available which fixed this issue. Could you kindly please try Workstation 12.5.1 and let us know if there is any other issue? Thanks a lot!

Reply
0 Kudos
RiP2
Contributor
Contributor

Yea, seems to be fixed in build 4542065 Smiley Happy

Reply
0 Kudos
ILuvNips
Contributor
Contributor

12.5.1 installed last Friday and tested then and today and it has fixed the previous issues for me.

Reply
0 Kudos
JanaZ
Contributor
Contributor

Version 12.5.1 does indeed fix the missing bridged network problems. One warning to those upgrading: There appears to be a significant regression when running multiple Windows 7 x32 VMs on a Win 10 x64 host. We noticed this behavior on two systems (out of two tried). Not an exhaustive test, but enough to convince us to roll back to V 12.1.1 again.

Version 12.5.1 appears to have difficulty multitasking access to external devices including network cards but particularly attached USB devices. We saw VMs freeze up for 15 seconds to nearly a minute when accessing a device connected by USB. There were network freezes as well. These problems only appear when more than one (3 - 5 in our case) VMs were running simultaneously. No, this wasn't a resource constraint. One system had 12 cores and 96 GB available, the other had 16 cores and 128 GB. No such issues seen on any previous version of VMWare Workstation.

I can't comment about whether these problems are more generalized to other host and guest operating system combinations.

Reply
0 Kudos
eskimo682
Enthusiast
Enthusiast

Finally had time to do some testing (and then realized it might be moot). Didn't find anything conclusive anyway but will list my steps.

All this on the secondary Win10 system where I switched back to 12.1 to get anything working three weeks ago.

Upgraded (again) to 12.5 (note not 12.5.1 yet as I was curious what eventually fixed the issue for me).

The interesting thing here is that the virtual machine crashed once bluescreen style/VMware caught, then actually worked. Maybe going back to 12.5 after using 12.1 kept the network on for this test. No idea. The vm was working in tar mode though, dead slow.

Updated the Intel chipset and Realtek drivers (which I imagined fixed things last time). Still works, still tar.

Upgraded to 12.15.1, tar disappeared.

Good enough for me for now. Hate not knowing the exact fix earlier and definitely not feeling confident at the moment but no point spending more time on this.

Time for a backup of one vm followed by a VMware tools update hoping that won't break things :smileygrin: .

Reply
0 Kudos