VMware Communities
Bradall
Enthusiast
Enthusiast

Guest Virtual Networks lost after sleep/suspend

I have a rhel8 machine as a guest, but have noticed this on ubuntu 18/20 releases as well, if the guest has established virtual networking via libvirt and/or created additional bridges, then if the host is put to sleep/suspend mode and then woken back up all the gues networking is no longer functional. I've searched everywhere and there is little information on this so perhaps it is just a VMware issue? I'll try an alternative later today to see if this is just VMWare related. I've searched here and also can not find too much info. This is with workstation 16, and is repeatable with fusion 11 as well. Both behave the same way. Does anyone have a work around?

Labels (1)
Reply
0 Kudos
12 Replies
continuum
Immortal
Immortal

We need to know what host OS you use, which type of virtual networks you assigned and what exactly you mean with : "if the guest has established virtual networking via libvirt and/or created additional bridges"

General advice: avoid using suspend for the host when any VMs are running.

 

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Bradall
Enthusiast
Enthusiast

Thaks for the response and sorry for the lack of detail but it applies to any libvirt installation by the looks. This only appears to be an issue with VMWare products as i have imported the VM into virtual box and the sleep facility there does not impact the networking.

This is a stock standard RHEL8.3 install with default Server with GUI install. No changes at all to any selection. After the VM boots the following routes will exist.

ip route
default via 172.16.50.2 dev ens160 proto dhcp metric 100
172.16.50.0/24 dev ens160 proto kernel scope link src 172.16.50.134 metric 100
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

If you suspend the then awake the VM the resulting routes are.

ip route
default via 172.16.50.2 dev ens160 proto dhcp metric 100
172.16.50.0/24 dev ens160 proto kernel scope link src 172.16.50.134 metric 100

The VM still thinks the bridge is running. You can use virt-manager to stop and restart the bridge and then the routes return. The more complicated networks behave in the same manner after sleep you need to disable and then reenable each to get them to work again. 

As stated, I can import this exact VM into virtual box and this does not happen. 

Any suggestions are welcome. Thanks. 

 

 

Reply
0 Kudos
continuum
Immortal
Immortal

I still do not know what your host OS is and what type of virtual networking (bridged or NAT) you use ...
If you use a Windows host and NAT networking the workaround is to restart the VMware NAT and DHCP-service after resuming the host after sleep/suspend.
Do not draw conclusions if this problem does not appear in VirtualBox - some things that do not work in Workstation just work flawlessly in VirtualBox - this is one example.

 

Ulli


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
Bradall
Enthusiast
Enthusiast

Sorry, but for clarity. The virtual networking that no longer functions is the networking on the guest. This is not an item regarding the virtual networking of the Type 2 hypervisor. 

 

However to answer the question.

VMWare Workstation PRO on Windows 10.

VMWARE Fusion 11 on a MACOS. 

I'll try the restarting processes on win10 when I get back to the machine. I'm not sure that this will restart the bridge inside of the Guest VM however which is the issue as per the example provided on the bridge on the guest going missing.  

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

If an IP is lost after a sleep/suspend then that is most likely due to the suspend/sleep mode that you are using.

There's hard sleep/suspend modes versus soft sleep/suspend modes.

If you have a soft sleep/suspend mode then the guest will runs scripts to release and renew the IP addresses.

The default is soft sleep/suspend mode...

As you mention both Fusion as well as Workstation..

On Fusion, select the VM, settings -> Advanced -> Power Options --> change "Suspend" to "Suspend Hard"

On Workstation, edit virtual machine settings -> Options tab -> Power -> change "Suspend Guest" to "Suspend"

IIRC then you don't need to change the resume.

Alternatively you would have to look at extending the vmware tools scripts for suspend/resume.

hope this helps,
--
Wil

edit:typo "slow" was meant to be "soft"

 

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Bradall
Enthusiast
Enthusiast

Thank you for that. Seems that Suspend hard keeps the virtual network intact on restore whereas soft appears to corrupt the VM state. 

So it appears that the scripts that tools runs probably does not take into consideration a virtual network and the state restoration restores just the state that is associated with just the physical network. Virtual networks are essentially corrupted with Suspend Guest (on workstation) or Suspend (Fusion). Thanks for the heads up I'll live with the VM still being connected to the network.

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

Yes I figured this would fix your issue.

Note that the soft suspend has its use as well, especially in a network where IP's are handed out by a DHCP server. In that case it is not a bad thing if your VM releases the DHCP address on suspend.
Then on resume it can ask for a new IP address and you won't get IP address conflicts.

That's the idea behind the way it works when you use soft suspends.
It is also possible to keep soft suspend and then customize the scripts that are run by vmware tools on suspend and resume.

More information about that is here:
https://docs.vmware.com/en/VMware-Tools/11.2.0/com.vmware.vsphere.vmwaretools.doc/GUID-B0702BD6-07F5...

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
Bradall
Enthusiast
Enthusiast

Hi, I'm not so much concerned about the external IP address at all but the internal Guest networking being corrupted. I can live with external IP address changes but what I can not live with is the internal and complex network needing manual turn down and restarting each time. I'll have a look at the scripts but I suspect today they are not dealing with internal virtual networking and the state save is ignoring that save for those items. 

Reply
0 Kudos
Bradall
Enthusiast
Enthusiast

Having looked through open VM Tools source the scripts appear to only work with Linux distros that still utilise ifup/down on the interfaces and also Network Manager. Guess that fundamentally answers the questions on later linux distros where these have been migrated. It also answers that anything that is virtual within the guests simply is not dealt with. 

Reply
0 Kudos
wila
Immortal
Immortal

Hi,

OK.. so a hard suspend it is then.

That should at least resolve your issues.
If the potential IP address conflict is no problem for you then I don't see any issues.

--
Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
teruzzi
Contributor
Contributor

Hello, I have quite the same problem in WKST pro 15 & 16...
WIth the difference that the DHCP clinet interfaces do not get the IP after HOST OS (latest and patches Win10) wake-up after sleep.
I found also that is I sleed the vritual machines after OS Host reboot the problem is solved.

Hope to have this problem fixed on day.

 

Saluti

Maurizio

 

Reply
0 Kudos
vmware_usr7
Contributor
Contributor

The workaround from @wila unblocked me... was not able to connect to docker services after resume... after changing from Suspend Guest to Suspend, services are reachable after resume. Thanks @wila!

Reply
0 Kudos