In my previous blogs about image management I’ve focused on explaining Provisioning Services (PVS) in part 1 and Machine Creation Services (MCS) in part 2, and compared Machine Creation Services with its direct rival VMware Composer from a technical point of view. Within these blogs I highlighted a number of technical aspects where the Citrix technologies are superior to VMware’s products / features.

This time I’d like to take a step back and shed some light on why I believe Citrix has a far better single image management story than VMware (despite all the noise they make).

How to compare?

This is actually a really difficult question. It’s easy to come up with a myriad of use cases, including obscure requirements, in order to highlight the benefits of your own products as well as the weaknesses of the competitors. But I’m not sure if a biased use case really helps deciding which technology / tool is best.

So decided to go for a very generic virtual desktop use case, based on the results of the “State of the VDI and SBC union 2013” survey done by PQR:

  • Mixed Environment: Based on my experience the vast majority of customers are using a mixed virtual Windows Workstation (e.g. Windows 7) – VDI and virtual Windows Server (e.g. Windows 2012 R2) – SBC/HSD environment. Regardless if they come from a Server Based Computing / HSD world and go for VDI because of performance or application compatibility reasons, started off with VDI and now shift towards SBC/HSD for better user density or if they need both in parallel. A single image management solution should support both use cases. If not, two separate management infrastructures need to be implemented and admins need to be trained twice. Both increasing cost.
    The numbers within the state of the union white paper mentioned earlier, backs this up. Although the paper does not specifically state what percentage of customers are using mixed environments.
  • Stateless Desktops.The majority of customers are using stateless (aka pooled) desktops in their primary or secondary scenarios. This means users can change user specific settings, such as the wallpaper, the Outlook signature or add favorite websites or custom dictionaries. But they cannot install applications on their own. This makes a lot of sense for at least three reasons:
    • No / Less license violations. The IT department can ensure the organization owns sufficient licenses for the applications in use.
    • Supportability / Manageability. Users connect to a well know environment, so troubleshooting user issues is much simpler then if each user has a different set of applications. Furthermore this enable the admins to perform regression testing for application or OS updates. If they don’t know the apps, they can test them.
    • Single Image Management. If only well known applications are used, single image management tools can be used. This enables the admin to maintain ideally just one / a few image (OS + applications), instead of each virtual desktop individually. This means IT agility (rolling out new or updated applications) is much higher and in case something goes wrong, the rollback times are much lower. Furthermore the disk space requirements are lower, since I just have a single full blown image of a large number of virtual desktops, without even investing into de-duplication technologies on the storage backend. At the end of the day this means the cost of building/hosting/maintaining the environment is lower.

So my use case is a stateless mixed virtual desktop environment. Now I expect a few of my readers to jump of their chair and shout “What about the non-standard apps?” / “What about the developers, traders or creative artists using my virtual desktop environment?”. Well, I believe non-standard applications should be handled as an exception. So IT provides a fully tested standard desktop or application set for each user group. If the users need any apps in addition, they should be either integrated into a IT provided build (whatever technology is picked here / e.g. App-V) as soon as a significant number of users require an app. Alternatively the users could be provided with the ability to install their applications into an elevated part of the standard build. So I’m talking about some sort of application virtualization / layering here, which enables the user to perform system wide changes but still provides the admin the option to centrally manage the image (e.g. Personal vDisk).

I know this sounds like a pretty restricted environment, but I strongly believe VDI and SBC/HSD is all about standardization. Yes, there are other drivers like data security and application performance for heavy apps (e.g. SAP) as well. But at the end of the day all comes down to a positive business case and that is much easier to achieve if we standardize the application landscape (this also includes application rationalization).

This is how cloud economics work -Low price by large scale-. But there is no large scale without strong/enforced standardization.

In case the users really, really need to be very flexible, then why not integrating the line of business apps with BYO endpoints. The users then have the absolute flexibility and IT can focus on providing the business critical apps.

What are the criteria?

So, again, the use case is a stateless mixed virtual desktop environment. Now we need to define the criteria, which helps us understanding why Citrix has a better single image management than VMware. So from my point of view, these are the ones that really matter:

  • Support for VDI and SBC/HSD. Has to support the mixed stateless virtual desktop environment. (That’s a pretty obvious criteria)
  • Management Efficiency. The solution should enable the admin to rollout and of course roll back changes quickly. Especially the roll back part is not considered in many cases unfortunately. But in environments with single image management this is vital, since a change on the master affects hundreds or thousands of users.  So there must be a quick way to go back to the last good known configuration.
  • Management Simplicity. The solution should simple to use in order to keep the training requirements low.
  • Infrastructure Impact. The impact to the virtual desktop environment (e.g. storage utilization or downtime) should be low. Otherwise additional desktops have to be hosted to cover for rollout downtimes (aka overprovisioning) and/or additional storage capacity has to be acquired to cope with the increased load during rollouts.

Why is Citrix better?

The first reason is very simple. Neither VMware Composer nor VMware Mirage support image management for Windows Server workloads. This means if your organization is or will be using VDI along with SBC/HSD, VMware cannot help you managing your environment. In contrast Citrix Provisioning Services as well as Machine Creation Services do support Windows Workstation and Server operating systems.


The second reason comes down to rollout and rollback performance. I’ve already discussed this topic for Citrix Machine Creation Services within my last blog post. But Citrix Provisioning Server is even more powerful in this regards. This is actually a unique feature of Citrix Provisioning Services (PVS). Instead of deploying the central image to the virtual desktops, PVS sends (streams) only the part of the image that has been requested by the virtual desktop. So for example when starting a Windows 8 approx. 200MB are transferred over the network, regardless of the size of the actual image. Provisioning Services will take care of the personalization of the virtual desktops (e.g. computer name, AD account) automatically on the fly. Although this might not sound so special, think about the implications when rolling out a new application. All that needs to be done, is to point the virtual desktops to a new version of the image. Upon next reboot the virtual desktops will get their data from there. If you need to roll back, it’s the same thing. Just point to the old version and reboot the virtual machines and you´re back to the last good known state. So the time it takes to boot 10, 100 or 1,000 systems is the time it takes to roll out a new image or to roll it back. There are no additional delays.

In contrast Composer needs to prepare each virtual machine separately. So in case of a change, the new version of the full image or replica will be copied to the storage and then each and every virtual desktop needs to be booted a number of times and scripts need to be executed.

VMware Mirage on the other hand works more like a traditional Enterprise Software Deployment (ESD) solution. Although it provides single image management capabilities, the operating system and the applications are deployed onto the hard disk of the virtual desktops. Since Mirage was build for physical endpoints, the software architects did not pay to much attention to CPU and disk utilization (IOPS). Their focus was on optimizing the delivery of the software / updates over the network. So they use a lot of CPU cycles and disk I/Os in order to minimize the amount of data send across the network. This approach makes a lot of sense if you manage physical desktops or laptops, but for virtual desktops located within a data center this approach is sub-optimal, since it negatively impacts the user/desktop density negatively.

Common for both VMware technologies is that the rollout / rollback is time intensive. So for example with Composer is takes about 2 hours for 1,000 desktops on a dedicated all flash storage appliance. Also both technologies have a significant impact on the underlying storage infrastructure from an I/O perspective. So in order to cover for the downtime during a change, additional desktops need to be created (over-provisioning) and the storage infrastructure needs to be powerful enough to serve the high number of additional I/Os without impact the performance of other workloads. From a technical point of view this is no problem, but cost wise this is severe.

The following diagram outlines the I/O differences when updating Windows 7 desktops. All tests were performed on a single HP BL280c with local storage, running vSphere 5.5. Only the virtual desktops were hosted on this system. The IOPS data was gathered with esxtop.

As a side node: PVS was configured to use the hard disks of the virtual desktops for the write cache. Alternatively I could have configured PVS to use some RAM on the target side for the write cache. In that case we would see 0 IOPS for all use cases.

As you can imagine the significantly lower I/O footprint of MCS and PVS result in significantly lower rollout times.

Proof your point!

In order to illustrate the operational benefits customers get with Provisioning Services, I’ve created the following video, which compares the task of rolling out Microsoft Office 2013 to three virtual desktops by means of PVS and Composer.

I understand that no organization would implement any single image management technology for mere three desktops. That would be the ultimate overkill. But for this purpose three desktops were enough to illustrate significant differences.

In addition I created an extended version of the XenDesktop MCS vs VMware Composer video. It goes beyond the management experience and shows the actual desktop creation, provides some technical explanation of why we see significant differences in the deployment performance and provides you an exclusive view behind the scenes, showing you what XenDesktop admins do while waiting for their View colleagues. Here is the new MCS vs Composer video:


The table below summarizes the differences of Citrix Provisioning Services, Citrix Machine Creation Services, VMware Composer and VMware Mirage.

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.

Follow me on Twitter @tberger80.