Missing /etc/vmware/networking file

[adahug]

I am using VMware Workstation Pro 17.5.0 build-22583795 on a System76 laptop running Pop!OS 22.04 LTS on Linux kernel version 6.6.6-76060606-generic.  Starting a week or more ago I was having some intermittent networking issues where I would be unable to even ping my default gateway from either the host or any of the guest VMs.  A reboot of the host generally fixed the issue for about a day.  I decided to check for OS updates to see if any of those would fix the issue. After that, my host PC network was fine but the guests never would connect.  I discovered the following things:

• vmnet1 and vmnet8 were missing from my results after running ifconfig.
• /etc/vmware/networking file is missing.
• Uninstalling VMware Workstation Pro 17.5.0 and reinstalling it doesn't create the files again.
• I have a /etc/vmware/networking.lck folder that contains a M44303.lck file that I'm not sure should be there or not.

Is there a way to recreate the file(s) that I need to get networking going again?  At the present moment I don't have a way to see the what was in the file before it was mysteriously removed.

Is there a utility that will recreate the file(s)?

[bluefirestorm]

Have you tried the Virtual Network Editor tool?

sudo vmware-netcfg

On the Windows version there is a "Reset to Default" button but it does not appear to be available on version 16.2.5 on an Ubuntu host.

The default will just put it back to 1 bridged (vmnet0), 1 host-only (vmnet1) and 1 NAT (vmnet8). You add more on your own as needed as well with the Virtual Network Editor tool.

[adahug]

Yes, I did try the Virtual Network Editor tool. The first time I ran it, I got an error message that said "Fail Network configuration is missing. Ensure that /etc/vmware/networking exists". I was really hoping there was a "--reconfigure" or "--regenerate" switch to the "sudo /usr/bin/vmware-netcfg" command that would allow me to recreate the missing network files.

Since there doesn't seem to be, I created a blank file using "touch /etc/vmware/networking" and then ran the tool again. That time I got the error "Fail Network configuration format is unsupported. Ensure that /etc/vmware/networking contains valid data.

After that I found a post online somewhere that contained example data from the file. I copied and pasted it into the file, ran the Network Configuration tool again but got the same error.

I ended up uninstalling Workstation Pro 17.5.0, moving the /etc/vmware/ directory to my desktop (as a backup) and reinstalling Workstation Pro. I moved my license files back to the original location, rebooted, and started Workstation Pro. Running "ifconfig" showed that my vmnet1 and vmnet8 interfaces were back and my network was working correctly again.

However that was fairly short lived as they disappeared again about half way through creating a new VM, which is what I was doing when they first disappeared. So basically, I had to go through the whole process again and, as long as I don't try to add any new VMs, I can keep my network.

Seems like a HUGE bug that adding a new VM kills my network and deletes my virtual interfaces somehow.

[bluefirestorm]

I am still on 16.2.5 with an Ubuntu 22.03 with 6.2.0-39 kernel now.

I don't know if it is a version 17.5.x problem or a Linux kernel/networking problem. There is post that mentions high CPU usage on Windows host for version 17.x when NAT is used.

Perhaps to avoid the whole re-installing episode maybe apart from backing up /etc/vmware/network file more frequently; the corresponding vmnet1 and vmnet8 (and other custom vmnet you might add) needs to be backed up as well. These should have the dhcpd and nat configuration files as well. The data in the network file likely has to match the dhcp and subnet data of the VMnets. Maybe this will at least help you avoid the reinstallation episode. Not sure if permissions of the files is important considering that VNE required sudo authentication.

[adahug]

Thanks for the suggestion. I do weekly backups that "should" include the relevant files.  However, to add insult to injury, my backup device broke about a week before this started happening.  I hope to have that resolved in the next week or so.

[bluefirestorm]

You could try using 17.0.2 instead. It might give you less grief considering all the networking grief with 17.5.0 even with the Windows host equivalent. The license key for 17.5.0 should work for 17.0.x since both have the same major version number.

https://customerconnect.vmware.com/downloads/details?downloadGroup=WKST-1702-LX&productId=1376&rPId=...