Monday, March 7, 2011

XenDesktop 5 Deep Dive: Machine Creation Services on vSphere 4.1

By: Andy Paul

When XenDesktop Desktop Studio is configured, a hosting infrastructure and storage system is defined. This hosting infrastructure can be Citrix XenSerspver, VMWare ESX/vSphere, or Microsoft Hyper-V. Storage for use by XenDesktop is also defined, which can be local storage or shared storage. In a production vSphere environment, shared storage defined as VMWare Datastores is preferred.

When using Machine Creation Services (MCS) in XenDesktop 5 Desktop Studio, a Master Image is identified when a Catalog is created. MCS Catalogs can be designed for Dedicated or Pooled virtual desktops. Pooled Assignments can be set for static assignment or random access.

Dedicated Catalog virtual desktops retain all changes, including software installations and local data, in a local difference disk. Pooled Catalog virtual desktops do not retain changes, the difference disk is reset upon reboot, leaving only a copy of the master image. However, when using pooled desktops, the base image can be updated allowing changes from the master disk to be replicated to the deployed VMs, providing for centralized patch and application management. Each deployed image, whether pooled or dedicated, will also contain an identity disk; all deployments utilize thin provisioning.

The following chart highlights the benefits of each type of XenDesktop Catalog:

Graphic taken from CTX127587: XenDesktop 5 - Reference Architecture

During this test implementation, two Dedicated Catalogs are used to pilot XenDesktop 5. One catalog will be based on Windows XP, the other catalog will be based on Windows 7. These catalogs and the dedicated machines will be assigned to Desktop Groups for different business units.

Master Image Utilization
Once a master image is identified as part of the Catalog creation, a private-use clone of the VMDK is created for use by the catalog machines. This cloned disk is separate from the Master Image VM, allowing that VM to be updated or deleted with no impact on the MCS deployed virtual desktops.

This master image clone is copied to each Datastore defined during XenDesktop site setup. This site definition can be modified to include additional storage as it becomes available. If five datastores are defined the clone will be created on the first Datastore and then copied to the remaining four.

Each catalog is linked to its own master image clone. If multiple catalogs are defined, then multiple master clones will be generated. Any additional machines created within a catalog will use the defined master image. A master image can be changed to a different disk using the following command in PowerShell: Publish-ProvMasterVmImage (click here for an example of using this command if necessary.) This change would only impact new machines created in the catalog, not existing machines already generated.

Impact on Storage
Since MCS uses thin-provisioning, using Pooled or Dedicated desktops should require less storage than existing VM creations. On vSphere, the MCS service creates a snapshot for each VM called “Do Not Delete – Critical.” This snapshot is a reversion point back to initial deployment. For Dedicated desktops, additional snapshots can be created using vCenter’s Snapshot Manager functionality.

The master image, stored on each Datastore, becomes a private-use read-only VMDK for each MCS created VM. Depending on the NAS/SAN functionality, this image may be deduplicated or moved to high-utilization storage due to the increased read ratios.

For Pooled machines, the snapshot growth will be limited since it is reset at each reboot. Dedicated machine snapshots will grow over time as changes to the virtual desktop occur. It is recommended to incorporate profile management and data redirection where possible in either scenario to increase user flexibility and reduce data changes inside the images.

Determining Storage Requirements
Since MCS uses thin-provisioning, only the amount of space required is actually used, allowing for a potential of over-allocation of storage. When analyzing storage utilization, the key item to examine is the snapshot space utilized by each VM. Since the master image is shared, this is a “fixed” cost, where snapshot growth will be dynamic.

Please note, a snapshot can grow as large as the base disk, so if the master image is 40 GB in size, the associated snapshot for a dedicated machine can grow up to 40 GB in size; effectively doubling storage requirements if left unmanaged.

To see snapshot space utilized in vCenter, select the Datastore in question, select the Storage Views tab. This view will show the space used for each virtual machine as well as snapshot space used. For MCS created machines, the space used is misleading, since it is also counting the base image size. In the example below, the master image is 40 GB in size. For VXPXDTest002 (highlighted), the Space Used is 46.11 GB, but the actual space used is really 6.11 GB since 40 GB is for the shared master image. Of the 6.11 GB used, 4.09 GB is snapshot space.
To see more exact detail, you can browse the Datastore, examining the folder for VXPXDTest002, as shown below. Notice the total space used which is the active snapshot plus the memory swap file. The base image is stored in its own folder:

Sizing Wizard
Along with this analysis, I have created an Excel worksheet called
MCS Sizing Wizard. This worksheet will help determine the size required for MCS deployed dedicated machines. The basic formulas are:
    Determine size requirements for master image:
    ..... [VMDK Size] * [# of Datastores]
    Determine size requirements for deployed virtual machines:
    ..... Create estimates for low, medium, and high usage snapshots
    ..... Per machine: [identity disk] + [RAM swap file] + [estimated size of snapshot]
    ..... Total VM sizing: [# of VMs] * [Per Machine Estimates]
    Determine total storage requirements
    ..... Most likely storage: [Expected VM storage] + [Master image storage]
Using the worksheet, creating 120 Windows 7 dedicated machines, spread across 5 datastores, with a 40 GB master VMDK, 4 GB RAM and an average snapshot size of 15 GB would use 2.4 TB of storage out of a maximum provision of 5.4 TB of storage. If using standard (existing) VMs, the same number of machines would use approximately 5.1 TB of space, for a net savings of 2.8 TB of utilized SAN storage. Using the worksheet, creating 120 Windows 7 dedicated machines, spread across 5 datastores, with a 40 GB master VMDK, 4 GB RAM and an average snapshot size of 15 GB would use 2.4 TB of storage out of a maximum provision of 5.4 TB of storage. If using standard (existing) VMs, the same number of machines would use approximately 5.1 TB of space, for a net savings of 2.8 TB of utilized SAN storage.

About this Article
The purpose of this article is to summarize the underlying architecture and impact of using Machine Creation Services in a pilot environment. This article is not intended to replace the XenDesktop Admin Guide or the XenDesktop PoC Implementation Guide.

The scope of this article is to help understand and manage the virtual machines created by MCS as well as understanding the storage requirements when using MCS. The actual amount of storage will grow over time as the snapshots grow and should be managed appropriately. Any sizing numbers are for illustrative purposes only and are no way intended as definitive calculations.

To help with the additional planning, design and optimization areas, it is recommended to utilize the XenDesktop Design Handbook Success Kit.

Additional References
XenDesktop 5 hosted-virtual desktop architecture series
XenDesktop 5 scalability: Site Capacity
PVS or MCS: We Are Talking About IOPS Again
PVS or MCS: Operations Is Important
Provisioning Services or Machine Creation Services: Big Picture Matters
XenDesktop 5 Virtual Machine Creation Services on vSphere 4.1
blog comments powered by Disqus
Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.