Power Management: Warmup Policies

Last update: March 21, 2024 by Robert Plamondon

Introduction

To save money and energy, non-persistent desktops enter sleep, are shut down, or even (in the case of non-persistent desktops) deleted when not in use. New desktops are awakened, powered up, or created as required.

When the desktop is in an active, running state, users wait only for the connection to be established, which takes a few seconds. If the desktop is in a power-saving state, the delay of resuming the desktop from sleep or shutdown is added. If no active or sleeping desktop is available, the desktop has to be imaged, which can take minutes.

For non-persistent desktop pools (only), Workspot Control's Warmup Policies allow desktops to be created on a schedule, so they are ready before the users sign in. This prevents users from having to wait while their desktops are created (imaged, provisioned) and powered up. This is especially important with desktops that are reimaged after each use, which is typical for non-persistent desktops.

Contents

Prerequisites

• Warmup Policies apply only to non-persistent desktop pools.
• Warmup Policies are not supported for every Cloud or with every billing type. When not supported, customer are not shown the option to define or apply Warmup policies.

How Warmup Policies Work

A Warmup Policy allows you to specify the number of desktops to have ready for users at any given time. This minimizes user wait time.

Tip: Warmup Policies are always optional. Users can always sign in, even when the policy specifies zero desktops. Signing in just takes longer. Users who are signed in can always keep working.

Variations with Cloud Providers

Warmed-up desktops may be put to sleep (paused) while waiting for a use to sign in, since resuming from sleep is much than reimaging. However, this behavior depends on the Cloud provider:

• GCP: Pause/resume is fully supported.
• Azure: Desktops can be shut down and restarted but not paused, which is faster than reimaging and slower than pause/resume.
• AWS: Warmup policies are not supported.
• Amazon Workspaces Core: Neither non-persistent desktops nor warmup policies are not supported.

Start-of-Shift Example

Suppose a shift starts at 08:00 and you expect 50 users to sign in between 08:00 and 08:30. You specify 50 desktops for the 08:00 time slot.

Control ensures that 50 desktops are available at 08:00 by:

• Noting how many desktops are already populated, either in use or sleeping.
• Booting or Provisioning (creating) enough new desktops to bring the total up to 50 by 08:00.
• This process starts twenty minutes early, at 07:40.

Behavior by Cloud type:

• GCP: Once the warmed-up desktops have booted fully, they are optionally to sleep (the default) and are awakened one by one as users sign in. This behavior can be disabled in the warmup policy, in which case the desktops run to the end of the time period.
• Azure: Once the warmed-up desktops have booted fully, they are optionally shut down (the default). They are booted one by one as users sign in. This behavior can be disabled in the warmup policy, in which case the desktops run to the end of the time period.
• AWS: Same as Azure.
• Amazon Workspaces Core: Not supported.

Existing desktops count toward the total of 50:

• The desktops of users who are already signed in.
• Unassigned desktops that were already available for whatever reason.

If user #101 signs in, there are no remaining warmed-up desktops. This means the user has to wait until a new desktop created. The user sees this as a connection delay, adding to the time between clicking on the desktop icon in the Workspot Client and the appearance of the desktop's sign-in screen.

End-of-Shift Example

Suppose the shift ends at 17:00 and you expect no one to sign in from that point on. You specify zero desktops for the 17:00 time slot. As users sign out, their desktops are shut down and not replaced, since the policy calls for zero warmed-up desktops. If everyone signs out (whether manually or through a Time Limits Policy), the number of running desktops falls to zero. If some users continue working, they continue as if nothing has happened (because, for them, nothing has).

Users who sign in after 17:00 will see the same delay as user #101 in the previous example.

You can specify zero desktops even earlier than the end of the shift if you expect that no one will sign in during the latter portion of the shift.

Other Details

When the next time slot calls for fewer warmed-up desktops, the excess desktops are either shut down (but can be booted again later) or deleted at the end of the current time slot. 

When a user clicks on a desktop icon in the Workspot Client but fails to connect successfully, their desktop remains in the Ready state for approximately thirty minutes before giving up and being paused or shut down. If the user connects successfully, the desktop is paused or shut down when the user signs out (manually or through a Time Limits Policy).

Cost Savings

To ensure that the desktops are ready at the specified time, Control provisions the required number of new desktops twenty minutes early. After they are ready, Control pauses them unless you deselect the “Pause warmed-up desktops immediately” option in the Warmup Policy.

You are billed for the time between the start of the provisioning process and the time the desktops are fully paused. In addition, when a user signs in and acquires a desktop, you are billed for the time they spend signed in.

Non-persistent desktops do not sleep or shut down when there is an active user session, even if the user is disconnected, so the entire session time is billed.

Time Limits Policies

For user sessions, costs are controlled by setting both the "Idle Disconnect," "Sign Out After Disconnect,” and “Maximum Session Length” values in a Time Limits Policy:

• Idle users will be first disconnected when the Idle Disconnect timer expires and then signed out when the Sign Out After Disconnect timer expires.
• They will also be disconnected and signed out if the Maximum Session Length Timer expires.
• Once the user is signed out, billing stops.
• Billing also stops when the user signs out manually or the desktop is shut down by Control.

Warmup Policy Page

Mandatory Parameters

To add a new policy, to go “Policies > Add a New Policy” in Workspot Control and specify “Warmup” as the Policy Type. To edit an existing policy, go to “Policies > policyname.”

Warmup policies require a name and a time zone (which defaults to Control’s time zone).

Optional Parameters

Optional parameters are the non-persistent desktop pool that the policy controls (which you can specify later) and a Comments field.

The Warmup Schedule

The warmup schedule is shown in a matrix with the day of the week on one axis the time of day on the other, creating an array of 30-minute time slots. Each time slot specifies the number of warmed-up desktops to be ready at the start of the period. This number includes the already-active users, so if you specify 50 desktops and the period starts with 10 users already signed in, 40 desktops are warmed up. The default is zero and the maximum is the size of the associated desktop pool.

Note: Different pools have different recommended rates of ramp-up and ramp-down. See the note on the “Add/Edit Warmup Policies” page for current recommendations.

Set each time slot to the minimum number of desktops you want ready for users during that period. You can select ranges of cells, copy them (such as with Ctrl-C), and paste them into another range of cells (such as with Ctrl-V). If the target range is larger than the source range, values are repeated to fill the whole target range.

Pause Warmed-Up Desktops or Keep Them Running

Below the schedule is a checkbox, “Pause warmed-up desktops immediately” (enabled by default). This saves money but increases the end-user sign-in time. Deselect this checkbox if you want the warmed-up desktops to run until the end of the time period. In this case “Pause” includes “Shutdown” if your Cloud Provider and template don’t support Sleep.

You can also copy or delete a Warmup policy using the controls at the bottom of the screen.

Notes and Best Practices

• To minimize costs, leave the entries at zero for periods where you don’t expect anyone to sign in, and let users know that signing in during such period will take longer.
• This feature is at its most valuable at the start of a shift. Once everyone is signed in, the values make little difference unless users sign out and back in again.
• The Warmup policy doesn’t track the size of the desktop pool. If you increase the size of the pool, the policy's entries don’t increase. If you decrease the size of the pool below the largest entry, you have to manually edit all entries that are larger than the new pool size before you can save the downsized pool.
• If any desktops are in the Failed or Error states, they are inactive by definition. On warmup, such desktops are deleted, reimaged, and powered up. On shutdown, such desktops are deleted. Thus, their problems are self-correcting.