Virtual machine fine for months. Added a 2nd VM (as a test), ever since first VM "no network access" (Windows Server 2016)

[joescat]

I searched VMWare troubleshooting docs and tried ALL of the steps, and searched here. Surprised I didn't find a solution so here goes:

VMWare Workstation Pro v15.5. Running a single VM just fine (Windows Server 2016 Standard).

I recently added a second VM, a Windows Server 2003 Standard as a proof of concept only, it will never (hopefully) need to run on this host. This new VM was running on VMWare Player v6.x, I used the latest (v6.2.0) VMware vCenter Converter Standalone to "upgrade" it to the latest VMware it would convert to (hardware version 11 I recall). The new VM started up and a cursory check was fine. Since it was a test of a old but still running VM on another host, I changed networking to "Host only". I've since "removed" the new VM from VMware Workstation.

Now the original VM that was running flawlessly shows "no network access". I've tried everything I can think of! All appears fine with networking - the adapter is enabled and shows "connected", it has it's static ip address and all other pertinent network settings. The host's networking is fine, fully in production. The symptoms are simply "no network access", the tray icon has a yellow "!", the "network" is shown as an "Unidentified Network", "Public", Access Type: no network access" on "Ethernet0" adapter. Looking at the properties, everything appears correct. There is activity shown there, network traffic being sent a bit, and received a lot less but at least some. I can ping the loopback address but nothing else.

The network setting for the VM is Bridged (not checked "Replicate physical network state") as it always has been. "Connected" and "Connect at power on" are checked.

I've reverted the VM back to quite a few known good previous snapshots, including all the way back to near the beginning of the build - no luck. Uninstalled, reinstalled VMware Workstation. Allowed the upgrade from v15.5 to v15.5.5. Performed every trick in the book I know of resetting networking with netsh and even the "reset network" in the O/S GUI. No glaring items of interest are in the System or Application logs of either the host or the VM having the problem.

I've seen so tried "adding" a network adapter "Intel Pro 1000/MT" nic (replacing the original "Intel 82574L Gigabit network connection), that flunked with the new adapter reporting the hardware cannot start. Update driver for the original nic yields no available newer drivers. I've tried disabling the Windows firewall, uninstalling the Avast anti-malware software (ONLY the remote control module was installed anyway), and that's been solid since the beginning and on many other systems under my care. I've tried regenerating the MAC address for the VM. I'm still stuck!

[Mits2020 · Accepted solution]

Please read the 2nd Known Issue in VMware Workstation 15.5.5 Pro Release Notes

Your Virtual Network Editor should look like the attached image, listing 3 virtual networks.

[joescat]

Thank You! You're definitely onto something here. VMnet0 is missing in the editor. However, I cannot get the change to remain! I am running as Administrator (logged in as), I can make intended changes (only "Change Settings" is available, everything else is greyed out), I am prompted by UAC and can ok it. I've added VMnet0 as appropriate, Apply and Ok to close the editor. When I relaunch the Virtual Network Editor, all changes are gone ("VMnet0" is missing again)! My changes to Bridged Automatic "Automatic Settings" and deselected all network adapters except the one that should be used (per documentation) - THAT setting is retained when I revisit it (by again changing settings, making VMnet0 reappear).

I've tried closing all Workstation GUI's and launching the Virtual Network Editor separately with the same results - the change is not saved when relaunching.

Peculiar, I've manually stopped all VMware services, the tray icon remains running, and Workstation Pro launches anyway. I did not try to start any VMs under those conditions. Still, changes in the editor do not persist.

I'm confident this would be the solution - IF I could get the setting to stick!

For brevity, I've reverted back to version 15.5.0 of Workstation Pro (as originally was running perfectly). I will again upgrade to the latest later today during a maintenance window, though I don't recall a host server restart is required, I will likely do so anyway.

I don't think it should be important, but just in case . . . the only utilized network connection on the host is a nic team set up in the O/S using two of the available motherboard nics. Networking on the host has never been an issue:

The choices available in the editor:

[joescat]

My current thought is if I disabled all of the network adapters on the host except for the one desired connection, automatic bridging in VMware would have only one network adapter to choose from. But that seems to be sledge hammer approach, as well a eliminating the potential use of additional network adapters should they ever be needed.

[Mits2020]

I also think that reducing the number of variables is essential for troubleshooting, so I think your suggestion to start with one NIC is the way to go.

Then, in the Virtual Network Editor, I'd suggest using the "Restore Defaults" feature (bottom left button on the screenshot I provided earlier) when the guests are powered off. This should restore the 3 VMnets in a permanent way and you'd just have to reconfigure the guest settings (networking type, shared folders etc).

Then you can gradually add one NIC at a time and see what works and what doesn't.

[joescat]

In the meantime, something very interesting:

https://communities.vmware.com/thread/449878

It's old, but seems to have SOME effect on my host. I'm logged in as Administrator. If I run the Virtual Network Editor (vmnetcfg.exe) by not specifying a user, VMnet0 is gone. RunAs...Administrator, VMnet0 is listed! Eureka I'd hoped. I ran Workstation (GUI) as Administrator - nope, still no networking.

I suspect the GUI is not what is actually launching VMware Workstation, so it's not really running as Administrator.

This leads me to another things to try . . . setting the several services to run as Administrator. But again for that possible solution, I shouldn't have to do that. And, it doesn't explain why these symptoms are now happening, the VM has been working fine for months. The only discernible change is temporarily adding a 2nd VM.

I'm now trying to research anomalies where the Virtual Network Editor doesn't save its changes. That should be key?

I'll reply with any findings - no forum is at its best unless findings and solutions are included! In the meantime I welcome any input and thanks so far for the help!

[joescat]

Great news: The VM has network access again!

The bad news . . . I did quite a few changes and experiments, so I'm not 100% certain exactly what was the precise solution. :smileyblush:

The condition kept changing - often "by themselves". I mean, I could check or change something, go back in the same thing and look, and settings were different. NOT my usual Administrative style!

What's definitely working right now:

Onboard nics 1 and 2 are teamed using the O/S as described before, looking like:

I did disable the other various nics, instead disabled their association with network services.

The two VMware "nic"s created, "VMnet1" and "VMnet8". I don't know why "VMnet0" is not also created, nor my VM is working now without one?

It makes more sense to me that VMware would create VMnet0 also upon installation - I've never seen that adapter listed on the host

I left VMnet1 and VMnet8 alone:

Finally, the "real" nic actually being used by the host, and the one I want to bridge to:

Not shown is that TCP/IP v4 is enabled

I launch the Virtual Network Editor logged in as Administrator, but NOT choose to "Run As..." any user:

??? I finally DO have VMnet0 showing up and not disappearing when I [Ok] it and launch the editor again. But, it's not showing VMnet is associated with any network adapter. Weird. I don't want to touch "Change Settings" ATM, a system backup is running so I can save everything while it's working. But, the ONLY choice when modifying VMnet0 is the "Microsoft Network Adapter Multiplexor Driver" - fine! That's the name of the nic team I want to use! So although that choice doesn't remain visible as selected, things are working. That's the part I can't (yet or ever?) be certain of - its it because it's the only nic with VMware Bridging enabled, or is my change in the VNE really taking effect and just not displaying it if I just go look?

/sigh I want concise answers, not guesses.

TL;DR warning:

Potentially related:

I've had other outside "Administrators" remoted into this host in the past - it was born to run their software products, and they definitely were very weak with tech knowledge, and had a single goal of making their product work so had little care of anything else. I've found some anomalies in NTFS folder/file permissions to explore in greater detail once I have a solid way back should things get worse. Messing with NTFS permissions is always a slippery slope.

I don't want to reveal the VM's name as it contains a product name and that would throw their tech support potential under the bus. I think I may have inherited an odd permissions issue (comically including permissions inheritance bada-boom).

The folder where the VM is stored:

I'm running as Administrator, confirmed a member of the local Administrators group. This is a stand-alone server so only local permissions apply. By inheritance via my group membership, I should have unfettered access to the folder and all below it. There are no "deny" permissions. It's perhaps not behaving quite that way!

I'm currently copying the entire VM's folder to a USB drive so permissions will not be copied, as well as a backup software full backup of the O/S volume. Once that's done I can dare tinker with the permissions to try and make them "correct".

I still don't know why the VNE won't save changes as expected.

Thanks for staying tuned. I'll update if any new revelations are encountered.

Correct answer credit to Mits2020 - Thank You! The tip of the Virtual Network Editor led me down the winding path that ultimately got the VM working - at least right now!

[Mits2020]

Thank you very much for your detailed report. The takeaway lesson is that having other people login on a production machine with admin privileges is a very bad idea. If you had mentioned this from the beginning we'd have suspected permission issues.

This is why cloud computing was born, if they want a VM for their purposes, let them rent one on the cloud. If they want you to support them, you'd better do it on their own VM and allowing You to login there as admin