Power Management on Horizon Cloud Service – next-gen

Introduction

This guide describes several of the features and components of Horizon Cloud Service – next-gen that help you right-size your environment by managing the power states of your deployed workloads. Options include power-based, load-based, and schedule-based power management policies and configurations that control how virtual machines behave when their associated desktops are not in use. Managing your workloads efficiently can reduce the amount of spend on Infrastructure-as-a-Service (IaaS) components on Microsoft Azure.

Audience

This guide is written for data center administrators and IT personnel who want to optimize the costs of running a Virtual Desktop and Application solution on by minimizing the amount of time that the resources are being consumed. This guide can help you work with Horizon Cloud Service – next-gen, and it provides a reference as you become more proficient.

Horizon Cloud Service – next-gen

Horizon Cloud provides virtual desktops and hosted apps as a cloud service and deploys and manages them in the cloud by using IaaS components from the Microsoft Azure platform. It enables users to securely access their desktops and apps from any device or browser. 

For more information on Horizon Cloud Service – next-gen see What is Horizon Cloud Service - next-gen? on Tech Zone.

Benefits of Power Management with Horizon Cloud Service – next-gen

Power management configurations control how a virtual machine behaves when the associated desktop or server is not in use. A desktop is considered not in use both before a user logs in, and after a user disconnects or logs off. A multi-session VM is considered not in use when the last user session is ended from that host. Power policies also control how a virtual machine behaves after administrative tasks are completed, such as refresh, recompose, farm expansion, and farm refresh.

Horizon Cloud Service – next-gen has several methods for controlling the IaaS costs of your Horizon Cloud Service – next-gen environment. Most of these methods are included in the sizing components of the Pool Group configurations or RDSH/Windows 10 multi-session farm configurations. By using these sizing components, you can implement a cost-effective deployment of Horizon Cloud Service – next-gen, while at the same time ensure that resources are available to your users when they need them.

Note that many of the configuration items that are described in this asset are applicable to all Pool and Pool Group configurations. As a result, the explanation of how configuration items affect the Pools and Pool Groups has been consolidated and referred to directly in this asset. Make sure that you review UI flows directly or in the product documentation to help avoid confusion.

Choosing the Right Power Management Policy Settings

The primary reason for using power management policies is to reduce the amount of infrastructure resources necessary to support users, while still providing enough powered-on and available resources for users when they need them. Leveraging the power management policies effectively will help you adhere to a lower cost on infrastructure spending.

Figure 1: Powered on time for 30 desktops with Scheduled (Purple) vs. Load-Based Power Management (blue, and actual user demand in green)

Figure 1 demonstrates the differences between leveraging a schedule-based power management policy and a load-based power management policy. While the schedule-based power management policy helps reduce costs by only powering on resources during scheduled times, it does not account for variances in actual user load, as a load-based power management policy would.

It is important to match the correct policy configuration to the correct user assignments. There are several key user metrics that you should keep in mind as you read through this document:

• Size of User Group / Assignment – Configuring the assignment as close to the number of users in the given groups as possible. This applies to all power management policies.
• Service Level – Aggressive power management policies can mean that less resources are available for use immediately upon request from users. Users may need to wait longer for resources to boot and become ready for their use.
• Peak Times – Knowing the times when you need to have the maximum or minimum amount of resources available on-demand. Peak Times may change based on seasonality or projects. Knowing these will help you decide when to use load-based policies.
• Work schedules – Understanding the typical workday hours of the users in any given group, and if there are night, weekend, or holiday-specific items that might impact a schedule-based policy.
• Selecting the correct Pool Group type for each user group – It’s always best to match a user group to the type of remote desktop or application delivery method. Consider, as you read below, that some power management and scalability configurations apply differently to each assignment type.
• Variability – Some user groups will have some variability in work schedules and locality. With a larger percentage of remote users, you may need to leverage a combination of load-based and schedule-based power management policies to accommodate.

All of these variables should weigh in on choosing which power management policy will apply to each user group.

Power Management for Horizon Cloud Service – next-gen resources

Power Management features allow you to automatically provision or deprovision (power off and deallocate) virtual machines running on Microsoft Azure. Each assignment type has different power management capabilities available to it. You can configure these capabilities in the Pool and Pool Group creation workflows. You can use these features in different combinations to maintain a tight control on your IaaS spend in Microsoft Azure.

Power Management for Horizon Cloud Service demo

This demo gives you a brief introduction to the power management features available for Horizon Cloud Service. You will learn about the UI and how the functionality works to save on your infrastructure spend.  After this click-through demo, we will explain the features in detail.

Configuring Virtual Machine Pools

A Pool is a collection of virtual machines that are created for end-user capacity. You can create pools of different virtual machine configuration types to accommodate the different needs of each user group that you have. Finding the most cost-effective virtual machine size for each use case is critical in having an efficient Horizon Cloud environment.

Virtual Machine Pool Types

Efficient VDI platforms match individual use cases to appropriate types of resources. To start, you should interview key stakeholders for each user group to match an appropriate virtual machine configuration for each individual group.

There are three different kinds of virtual machine pools that you can create:

• Dedicated single-session is used for a persistent VDI desktop experience where each desktop is mapped to a single user.
• Floating single-session is for the non-persistent VDI desktop experience where multiple users can use the desktop at different times and the desktop resets after each user session. User persona can be managed separately with Dynamic Environment Manager to give end-users a persistent experience with non-persistent desktops.
• Multi-Session for session-based published desktops and applications.

One of the simplest methods to manage infrastructure costs is to leverage an appropriate virtual machine type from the infrastructure provider. Platform providers typically provide a menu of virtual machine hardware configurations, and charge based on their configurations and resource consumption. Horizon Cloud Service – next-gen allows you to choose which VM types and sizes are available for use in Pools.

Configuring Pool Provisioning

In the workflow to create a pool, you can configure a maximum number of virtual machines available for that pool. Setting these values appropriately for your user groups will help you limit resource consumption.

Figure 2: Pool Creation Configuration UI

For each Pool, you can also select the provisioning method. You have two choices:

• Provision All at once – This option will provision all of the virtual machines in the pool, up to the maximum number of virtual machines in that pool upon creation of the pool. 
• Provision On demand – This option will allow you to control how many virtual machines are initially created for the pool. You can configure the Minimum spare VMs and the Maximum spare VMs values number of spare virtual machines that will be created when the pool is initiated. Only the minimum number of desktop instances is initially powered on. As end-user demand increases, the system provisions additional desktops, up to the Maximum VMs value. As end-user demand shrinks, the system powers off and deallocates the desktops until it matches the Min Desktops number. A desktop must be free of a logged-in user session before the system will power it off. This allows you to control the number of resources that are always available for users in each pool, and thereby manage costs of pre-created infrastructure.

Power Management for Single-Session Pool Groups

Pool groups allow you to entitle desktops and applications to any users or groups at any time. You can create a single-session pool or a multi-session pool.

Power Management for Dedicated Pool Groups

There are some configuration items that are available to Dedicated Pool Groups.

• Unused VMs - The minimum number of VMs to be kept powered on relative to the total VMs in a pool group at any point in time. An Unused VM is a VM that is configured and powered on and ready to be assigned to a user. This setting applies for each Pool Group that is specified to use this Pool.
• Power Off Protect Time – The number of minutes that a VM is protected from powering off due to a headroom error. See Power Off Protect Time below.

If you set any schedule here on a Dedicated Assignment, all assigned or claimed desktops will be powered on during the schedule period. This is to make sure that all Dedicated desktops are ready to use for mapped-to users use during the specified period. As a result, if all desktops in a Dedicated Assignment are assigned/claimed, all desktops will be powered on, even if the schedule is set to power on zero (0) desktops since that value only applies to unassigned/unclaimed virtual desktops.

Note: When you configure a schedule for Dedicated Pool Groups, by default, the system keeps all of the assigned/claimed desktop VMs powered on, regardless of the schedule.

Power Management for Floating Pool Groups

You have more Power Management choices in managing floating pool groups since floating pools are refreshed and made ready for a new user after a user logoff. There are other configuration items that are available for floating pools. 

There are two methods for classifying how pools calculate power management policies. You can find these configuration items in the Power Management section of a Pool Group creation workflow.

When the usage increases above an upper threshold the system automatically powers up a new desktop instance. When the usage shrinks below a lower threshold, the system shuts down and deallocates desktop VMs as end users log off from the desktops.

Occupancy Based - If you configure a threshold for a floating pool to calculate power management configuration for a new virtual machine to be provisioned or drained. 

• Select Optimize for Performance when you want the system to power on the next desktop instance sooner rather than later. Even though you are spending more by having the next desktop ready to go before the user demand requires it, this setting increases the chance that when users try to launch a desktop from the assignment, the desktop is already powered up to meet that demand.

The threshold values used for assignments or farms configured with Optimized for Performance are as follows:

• Low threshold: 23%
• High threshold: 50%
• Select Optimize for Cost when you want the system to wait, if possible, before powering on the next desktop instance. The occupancy of the assignment's set of desktops is higher before the system powers up the next desktop instance. Even though this selection minimizes capacity costs by having more utilization of the existing desktops, this setting increases the chance that there might be a delay when new users try to log in, because they might have to wait for the time it takes to power on desktops.

The threshold values used for assignments or farms configured with Optimized for Power is as follows:

• Low threshold: 38%
• High threshold: 80%
• The Balanced selection allows you to strike a balance between capacity costs and timely access to available user workspace constructs.

The threshold used for assignments of farms configurated with Balanced is as follows:

• Low threshold: 31%
• High threshold: 66%

Non-Occupancy Based is a simple value of the minimum number of virtual machines that are to be kept powered on at any given time relative to the maximum number of virtual machines in the Pool. This setting applies to each Pool assigned to the Pool Group unless there is a power management schedule specified.

Remember, desktops take a while to power up and boot before becoming available for a user to log in. Depending on the size of the VM used, or the number of boot-up agents or applications that are set to start on startup, it may take more time for the VM to be ready and available for a login. Reducing the system boot time can save on infrastructure costs.

Figure 3: Pool Group creation UI

Power Management for Multi-Session Virtual Machines and Application Hosts

Hosted desktop and application hosts service multiple users as opposed to single-user virtual desktop assignments. Microsoft has multiple operating system versions to service these types of workloads, including Windows Server and Windows 10 Multi-Session.

There are some differences in how you can manage the size and configuration of your multi-session virtual machines, including load balancing features which help determine how you distribute users to multi-session VMs, in addition to increasing or decreasing the number of virtual machines in a multi-session Pool Group.

Configuring Multi-Session Virtual Machine Pools

Pools of multi-session virtual machines are configured in the same UI as Single-Session virtual machines, and the configuration options are very similar. The major difference is that capacity growth and shrinkage depend on the number of users on each virtual machine contained in a shared-session virtual machine pool. 

Only the minimum number of VMs are initially powered on. As end-user demand increases, the system powers on additional VMs, up to the Max VMs number, according to the Pool properties and Pool Group Load Management properties. As end-user demand shrinks, and all users log out of multi-session virtual machines, the system powers off the VMs, until it reaches the Min VMs number of VMs. A VM must be completely empty of user sessions before the system powers it off.

When you specify zero (0) for Min VMs, it indicates that you want the system to power off all the farm's RDSH VMs when there is no end-user demand for sessions to the farm.

Power Management for Multi-Session VM Pool Groups

Load-based power management works similarly for farms as it does for Floating Single-Session Pool Groups. See Power Management for Floating Pool Groups for details, or Create a Multi-Session Pool Group in the product documentation.

Remember that users are distributed onto hosts within farms for session-based desktops or applications. If you change the load-balancing options in each Pool Group configuration, it can decrease the amount of time until a new host in a farm is available for additional user demand while the pool is rebuilding.

You can leverage the Load Balancing configuration items in the Pool Group configuration UI to modify how users are distributed to multi-session virtual machines in the available pool. These settings can affect Power Management as well, as it will change how users are directed to any given multi-session VM.

Load Balancing Options for Multi-Session Pool Groups

You can see more details about Load Balancing Options in Create a Multi-Session Pool Group in the product documentation. These options help you to ensure that your end-users can get the resources that they require in a multi-session virtual machine. 

For example, you can modify the “Time between consecutive session allocation” value in a Multi-Session Pool Group to control how many users you add to a single virtual machine within a given time window. If you are using load-based power management, and want to save on infrastructure costs, you might want a lower value for this field to get more users onto existing hosts faster, even though it may have a negative performance impact on the virtual machine from an end-user point of view.

Other values such as CPU Usage, Memory Usage, and Disk queue length are all available for you to modify.  The details of each configuration item are in the product documentation. You can modify these configuration items to add more users aggressively or more slowly as other users drain off from shared session VMs over time.

For more information about implementing a Power Management policy with pools of multi-session machines, see Create a Multi-Session Pool Group.

Schedule-Based Power Management Policies

In addition to load-based power management policies, Horizon Cloud Service - next-gen also supports scheduled power management. You can define specific schedules for each assignment in each pod to grow or shrink a given assignment or farm based on set-times. Power management schedules take precedence over automated power management features applied as part of a user assignment or an RDSH farm in a Horizon Cloud Service – next-gen deployment.

You can define multiple power management schedules per Pool Group, regardless of Pool Group type. For example, you may want to define one power management schedule for standard workdays (such as 9AM to 5PM on Monday through Friday), and another power management schedule for weekends (such as 10AM to 3PM on Saturday and Sunday).

Figure 4: Scheduling Power Management

You can have up to 10 schedules for VDI desktop assignments (floating or dedicated). If schedules overlap and have different minimum VM values, the system uses the largest value of minimum number of desktops for the overlapping time period.

Using these options helps you to save money on your IaaS spend in Microsoft Azure. For more information about implementing a Power Management policy with Floating assignments, see Creating a Single-Session Gool Group.

Session Time Out Management

There are several settings that allow you to act on user resources that are not being actively used. Proper configuration of these settings may vary depending on how the users use the resources.

Timeout Handling items allow you to determine behavior when a user is not using their resource. The Logoff disconnected sessions configuration automatically logs off the user from a VM with a disconnected session. At the most basic, you can decide to log users out immediately, after a given time period, or never. These settings and the time out values that you assign for these configurations will have a direct effect on the timing of when Horizon will be able to power off a given resource. The sooner that inactive users can be drained of resources, the greater the savings in infrastructure costs.

Configuring this setting for Floating Pool Groups can be very effective in reducing infrastructure costs, as it is assumed that the desktop environment has been configured with a non-persistent use case in mind. 

Configuring this setting appropriately for Dedicated or Shared Session Pool Groups can also be useful. Claimed machines can be powered off after a defined amount of time after the user logs off the VM. It can save infrastructure costs and allow for more timely maintenance and updating of the Virtual Machine Pools.  However, misconfiguration can cause your users to lose work if they are disconnected from their desktops unexpectedly due to user endpoint issues or faulty networking. Consider the needs of the business against the individual users to come to a proper configuration.

Power Off Protect Time

This Power Off Protect Time is used primarily for the situations where the system will automatically power off a desktop VM because it is calculated to be unnecessary based on the current load – also called a “headroom error”. This setting specifies the number of minutes that you want the system to wait before automatically powering off a powered-on desktop. You can enter a value from 1 to 60. The default is 30 minutes. A lower number powers desktops off more quickly and reduces Microsoft Azure IaaS costs.

In some situations where user requests for virtual machines have a higher variance state over short periods of time (shift changes), the service may begin to reduce the amount of availability within the pool, only to have a few users request more resources during a subsequent census cycle. Power Off Protect time will introduce some delay in deprovisioning resources due to variability in the acute user demand. 

Use the Power Off Protect Time value to specify the amount of time you want the system to wait after determining the remaining powered-on VM has no user sessions before the system powers off that VM.

Using Encrypted Disks with Virtual Machines

Encrypted VMs take longer to power on than non-encrypted VMs. If you have set Encrypt Disks to Yes, and you want 100% of the encrypted VMs to be ready for end-user connections at a particular time of day, you might have to set an earlier start time. For more information, see When Scheduling Power Management for Farms and VDI Desktop Assignments That Have Large Numbers of Encrypted VMs.

Examples

The following scenarios provide examples of what load-based and schedule-based power management policies might look like for floating assignments and session-based desktop farms.

Example 1: Load-Based Power Policy for Floating Assignments

In this scenario, a simple floating assignment is configured for a small group of users. The assignment is configured with the following details:

• Desktop Type: Floating
• Min Desktops: 3
• Max Desktops: 10
• Power Management Mode: Optimized Performance
• Scheduled Power Management: None

This example behaviors are as follows:

Figure 5: Load-Based Power Management Example with VDI Desktops

As outlined above, with the Optimized Performance setting, the system powers on the next desktop at a lower occupancy threshold. This configuration trades the cost of faster ramp-up to make sure that new desktops are ready to use before any user demand requires it.

Example 2: Schedule-Based Power Management Policy for Multi-Session-Based Desktop Pool Group

In this example, we use a Multi-Session Pool Group with a Pool of multi-session based virtual machines to demonstrate the results of a schedule-based power management configuration.

In this scenario, a multi-session pool group has been configured for a group of 160 users. They are scheduled to start work at 9AM and end at 5PM.

The assignment is configured with the following details:

• Default Settings
• Min 3 VMs in Farm
• Max 10 VMs in Farm
• Schedule
• 9:00AM to 6:00PM
• Min 8 VMs in Farm
• Max 10 VMs in Farm
• Logoff after disconnect = 30 min

This example behaviors are as follows:

Figure 6: Scheduled Power Management Example with Session-Based Desktop Farm

As you can see, from 8:00 AM until 9:00 AM, you have users logging in. Based on the basic settings of the Farm, the minimum three hosts are running to service those users. In this case, as the hosts fill up, you see that although only two hosts are in use, three are powered on and available for use.

The bulk of the users are logging in between 9:00 AM and 10:00 AM and staying logged in for work until 5:30 PM.

Users start to drain off the system at 5:00 PM. For those who forget to logoff, the setting to automatically log off users who are disconnected for 30 minutes forces them to logoff. This results in the farm being drained of all users before 6:00 PM. At that time, the Power Management feature stops and deallocates back to the 3 hosts required as a minimum in the default Farm settings.

Summary and Additional Resources

Using Power management configurations to control how a virtual machine behaves when its associated desktop or server is not in use can have significant efficiency benefits, including reduced infrastructure costs.

Additional Resources

Power Polices are also available in Horizon 8 running on vSphere. Details on this can be found in the Horizon 2006 product documentation:

• Setting Power Policies for Desktop Pools in the Horizon 2312 Product Documentation
• Creating and Managing Farms in the Horizon 2312 Product Documentation

 If you would like to try out Horizon Cloud Service – next-gen, see Evaluation Guide for Horizon Cloud Service next-gen.

For additional information about power management policies, explore the following resources in the Horizon Cloud Service – next-gen Product Documentation:

• Create a Pool
• Create a Single-Session Pool Group
• Create a Multi-Session Pool Group

For additional information on Microsoft Azure, see:

• Microsoft Azure Pricing Calculator
• States and billing status of Azure Virtual Machines

Changelog

The following updates were made to this guide.

Authors and Contributors

The following authors, contributors, and subject-matter-experts collaborated to create this guide.

Author

Rick Terlep is an End-User Computing (EUC) Staff Architect, EUC Technical Marketing, Broadcom.

Contributors

• Jerrid Cunniff is an End-User Computing (EUC) Product Line Manager, EUC Product Management, Broadcom
• Jim Yanik is a Director, EUC Technical Marketing, Broadcom
• Mukundan Sampath Kumar is a Senior Member of Technical Staff, Virtual Workspace R&D, Broadcom
• Griff James is Staff Engineer, Virtual Workspace R&D, Broadcom

Feedback

To comment on this paper, contact End-User-Computing Technical Marketing at euc_tech_content_feedback@vmware.com.