Overview
Desktop power management allows you to specify a sleep state for power savings. The availability of different sleep states varies with the Cloud provider (like Azure) or network hypervisor platform (like vSphere). See Workspot Compatibility Matrices.
Power-management parameters are specified in Workspot Control primarily with Time Limit Policies. Some aspects are set in Desktop Pool definitions, Application Server Pool definitions, and Warmup Policies.
Sleep States
Workspot currently supports the following standard sleep states, when available:
S0 (running).
S3 (pause).
S4 (hibernation).
S5 (power off/shutdown).
Currently, no platform supports both pause and hibernation.
Use of the term “Sleep”
In this document, “Sleep” means “whichever power-saving state is configured: pause, hibernation, or shutdown.”
Persistent Desktops
.png?sv=2022-11-02&spr=https&st=2026-04-22T10%3A17%3A31Z&se=2026-04-22T10%3A29%3A31Z&sr=c&sp=r&sig=UQse%2BFUq7IOgfxpUqPaiVRPD4irVMjT4O8uxn92q12w%3D)
Power management in persistent desktop pools.
Persistent desktops enter sleep if no user is connected and the “Sleep After Disconnect” timer (specified in Timeout Policies) has expired. They awaken from sleep when the user connects to them. See the state diagram below.
Once the user is connected, sleep is deferred until the user signs out or until first the “Idle Timeout” timer expires and then the “Sleep After Disconnect” timeout expires.
The desktop is idle when there is no keyboard or mouse input: no other activity counts, no matter how busy the desktop is otherwise. Any keyboard or mouse activity resets the idle timer.
The desktop continues to run while disconnected. The user can reconnect to it and continue as if nothing has happened.
The “Sleep After Disconnect” timer runs after the Client becomes disconnected for any reason. It is reset when the Client reconnects.
Depending on the Cloud provider, the operating system, and the capabilities of the desktop template, the sleep mode may be pause, hibernation, shutdown, or even “none”: that is, nothing happens after the “Sleep After Disconnect” timeout.
Non-Persistent Desktops
Power management in non-persistent desktop pools.
Non-persistent desktops are similar to persistent desktops, with these exceptions:
Unlike persistent desktops, where the desktop is assigned to the user permanently, a non-persistent desktop belongs to the user only only for the duration of a single sign-in session. Once they are signed out (usually via the “Sign Out After Disconnect” timer in Timeout Policies), the desktop is no longer theirs, and they will probably get a different one next time.
Non-persistent desktops are never put into a power-saving mode during the user’s session. The user is signed out instead. This ensures that the desktop will eventually become available to someone else.
Non-persistent desktops are deleted and reimaged on a selectable schedule including “After Every Logout,” “Never,” and values in between. This prevents malware from accumulating.
If there is no Warmup Policy defined for the pool, the full number of desktops is maintained continuously.
The “Control Images and Boots VM” state (in the diagram above) becomes “Control Boots the VM.”
The “Control Deassigns and Deletes VM” state becomes “Control Deassigns the VM.”
If there is a Warmup Policy, the diagram is broadly correct, but see the next bullet.
To prevent users from waiting while a desktop is reimaged or booted, a Warmup Policy can specify that some desktops should be imaged in advance.
Warmup Policies provide the option to put newly warmed-up desktops to sleep (paused, hibernated, or shut down) while waiting for a user.
When the Warmup Policy calls for fewer desktops, they provide the option to put the extra warmed-up desktops to sleep instead of deleting them.