The Purpose of This Post

Sometimes a small change adds great value or alleviates a pain point. This post today is about one of those small changes. With XenDesktop 7.6 a new setting called “Simultaneous Personal vDisk Inventory Updates (Absolute)” has been added to the Hypervisor Connection screen. But in order to appreciate the present, it is important to understand the past and the pitfalls it presented. So we go back to XenDesktop 7.5 , touch base on some requisite background and understand the problem first.

The Essentials

Image Update

Since this post is primarily about PvD, it is important to understand what Image Update means in the context of PvD.

In brief, Image Update or catalog update is the process of upgrading all desktops within a machine catalog to a single updated master image. This is also referred to as the “Preparing” state in Studio. It involves two steps

  • Updating the master image
  • Upgrading the XenDesktop Catalog

For PvD, this also implies re-computing the impacted data on PvD for it to be able to work with the new base image. Additionally, this process also involves rebooting the machines undergoing update. For detailed information on image update and steps to perform please follow this link.

Hypervisor Throttling: What and Why

In XenDesktop, Hypervisor Throttling is a mechanism through which the number of simultaneous actions of a certain type are limited by configuration settings. These include actions like power actions and PvD Preparing state.

Fig 1: XD 7.5 - Edit Connection Settings

Fig 1 is  the “Edit Connection” window from XenDesktop 7.5.  Details on how to reach this screen can be found here under the “To edit a connection” section. The configuration fields in the image show how XenDesktop controls important parameters like concurrent power actions on a hypervisor. These limits are required because the hardware infrastructure is capable of handling only a finite number of such actions at a time.

Before getting to the crux of this post, it is important to understand the settings that this window presents. Below is a brief description of each of them:

It is important to note that these settings apply to the collection of all machines for a given hypervisor connection.

  1. Maximum active actions : This is the maximum number of power actions that can run at any one point of time.
  2. Maximum new actions per minute : This number of new actions that can be started every minute.
  3. Maximum power actions as percentage of desktops : The percentage of total VMs configured for the hypervisor connection that can go through concurrent power actions.  The effect is essentially same as ‘Maximum active actions’, just that the value is expressed in percentage rather than the absolute number.
  4. Maximum Personal vDisk power actions as percentage : A bit of a misnomer, this setting actually controls the number of PvD machines that can  concurrently be in the Preparing state at any point of time. The name though suggests that it applies to the power actions for the PvD machines.

Also note that whenever the same setting is controlled by two fields, one denoting the absolute number and the other denoting the percentage, the value that resolves to lower number of machines is the one that takes effect.

Let’s put our focus on number 4 above. “Maximum Personal vDisk power actions as percentage”. The preparing state for a PvD machine (also referred to as Image Update) is a storage IOPS intensive operation and is dependent on the storage/ hardware infrastructure.

Back to the main point…

By now, we have learnt three important things:

  1. The settings on the screen apply to all the machines on the hypervisor connection.
  2. Image update is an intensive operation that is directly dependent on the storage and hardware infrastructure.
  3. The number of PvD machines undergoing image update at any one point in time is controlled by a number that is a percentage of the total number of machines on the  hypervisor connection.

The thing about percentages – they resolve to bigger numbers as the whole grows. The ‘whole’ here is the number of machines governed by the hypervisor connection.

So what all of this essentially boils down to is the fact that the setting “Maximum Personal vDisk power actions as percentage” that we discussed earlier implies that for a given percentage number, if the number of machines under the hypervisor connection increase, the number of machines that will concurrently be in the preparing state for the same hardware is now higher.

Which means that the same hardware will now have to support more simultaneous image update operations compared to before. There is an obvious problem here. The number of machines undergoing image update  at one point of time have increased where as the underlying supporting hardware stands unchanged.

So how do we solve this problem? One way to do that is to have an absolute number and not the percentage. While we already do have percentage and an absolute number for “Maximum Power Actions” , the absolute the number is missing for the PvD preparing state.

Enter XenDesktop 7.6…

Considering the problem we discussed above, we set out to improve things with XenDesktop 7.6.

Fig 2 is a screen shot of the same settings screen in the new XenDesktop version.

Fig 2: XD 7.6 - Edit Connection Settings

As can be seen, the screen is more informative, explains how the absolute and percentage values work in conjunction with each other. Also we have an absolute value setting for “Simultaneous Personal vDisk inventory updates” along with the percentage value and the name of the setting makes more sense. The value which resolves to the lower number of machines takes effect.

Thus now, the administrator has the option of specifying an absolute number of PvD machines for the hardware infrastructure and that value would not change if a new machines come under the hypervisor connection. The administrator can set the percentage value to a high value if he wants the number of concurrent machines in the Preparing state to be unaffected by the total number of machines under the hypervisor connection. This would cause the absolute value to kick in, since that is the lower value.

Alternately, if the administrator is happy with the settings that they had set in XenDesktop 7.5 (assuming that it was upgraded to XenDesktop 7.6), they can continue using the percentage and set the absolute value to a much higher number so that the percentage takes effect.

I hope this helps administrators understand the intricacies of this setting. Keep an eye out for a future post about how to choose the optimum value for this setting.