GB10
Contributor
Contributor

Bug? Why do VM Networking settings always change to “Bridged” when the VM gets shutdown?

Jump to solution

Using latest Workstation 16 Pro, when I set a VM to use “Vmnet1” (or any other available option, like “Host”), the setting saves to the vmx fine, but then changes back to “Bridged” when the VM shutsdown.
Is that normal behaviour and if so, how does one persist custom network configurations?

0 Kudos
1 Solution

Accepted Solutions
a_p_
Leadership
Leadership

Interesting issue.

Since the VM seems to have been copied from ESXi, it may be worth a try to delete all "ethernet" related lines from the VM's .vmx file, and then add a new network adapter from the Workstation GUI. Maybe one of the non-Workstation settings causes that strange behavior.

Pleas ensure that VMware Workstation (or at least the VM's tab) is closed when you edit the .vmx file.

André

View solution in original post

13 Replies
GB10
Contributor
Contributor

Does anyone else experience this problem, or not? This is a serious issue for what I need to achieve, so any comments appreciated.

0 Kudos
Technogeezer
Champion
Champion

I assume that you are making these setting changes via the GUI, and not manually editing the vmx file.

GB10
Contributor
Contributor

Thanks. Correct. Network setting changes made via the GUI, then seen to be correct in the vmx, which is then closed before running the VM. As the VM shuts down, the vmx changes and the GUI shows the Network has reverted to "Bridged". The same occurs despite downgrading Workstation to 16.1.2 and 15.5.7. The VMs were downloaded from ESX Servers running vSphere 5 Essentials. The VMs appear to run fine under Workstation, apart from this issue, preventing the network configuration I need.

0 Kudos
GB10
Contributor
Contributor

Could users of Workstation Pro please share whether the reset of Network to "Bridged" is normal or not?

0 Kudos
RDPetruska
Leadership
Leadership

@GB10 wrote:

Could users of Workstation Pro please share whether the reset of Network to "Bridged" is normal or not?


It is definitely NOT normal behavior.  I've been following this thread and have absolutely no idea why your system is doing that.

CarltonR
Hot Shot
Hot Shot

As @RDPetruska says, this is not normal . . . just to try and get a broader understanding of the issue, I have a few questions.

 

- You say that the VMs were moved from an ESXi server, are you seeing the same issue for VMs that were originally created 'natively' within VMware Workstation.  In other words, is this unique to the migrated ESXi VM or are you seeing this issue across the board ?

- In the original question you mention 'a VM' but further down, when explaining the original source being from an ESXi server you refer to 'VMs'.  Assuming that more than one VM was moved is this occurring for all that were moved . . . or was this just a 'keyboard' mistype.

- How did you import the ESXi VM into VMware Workstation and which files were used ?

- as a matter of interest, what is the VMware Workstation Hosts OS ?

 

Post Note: other information that may well be helpful.

- what is the VM Guest operating system and its function ?

- is VMware Tools currently installed on the VM ?

- and, are there any plugins/scripts that have been added to VMware Workstation ?

GB10
Contributor
Contributor

Thanks for your questions.

  1. I have no VMs natively created by Workstation, yet. What would be a quick VM to create, to test the possibility the ESXi server source is the issue?
  2. Same issue for all 3 VMs downloaded from ESXi server. Downloads done via vSphere client using “download” of each VM’s folder from datastore, hence all VM files were copied to their own folder on Workstation host. VM guests are a Linux firewall, Windows Server 2016 and Windows 10 PC. VMware Tools were auto-updated on each VM, by Workstation.
  3. Workstation host OS is Windows 10 Pro 64bit. No plugins or scripts AFAIK, as this is a new Workstation install. VMs had no scripts on ESXi, AFAIK.
0 Kudos
CarltonR
Hot Shot
Hot Shot

Recommendations, observation and yup, sorry more questions . . .

1. "no VMs natively created by Workstation, yet. What would be a quick VM to create" [@GB10

Try Win 10 (first test the VMware Workstation without VMTools, and then with, to see if the GUI/.vmx retains the network setting after shutting down the VM)

2. "Same issue for all 3 VMs downloaded from ESXi server" [@GB10]

- what where the file types that were copied to their own folder on the Workstation host ?

- and how did you setup the VMs within VMware Workstation ?

One additional thing, could you humor me and uninstall VMTools from one of the ESXi migrated Windows VMs.  Clearly having first secured a backup of the VM before doing so, and then test.

GB10
Contributor
Contributor

Thanks & will do, though it’ll be early next week before I can.

File types were everything created by ESXi including vmdk, vmxf, vmsd, vmx, nvram, log. I appreciate some are surplus to requirements but didn't think any would cause this, but I may be wrong?
VMs then appeared with no apparent issues by right-click on My Computer, then “Scan for VMs”.

0 Kudos
a_p_
Leadership
Leadership

Did you check the VM's vmware.log after shutting down one of the affected VMs, to see whether it contains helpful information about the issue you see.

André

0 Kudos
GB10
Contributor
Contributor

Trying this on a new laptop running Win 10 64, the issue continues. I now know that
ethernet0.connectionType = "hostonly"
gets correctly set by the VmWs GUI and saved to the vmx, but during power on of the VM the vmx changes to contain 
ethernet0.connectionType = "bridged"

I attach the vmx's (renamed *.txt) and the log. Please help, as this is a showstopper to the network of VMs I need to run on workstation.

0 Kudos
a_p_
Leadership
Leadership

Interesting issue.

Since the VM seems to have been copied from ESXi, it may be worth a try to delete all "ethernet" related lines from the VM's .vmx file, and then add a new network adapter from the Workstation GUI. Maybe one of the non-Workstation settings causes that strange behavior.

Pleas ensure that VMware Workstation (or at least the VM's tab) is closed when you edit the .vmx file.

André

GB10
Contributor
Contributor

Awesome! That's fixed it, thank you!!

0 Kudos