Power Policies for Desktop Pools

I recently finished reading VCDX Boot Camp: Preparing for the VCDX Panel Defense. This is second time I’m reading the book. It is great refresher and as Technical Architect (which is my current role) aids me a lot in gathering requirements and how to validate the requirements of clients by focusing discussion around it. It has helped me rewiring brain. Made me think in terms on AMPRS*. Good Read (5 stars). Angelo Luciani wrote a very blog on chrome extension. I came across Instapaper chrome extension and started using it. Very helpful. As result i bookmarked some great post. During week reading, I read a very good blog post on Risk Management. Please read it, if you are aspiring to be Architect. Risk management is so crucial in decision making and how frequently we miss it. Weekend reading, i came another interesting post on Assumption by Simon Long. I was surprised on what we do not Assumption in our design documents. I have seen it in every decision document. Assumption must be either validated or posted as a Risk if it cannot be validated.

Point is my blog would probably never post on “How to” anymore. It will be always “Why”. Question “Why” is important question to ask yourself and client. Hope I haven’t bored you with it. Lets talk about subject of this post.

I was looking at Power policies we configure while creating Desktop pool. I felt it is most ignored/not so discussed settings. When I went through, I felt it needs to be visited. Hope the post allows you make decision on why to select particular power policies. There are four policies from which you can choose from. These  policies controls what happens to the desktop when user logs off from the desktop


Following are the 4 policies you can choose from

  1. Take No Power Action
  2. Ensure Virtual Machines are always Powered On
  3. Suspend
  4. Power of

Below I have tabulated all four settings in details with description, behavior of policy and its impact


Power Policy

1.    Take No Power Action

Behavior of Policy

As policy aptly named “Take No Power Action”, View connection server (VCS) do not control the state of VM. When End user change the power state of VM, state remains unchanged with small exception. Exception is when user logs off from VM, VM state remains powered on. However when View administrator initiates recompose operation, VM will be powered off. So power state is changed. VM remains powered off even after recompose operation is completed. 

Case 01: If user is assigned a dedicated desktop. User logs off end of his day as he is going on vacation. Recompose operation occurs while he is on vacation, as result VM is powered off. Till he returns, VM remains powered off. He has to log a call to helpdesk to see why his VM is not reachable. Log in time + Application launch time (e.g. AV if it is agent based) is increased. Uptime is low and user experience is negatively impacted.

Case 02: If user shuts down his VM end of this day. VM is powered off. Next day he logs in, VM is powered on. Again Log in time + Application launch time (e.g. AV if it is agent based) is increased.

Use Cases:

  •         Those users who need shutdown privileges. (Shutdown privilege is never given to end user without good justification)
  •         Dedicated desktop users might need shutdown privileges.
  •         Where desktops uptime is little concern


·         If there are any agents which are pulling data from desktop e.g. system management will be impacted.

·         Administrator overhead and IT helpdesk might be overloaded with tickets post recompose operations to power on VMs

·         Impact can be reduced by keeping minimum of VMs powered on to half the size of pool

·         Suitable for dedicated desktop when the % of VM is less e.g. 10% of overall population. Out of 100, if 10 VMs need to powered on, it is a little operation effort. If count goes beyond 50, effort needs to be estimated.


2.    Ensure machines are always powered on

Behavior of Policy

VM always remains power on irrespective of user action. Post recompose operation, VMs are automatically powered on. E.g. If user shuts down the VM, VM is automatically restarted by vCenter. And during recompose operation, VM is automatically powered off and post recompose operation VM is automatically powered ON

Use case:

·         Highly effective for shift workers. In shifts, 24 x 7 desktops will be consumed.

·         If dedicated desktop count is high e.g. above 50 desktops


·         VM always remains powered on, there is no boot storm. Therefore reduced log in time as VM is always powered on.

·         For dedicated desktop pool Administrative effort is reduced. Administrator might spend time to identify and power on VMs

·         Shutdown privilege is ineffective. Shutdown privilege must not be given.

·         For linked clone pool, there is little need to keep spare VM powered on as VMs are always available

·         Potential Resource wastage if all VMs are powered on without being used.



3.    Suspend

Behavior of Policy

VM is suspended when user logs off

Use Cases:

·         Compute resource needs to saved i.e. power needs to be optimally utilize but login time must not be increased


·         IOPS needed to suspend and resume VM will be high. Additional IOPS requirements needs to be consider

·         Once suspend, file is created it remains in VM parent directly till VM is powered off. Extra storage needs to be calculated.


4.    Power off

Behavior of Policy

VM is powered off, when user logs off

Use Case:

·         Disk space is constrained. During power off operation, independent disk will return to pristine state.

·         Desktops are consumed only during 9-6 operations

·         Power must be optimally used


·         Boot storm + login storm every morning. Impact is directly proportional to number of concurrent desktops logins. Can be mitigate if user login time is staggered.

·         Post recompose operation, Administrator have to manually power on all VMs. Can be mitigate using powercli script. Efforts and skills would be needed to develop script

*AMPRS :- Availability, Manageability, Performance, Recoverability and Security