… or “The myths and tales of Image Management (part 3)”.

The intent of my previous blogs was to bust the myth of image management with Citrix XenDesktop being overly complex and “..too hard for most lean IT staffs to use..” according to VMware1. So far, I’ve focused on Provisioning Services (PVS) in part 1 and Machine Creation Services (MCS) in part 2 of the blog series.

This time I’d like to take a look at Composer, which is the “built-in” image management solution in VMware View and discuss how it compares to XenDesktop MCS.

From a general point of view MCS and Composer try to solve the same problem (simplifying time-consuming image management while minimizing disk space requirements) and provide a similar functionality (creation and maintenance of non-persistent desktops, plus a few specifics here and there). But although the idea behind both technologies is comparable, the capabilities and requirements are quite different.

Inner workings

Before we start comparing the two technologies, we should have a look at the inner workings of both of them. The diagram below outlines the two architectures:

 

 As you can see from an architectural point of view MCS and Composer are fairly similar. Main differences –besides the terminology – can be found down at the VM-specific disk level.

Machine Creation Services

For MCS-based VMs, all writes (e.g. pagefile, event log, local copy of user profile) are redirected to the Difference Disk. This disk can be either persistent (e.g. for dedicated static desktops) or non-persistent (e.g. for pooled desktops). XenDesktop will pick the right mode automatically, so an admin does not have to worry about it.

In most cases customers use pooled desktops, which will use a non-persistent Difference Disk that is wiped upon reboot of the VM. This ensures the virtual machines are reverted to a clean state on every reboot and without an administrative intervention. This simplifies the support of the environment, since all desktops have the exact same look and feel.

The Identity Disk on the other hand is always persistent. It is 16MB in size and just contains data related to the identity of the VM, such as computer name or Active Directory account password. This information is injected into the operating system during reboot, ensuring that each VM is unique.

The third disk for MCS based desktops is the Personal vDisk. This disk can store all user installed applications and modifications persistently. Even in case the Master Image is updated (e.g. when rolling out new hotfixes) the Personal vDisk will automatically be re-aligned and the data/apps/etc will remain available. This disk is optional.

Composer

On Composer-based VMs (aka linked-clones), all writes are redirected to the Delta Disk by default. When a virtual desktop is booted for the first time or after updating the Replica (Master Image) SysPrep or QuickPrep (similar to SysPrep but quicker / used by default) is started automatically, in order to personalize the VM. This procedure requires a number of reboots, which is a rather I/O intensive task.

After the personalization has been completed, View/Composer will create a snapshot of the Delta Disk, in order to be able to go back to a clean state (aka refresh) without running SysPrep or QuickPrep again. This step is required since Composer does not have the ability to inject the identity information during boot (unlike MCS).

In addition to the Difference Disk, each virtual desktop owns an Internal Disk, which stores configuration data for SysPrep / QuickPrep and some identity information such as the computer account password. This data is needed whenever a desktop is refreshed.

In order to minimize the growth rate of the Delta Disk, disposable files, such as the pagefile, can be redirected to the optional Disposable Disk. This disk is non-persistent and will be deleted upon reboot.

The Persistent Disk is also an optional disk available to aka linked-clones desktops. If enabled, the user profile and other data which needs to be persistent, can be redirected to this disk. Effectively the functionality of this disk is equal to a standard Windows Roaming Profile plus a home directory. So if anyone tries to tell you that Persistent Disks and Personal vDisks offer the same benefits, now you know the truth!

Now let’s focus on some of the major differentiators.

Infrastructure

Machine Creations Services (MCS) is integrated with XenDesktop. Each XenDesktop Controller runs all of the MCS specific services and can handle all MCS related tasks, which enable the XenDesktop Controllers to automatically load balance and failover in case of an outage.

In contrast Composer requires a separate installation. It can be installed on the vCenter server or –as recommended for large scale deployments- on a stand-alone machine. If installed separately, automatic failovers are not supported. In addition Composer requires a separate database. Unfortunately neither the database software is installed nor the database is created nor the ODBC connection is configured automatically during the Composer setup. Instead these steps have to be performed manually, making Composer complex to setup.

MCS 1 – Composer 0

Machine Creation Services does not require additional servers or databases and is easier to setup. This ensures the cost and complexity of the environment remains low even for large-scale environments. Therefore MCS wins this round.

Management Interface

The management interface of both technologies is tightly integrated into the main admin console of XenDesktop or View respectively. Nevertheless there is a difference in regards to simplicity and speed, but see for yourself (click on the image to start the video):

MCS 2 – Composer 0

Well, I think there is no more comment needed.

VM deploy times / IOPS impact

As discussed earlier Composer based desktops are rebooted a number of times for personalization purposes (unique computer name, etc), whenever the replica is changed.

In contrast MCS is using a two step process. As part of the preparation process of the master image, MCS creates a temporary VM. This VM performs all environment specific customizations once and in a central location. After this procedure has been finalized, the master image is linked to the MCS based VMs. While booting the VMs are personalized on-the-fly, ensuring that each VM is unique and refers to a personal computer account in Active Directory. This approach significantly reduces I/O footprint and therefore minimizes rollout times. The diagram below outlines the I/O impact of creating 1, 3 and 10 virtual desktops

Note: The measurements for XenDesktop and View have been performed on the exact same vSphere 5.5 server (HP BL280c G6). The data has been captured by means of esxtop in batch mode with a custom configuration to only trace disk related data, in order to minimize the overhead. The virtual machines are based on Windows 7 SP1 with only XenDesktop VDA / View Agent installed.

 

 (Lower I/Os are better since that means lower storage utilization)

Very similar results can be seen when updating existing virtual desktops.

 

(Lower I/Os are better since that means lower storage utilization)

Because of the more efficient image preparation and personalization mechanism of XenDesktop MCS, the I/O impact of Machine Creation Services is lower. When creating desktops the number of I/Os increases slightly for MCS since more desktops are created and their configuration needs to be written to disk. When updating the number of I/Os remains flat, since the data changes per VM (disk link) is negligible. So regardless of the number of desktops affected by a change the I/O impact as well as the rollout time will stay almost flat.

In contrast the number of I/O required for Composer increases linear, since each VM is personalized individually. This also increases rollout time. For reference VMware estimates a change rollout time of 2 hours for 1,000 desktops, as shown in the diagram below:

(This diagram can be found within this VMware white paper)

One very interesting aspect of this chart / white paper is that the testing was done on an enterprise grade all-flash EMC XtremIO storage appliance. If rolling out changes to desktops on a traditional SAN, NAS or even local storage, the time required would be significantly higher. In large scale environments this can be very challenging, since each change requires a long downtime. While the change is executed the storage infrastructure will be under high load, which can impact other services. So additional planning is required.

MCS 3 – Composer 0

Machine Creation Services uses a more efficient image preparation procedure, which results in lower storage utilization and faster rollouts of updates or new virtual desktops. This means storage cost can be minimized due to lower performance requirements and image management can be simplified due to shorter downtimes and less impact on other storage dependent services or applications. Furthermore MCS enables admins to roll-back images very quickly in case of an emergency.

General Capabilities

XenDesktop Machine Creation Services can be used to manage VDI desktops as well as XenApp servers. The virtual machines can reside on XenServer, Hyper-V and vSphere, but the MCS functionality remains the same.

View Composer is limited to virtual desktops hosted on vSphere. Other systems have to managed by means of 3rd party tools.

MCS 4 – Composer 0

Machine Creation Services enables admins to use a single tool and management console for virtual server and desktop management. This simplifies the maintenance and troubleshooting of the environment and minimizes the training requirements for IT staff

Summary

The table below summarizes the differences of MCS and Composer, which have been discussed within this blog post:

 

Efficient VM provisioning and image management is a key success factor for every VDI and HSD environment and should be one of the key criteria when selecting a VDI/HSD platform.

In my opinion Machine Creation Services hits the mark in this regards.

-Thomas
Follow me on Twitter @tberger80.