Provisioning XenDesktop on Azure Just Got a Lot Faster

May 8, 2020, update: Learn how to improve Azure performance with Machine Creation Services.

Support for Azure Resource Manager in XenApp & XenDesktop continues to improve and now features on demand provisioning of virtual machines, reduced storage costs and significantly faster machine catalog creation and power operations.

Summary of Improvements

1. Faster machine catalog provisioning
2. Significantly faster power operations
3. More responsive power state reports in Citrix Studio
4. Reduced storage cost for pooled machines
5. Better performance when deleting catalogs

On Demand Provisioning

Previously, provisioning in Azure followed the traditional XenDesktop model where VDA machines are created as part of creating a catalog. From this point onward, machines are assumed to “exist” and can therefore be started and stopped. This is indeed possible in Azure, but a closer look reveals that it is not a natural fit with the Azure cloud paradigm.

The first clue is seen when creating an Azure machine. After creating the machine, the machine is running and there is no other option as Azure assumes that the machine was created because it was needed for some immediate purpose. However, the convention for XenDesktop catalogs is that machines are initially stopped so after creating each machine in the catalog, we stop it which is time consuming and, as we shall see, unnecessary.

The second clue is seen when inspecting the stopped machines in the Azure Portal. The power state is reported as “Stopped (deallocated)”. There is no Azure compute charge for machines in this state so it stands to reason that the machines do not exist. When we stopped the machine immediately after Azure had allocated it, Azure deallocated the machine to avoid compute charges to the subscription. The reflection of the machine in the Azure Portal is really more of a record of how the machine is configured in terms of disks, network interfaces etc.

The third clue is seen when starting a “Stopped (Deallocated)” VDA where the power state in the Azure Portal will briefly show “Creating”. What happens when the VDA is started is not much different from what happens when the VDA is initially created.

This means that that the time it takes to start an existing machine is comparable to creating a new machine. Armed with this information, it can be seen that it makes little sense to create machines when a catalog is created because they are effectively deleted immediately without being used. Furthermore, it means that instead of just stopping machines when they are not needed, they can be deleted. In subsequent sections, we will explore how this translates into improved power operations performance and reduced storage costs.

Philosophically, one of the ideas behind the cloud is that resources scale up and down depending on demand and we have taken the first step towards a more dynamic cloud idiomatic view of resources.

Resetting the Operating System (OS) Disk

Before we look at the mechanics of starting machines, we need to review the difference between pooled and dedicated XenDesktop machines. Pooled machines are always reset so they start with an OS disk that is an exact copy of the master image while dedicated machines start with the same disk and disk content they had when they were last used.

Resetting the OS disk is accomplished by recreating the machine with a new disk. In other words, the existing machine and the old OS disk is deleted and the machine is then recreated with a fresh copy of the master image. Previously,the traditional XenDesktop workflow requested the OS disk reset immediately prior to starting the machine. This is no longer the case so we can move the cost of deleting the machine to the point in time where the machine is no longer needed. When the machine is needed it can simply be created with the correct disk.
Some of the advantages of this approach are:

1. Machines start quicker because there is no existing machine that has to be deleted.
2. No confusing power state transitions can be observed while the machine is being deleted and recreated.
3. Machines cannot be started from the Azure Portal. Previously, it was not obvious that pooled machines would start with a dirty disk if started from the Azure Portal. Now, a machine is not visible in the Azure Portal unless it is running and it can therefore not be accidentally started with the wrong OS disk.

Performance Benchmark

Many factors like location and time of day influence performance. Performance characterics may chance at any time, but the following table is typical of the performance gains in the latest version of XenDesktop in Citrix Cloud:

Storage Savings for Pooled Machines

Since we know that the OS disk for a pooled machine will not be reused when the machine is started after being shut down, there is no need to keep it in storage and incur storage charges for data that is no longer needed. Previously, the OS disk could not be deleted when the machine was not being used because the machine itself was not deleted and it is not possible to detach the OS disk. On demand provisioning now allows OS disks to be deleted when not in use because the machine is deleted. This can result in significant cost savings for customers that routinely shut down machines, e.g., outside working hours.

Viewing Machine Power States and Azure Resources

Because the new on demand provisioning model is superimposed on the existing XenDesktop product, there are some differences to be aware off:

1. When a machine is shown as being “Off” in Citrix Studio, the machine does not exist in Azure, i.e., it will not show up in the Azure Portal when viewing the virtual machines in the subscription. The network interface and identity disk will always be there.
2. If the machine is a pooled machine, the operating system disk only exists when the machine exists.
3. If the machine is a dedicated machine, the operating system disk is created the first time the machine is powered on and remains in storage until the machine is deleted.
4. Whenever a machine is running, it is visible in the Azure Portal.
5. Machines in legacy catalogs and machines in existing manual catalogs are not provisioned on demand and will be visible in the Azure Portal even when not running. It is possible that we will automatically convert machines in legacy catalogs to on demand provisioned machines at a later date.

Managing Azure Core Quota

Resources in Azure are subject to subscription quotas and the network interface and core quotas are particularly illustrative. Before starting a lengthy provisioning process, we verify that the subscription has sufficient network interfaces and compute cores available. Other quotas and conditions are verified, but we will ignore those for the purpose of this discussion.

Let’s assume we are creating a catalog with N machines or adding N machines to an existing catalog. Before provisioning the N new machines, XenDesktop makes sure that the subscription has capacity for N additional network interfaces and N times “number of cores per machine” cores. While the network interfaces are allocated as part of the provisioning process, the cores are not since the machines are created on demand when needed.

While some or all of the machines are powered off, cores can be used for some unrelated purpose and there may therefore be an insufficient number of cores available when the provisioned machines are started. Generally, this does not happen provided there is a reasonable relationship between core quota and network interface quota, but it is the users responsibility to assure that sufficient cores are available when starting machines.

Limitations

1. Leaving machines behind when deleting catalogs is not currently supported.
2. Personal vDisks are not supported.