Power Management: Shutdown and Hibernation

This article discusses two power-management features: Shutdown (Start/Stop) and Hibernation, which are complex enough in practice to require in-depth discussion.

The other two modes, “Sleep” and “Always On,” are simple enough that they need not be discussed in detail.

Unlike the other System Sleeping States, shutdown is almost always available.
In the special case of Cloud providers that often run out of inventory of a specific VM type, but have substitutes available, a shutdown VM can be booted into a different VM type, but a hibernated one can’t.

How Workspot Uses Power Management

A Workspot desktop or Application Server may enter a power-managed state under these conditions, if allowed by Time Limits Policies, Warmup Policies, and Server Scaling Policies, and Load-Balancing Policies:

When the device has no signed-in users.
When the user has been disconnected for longer than the “Sleep After Disconnect” or “Sign Out After Disconnect” time limit.

The upshot is that:

Servers and desktops with a signed-in, connected user never enter a power-management state.
Your servers and desktops will run forever unless you set your Time Limits Policies properly.
- Set the “Sleep/Sign Out After Disconnect" timeout to ensure that power-managed states are enabled and “Idle Timeout” to ensure they do not remain connected forever.
- Closing the Workspot Client counts only as a disconnect. The session remains open until the “Sleep/Sign Out After Disconnect” timer expires to allow users to resume their sessions from another local device.

Power-Management States

The full list of power-management modes supported by Workspot and their corresponding System Sleeping States is:

Always On (S0). The system is kept running with no attempt at power management. (The system can still be rebooted or shut down for reasons other than power management.)
Sleep: Also called Pause/Resume (S1-S4). The system is placed into one of the Sleep States to save power. The operating system context is retained, but typically all network connections are closed upon Sleep. Note that “Sleep” and “Pause” both include “Hibernation” unless specified otherwise.
Hibernation (S4): The operating system state is saved to a file and the VM is shut down. When booted, the system resumes to a similar state as before, though all network connections are closed upon Sleep.
Shutdown: (S5): The system is shut down. The operating system state is not saved. When the system is restarted, it is a cold boot.
Deletion: (N/A): The system is shut down and deleted. Used when non-persistent desktops and Application Servers are reimaged rather than rebooted.

Note: Different Clouds support different power-management modes. See the Power Management Compatibility Matrix for more information.

Note: All modes besides “Always On” require that the “Pause Resume Service” selective feature be enabled, as shown on the “Details” page of Workspot Watch.

Hibernation Overview

Hibernation (S4) is considered to be less desirable than the other sleeping states (S1-S3), so Workspot provides it as an option when these other states are not available.

The Workspot Hibernation (sleeping state S4) is the same in general as in ordinary Windows devices. After an idle timeout, the state of the user’s desktop is saved to hiberfil.sys and then the desktop is shut down. In Azure, this is called “(Hibernated) deallocated.”

When the user clicks on the desktop icon in the Workspot Client, the desktop is booted, its state is restored from hiberfil.sys, and the user resumes working as if nothing has happened. This means that, except for the longer connection delay, the user experience is the same as when the desktop never entered a power-managed state at all or used a different sleeping state (S1-S3) instead.

How Workspot Hibernation Works

Entering Hibernation

Workspot Hibernation is controlled by a Time Limit Policy. As with the other power-saving modes, the desktop enters hibernation after two events have occurred in succession:

The network connection is dropped by the user or due to network conditions, or the Idle Timeout expires. In the latter case, after giving the user a warning that the connection will soon close due to lack of mouse/keyboard input, the desktop connection is closed.
1. Once the desktop is disconnected for any reason, the Sleep After Disconnect timer starts counting down. The user’s desktop continues to run undisturbed.
2. If the user reconnects, the Sleep After Disconnect countdown is aborted and the Idle countdown is reset.
If the user does not reconnect before the Sleep After Disconnect timer expires, the desktop hibernates.

Exiting Hibernation

The desktop exits hibernation and restores its previous state when the user clicks on the desktop icon in the Workspot Client, or when the desktop is awakened by a Maintenance Policy for a schedule maintenance window, or when the Control administrator selects the “Resume” option on the desktop’s “Actions” menu.

The desktop exits hibernation without restoring its previous state if the user or administrator uses the “Reboot” option.

Hibernation Limitations

Not supported on all Cloud providers or all operating systems. See Workspot Compatibility Matrices.
VM size limitations:
- Microsoft Azure limits hibernation to VMs with less than 112 GB of virtual RAM.
- Amazon AWS EC2 hibernation to VMs with less than 32 GB of virtual RAM.
General Microsoft Azure limitations:
- At the time of this writing, Microsoft Azure has released its Azure Hibernation feature as Preview rather than General Availability.
- Microsoft does not yet support hibernation in all regions.
- In Azure, you must use a template that supports hibernation. You can create appropriate templates in Control. Contact Workspot to migrate existing pools.
Hibernation is supported on persistent desktop pools only. This includes some GPU desktops.
- It is not supported on non-persistent desktops or application servers.
Hibernation requires the “Pause Resume Service” selective feature be enabled, as shown on the “Details” page of Workspot Watch. Contact Workspot if you need it enabled.
Hiberfil.sys must be on the C: drive of the desktop VM.
Control refers to Hibernation as “Pause” or “Sleep” when reporting the status of individual desktops and desktop events, and as “Power Management” otherwise.
Resuming from hibernation in Azure can be slower than expected.
Hibernation relies on Time Limits Polices. Changes to Time Limits Policies do not take effect until the next time the Workspot Agent restarts on the desktop or server, which happens once every 24 hours and when the virtual machine is rebooted.

Managing Hibernation

Hibernation at the Pool Level

A pool that supports Sleep or Hibernation lists “Power Management: Enabled” on the “Resources > poolname > Manage Desktop Pool” page. Such a pool will use Sleep or Hibernation, applying the timeouts defined by its Time Limits Policy.

A pool that does not support Sleep or Hibernation lists “Power Management: Not Enabled” on the “Resources > poolname > Manage Desktop Pool” page.

Workspot Control calls Hibernation “Pause” in status displays and Event messages.

Hibernation can be ended in Control by the “Resume” and “Reboot” options in the “Resources > poolname > Manage Desktop Pool > actions” menu and by Maintenance Policies.

Amazon Workspaces Core Hibernation

When creating a desktop pool on Amazon Workspaces Core, the “Power Management Method” give you the option of “Sleep” (Hibernation) or “Shutdown” as the action taken when the “Sleep After Disconnect” Time Limits Policy timer expires.

Form for creating a cloud desktop pool with highlighted power management method option.

Microsoft Azure Hibernation

Note: On Azure (only), there is no pool-level Hibernation enable/disable toggle. Hibernation is selected when a new template is created and cannot be changed afterward. Cloned templates inherit the Hibernation settings of their parents. Pools using Hibernation-enabled templates will use Hibernation if the Time Limits Policy allows it (by setting “Sleep After Disconnect” to any value except “Never”).

Hibernation at the Template Level (Azure Only)

When building an Azure Marketplace template, the first screen of the “Setup > Cloud > cloudname > Build Template” workflow has an “Enable Power Management” checkbox. This will enable or disable power management on the template. Also, it ensures that only appropriate templates can be selected on the next screen. Template creation works as before otherwise.

Cloned templates inherit the hibernation enable/disable setting of their parents.

Shutdown Overview

*Enabling shutdown on a Microsoft Azure pool.*

Form for creating a cloud desktop pool with highlighted power management method option. — *Enabling shutdown on an Amazon Workspaces Core pool.*

Shutdown is available for persistent desktops on some Clouds when Sleep and Hibernation are not available (see Power Management Compatibility Matrix). After both the “Idle Timeout” and the “Sleep After Disconnect” timeout have expired, the user’s desktop is shut down. Its current state is not saved. When the user accesses the desktop later, it is powered on and the user is presented with a freshly rebooted desktop.

Like Hibernation, Shutdown is available when the “Pause Resume Service” selective feature is enabled.

How it Works

Shutdown is available only if Sleep and Hibernation are not possible for a given pool (or, in the case of Amazon Workspaces Core, if it has been selected instead of Hibernation). It is enabled or disabled on the “Add/Edit Pool” page and controlled by a Time Limits Policy.

As with the other power-saving modes, the desktop enters Shutdown after two events have occurred in succession:

The network connection is dropped OR the Idle Timeout expires. In the latter case, after giving the user a warning that the connection will soon close due to lack of mouse/keyboard input, the desktop connection is closed and the Sleep After Disconnect timer begins to count down. The user’s desktop continues to run undisturbed. If the user reconnects, the Sleep After Disconnect countdown is aborted and the Idle countdown is reset.
If the Sleep After Disconnect timer expires before the user reconnects, the desktop shuts down.

The desktop restarts when the user clicks on the desktop icon in the Workspot Client or when an administrative event reboots it.

Limitations

This power-saving method is inherently destructive to any unsaved data the users might have.
Enabling or disabling Idle Shutdown does not take effect until the next time the Workspot Agent restarts on the desktop or server, which happens once every 24 hours and when the virtual machine is rebooted. This is also true of any changes to Time Limit Policies.

Managing Shutdown in Azure

Note: Due to a bug, the “Idle Shutdown” menu shows “-- Select --” when grayed out instead of its actual state of “Disabled.”

If Shutdown is available for a given pool, the “Idle Shutdown” entry in “Resources > poolname > Edit Pool” can be set to “Enabled” or “Disabled.” When enabled, shutdown will honor the settings in the Time Limits Policy specified just above it.

If Shutdown is not available for the pool, the “Idle Shutdown” menu is greyed out.

Managing Shutdown in Amazon Workspaces Core

Set the “Power Management Method” on the “Resources > poolname > Edit Pool” page or the “Resources > Add Pool” page to either “Sleep” (Hibernate) or “Shutdown.”

Shutdown Best Practices

Disabling shutdown may leave the desktops running 24/7, which can be expensive. On the other hand, shutting a user’s desktop down closes all running processes and is destructive to unsaved data. Therefore:

Set longer timeouts than you would for Sleep or Hibernation to prevent work disruption.
Examine the auto-save settings for your desktop users’ software to minimize the possibility of data loss.