VM Power Management - Suspend vs Put guest OS into standby

[mvrk]

Hi,

Can someone explain what's the difference between the options "Suspend the virtual machine" and "Put the guest OS into standby mode and leave the virtual machine powered on" ?

Best regards.

[abhilashhb]

Suspend the virtual machine	Stops all processes, which saves resources, and copies the contents of the virtual machine's memory to the virtual machine's .vmss file. Writing the memory to the.vmss file is useful if you need to copy the file to help with a troubleshooting scenario.
Put the guest operating system in standby mode and leave the virtual machine powered on	All processes stop running, but virtual devices remain connected.

[sudotsp]

Does the second option allow the virtual machine to be accessed via RDP? That's kind of what we're looking for...

[continuum]

To be able to reach a VM via RDP in a reliable way you need:
VM must be always ON.
If that is not acceptable you need a decision.
Route A: ESXi handles sleep and wakeup operations and your users are required to interact with ESXi  and resume the VM before they can connect via RDP
Route B: GuestOS goes to sleep when it wants and the VM uses a network-card that is ALWAYS ON and which is able to wake up the sleeping guestOS.
In my experience route A is ugly but quite predictable and reliable.
Option B appears to be the more elegant solution but in my experience it to often ended with a VM in a state that required a hard reset via ESXi-commands.
Also this option would need to interact with local physical hardware which you should avoid for portability reasons.
All problems with route A are basically solved.
For route B you first need to master the problem "wake on lan ESXi VM" - this is not trivial and probably needs extra google-hours when ever ESXi or hardware changes.
Anyway - you asked for a suggestion ...
Either live with "VM needs to be always on" or establish a procedure that sends a "resume VM" command to ESXi before it starts the rdp-connection.
With route B you open a can of worms and it definetely needs additional research.
Worst case: your solution is based on wake-on-lan functions and you have a state where the guestOS is asleep and the wake-on-lan solution fails. (not too far fetched at all ...)
Now as ESXi assumes the VM is running you need a hard reset of the VM - which may end with some data loss ....
If  you are the guy that has to answer the user phonecalls every friday night "cant reach my VM .... help !" go with VM must be always ON.
None of the other two ways will give you 52 call-free friday nights next year.
Ulli