Citrix Provisioning Services vs Machine Creation Services 2014 revision

Two years ago I started writing the Citrix Provisioning Services versus Machine Creation Services decision trees. A year and 12k visitors later it’s time for an updated version. The Provisioning Services vs Machine Creation Services decision tree has gotten a lot of attention over the last year. It’s used on Citrix blogs and more recently in one of the Citrix webinars by Atlantis Computing. This makes me proud and definitely works as an energizer to continue working on projects like this.

I’m writing this in such a way you won’t need to read the earlier articles but of course you are free to do so anyway.

The first article by Daniel Feller can be found here.
My article called Provisioning Services vs Machine Creation Services can be found here.
The 2013 revision of Provisioning Services vs Machine Creation Services can be found here.

After Daniel posted his decision tree over three years ago a lot has changed.

  • New Citrix features like XenServer Intellicache, MCS for “XenApp on XenDesktop 7″ and Citrix Provisioning Services in memory caching (with spill-over to disk)
  • In memory caching and deduplication by vendors like Atlantis Computing
  • Hardware vendors like FusionIO who are delivering local flash based storage with IO figures with over 200k IOPS
  • Local SSD storage prices have dropped massively and predictions are prices will continue to drop this year
  • The introduction of a new industry called Web-Scale technology with leading vendors like Nutanix. Bas van Kaam wrote an excellent article on WebScale technology.

New features and devices are not the only thing that changed over the last few years. Our knowledge of Windows IOPS usage and how to handle that load has grown as well. Mostly thanks to Jim Moyle and his extensive research into the world of the Windows IO needs. One example is the “MCS uses more than 1.6 times the amount of IOPS over PVS” discussion. This was only true in a theoretical world because we are talking about read operations which are mostly cached anyway.

All of this combined completely changes the decision making process and with this new revision I’m going to share my take on this. Will this always be right? Probably not and even if I am , it will change over time. Keep your eyes open and be smart! Please let me know if you have another use case and help me get it right!

Before focusing on the why and how let’s start with looking at the original decision tree by Daniel Feller.

pvs-mcs-tree

Now that we have seen the decision tree it’s interesting reevaluate certain decisions. I will finalize everything in the end conclusion where a new decision tree is included. Please remember Daniel created this years ago and all the changes are because technology changed, he wasn’t wrong at that time and the decision tree has proven to be valuable!

The reason I’m comparing the oldest of Decision trees to the newest is to make sure we don’t leave any old best practices floating around.

With great best practices come great responsibility! Never stop thinking!

Mix and match

Let’s start with the first decision in the tree in which we ask the question about using a XenDesktop only, XenApp only or mixed platform. The reason for this is that, before XenDesktop 7, it wasn’t possible to do MCS for XenApp load. Since XenDesktop 7 it’s actually possible to use Machine Creation Services for XenApp.

IOPS

In the old days we were worried about boot and logoff storms because of the amount of IOPS this generated on our expensive shared storage systems. If so we would advice to use Provisioning Services because of better IOPS caching possibilities.

Lots has changed in the past few years but the IOPS load is pretty much still the same, yet the decision making process changed. The reason for this change is that we now have more knowledge about the amount of IOPS and vendors jumped in and created new solutions offering huge amounts of IOPS on central or local storage.
On the hypervisor level we are now able to do live storage migrations. This helps us when we need to perform management tasks and don’t have the time to wait for all of the users to close their sessions.

Thin Provisioning

For Machine Creation Services it’s highly recommended to use a storage solution that offers the ability to utilize thin provisioning. This way we only use as much data as we need for write caching. If we don’t utilize thin provisioning each target will use as much disk space as the configured base image.

Persistency

Another decision is the need for dedicated aka persistent virtual desktops. If we need persistency you were forced to use Machine Creation Services. The reason for this decision was based on the fact that Provisioning Services falls back to Server Side caching when the cache had to be persistent. This method of caching results in a crappy desktop performance.
Since the introduction of Citrix Provisioning Services 6 we are able to offer persistent caching on the local target hard disk, which pretty much solves this issue. We therefore are now able to utilize Provisioning Services and Machine Creation Services for persistent desktops.

Physical vs Virtual

When we have a demand for physical virtual desktops we still need Provisioning Services. Machine Creation Services integrates on the hypervisor storage layer and therefore can’t be used on a physical target. This is the simplest decision of them all!

Advanced Image Management

As a reader of my blog you should already know that I like automation therefore I would never update images but instead rollout a new image. This way I can retest my image deployment every once in a while . Not of lesser importance I can always go back to my deployment run books to see how a certain component was installed for troubleshooting purposes.

If you care about image versioning and do a lot of image updates Provisioning Services is your way to go. Provisioning Services gives you greater flexibility to work with image versions and updates. Not everyone agrees with me on this one so I have decided to keep this out of the decision tree for now.

Multiple image locations or multiple images

This section has been added after publishing the article because the decisions attracts some attention, mostly by the guys from Atlantis Computing which must mean this market space has their full attention:). When we look at the Provisioning Services (PVS) architecture we have a central image store, the PVS server, for the sake of keeping things simple I’m not going into where PVS gets the image from local, filer, DFS et cetera. Machine Creation Services (MCS) works on the storage layer and places the image on each datastore which is used for targets.
When I create a new image or update an image with PVS I just change the pointer for each target and I’m done. With MCS that’s different, MCS first creates a single imagefile from a VM snapshot and when finished copies that image to each datastore. This process takes up CPU, IO and network resources and can take up to an hour in one of my production platforms (SSD 10Gbit et cetera).
So imagine a VDI cluster with 12 hosts with locally presented storage, this could be SSD, FusionIO or just as easily Atlantis ILIO. This would mean we have, at least, 12 storage datastores. With PVS this all stays simple, PVS is the central image location. With MCS this would mean we copy the base image to 12 different datastores.
Aside from the multiple image locations think about what happens if you have more then one image. This is not uncommon in enterprises, an example could be a VDI image, an RDS image with Internet Explorer 10 and one with Internet Explorer 11. This would mean that for MCS we copy not one image to 12 datastores but three images to 12 datastores. Think about the time and resources going into maintaining those images.
My decision would therefore be to stick with Provisioning Services when you have more then a couple of datastores or images. This is my personal opinion and there are some very smart people who would  judge differently on this one. Remember what I said before “With great best practices come great responsibility! Never stop thinking!”.

So here we go; let’s help you decide between Provisioning Services vs Machine Creation Services 2014 style!

So many things changed over the last few years and it is time to re-evaluate the decision tree. Remember that this is just me sharing my decisions and everyone is entitled to their own ideas. When you disagree on a decision please let me know in a comment, when I agree I will change the decision tree and if not…… everyone else can at least think about your ideas.

One last thing before I’ll show you the decision tree. If there is a decision that ends up in either Provisioning Services or Machine Creation Services this doesn’t necessarily mean you are not allowed to use the other one as well. You can mix and match Provisioning Services and Machine Creation Services. I like my designs to be as simple as possible so my advice would always be to actually make a choice and stick with it. I completely agree that it would be naive to say that this will always work but I’ll at least always try to do so.

Provisioning Services vs Machine Creation Services Decision tree

The first thing you should remember while deciding based on this decision tree is that this is my advice to you. If your choices end up on either Provisioning Services or Machine Creation services you could still decide to go either way. I won’t hunt you down, I promise. There is only one technology choice that is an absolute no go and that is the first choice in regard to physical targets, this will always end up in using Provisioning Services.

If this were a movie I would now say cut and wrap it all up. But with every movie there are some names at the end of it with names of people who contributed to the movie in some way. I’d like to thank some of the guys who shared their thoughts with me and with that helped me to be able to share this information.

Jim Moyle for his terrifying knowledge on IOPS
Daniel Feller obviously for writing the first ever article on deciding between provisioning services vs machine creation services .
Kees Baggerman for challenging me on a daily level and reviewing this article
Andrew Wood for reviewing
Shawn Bass for his sharp eye, saved me there!

Please leave a comment when you have new insights to add to the Citrix Provisioning Services vs Machine Creation Services decision tree

Leave a Reply

  1. Nice job Barry. I still struggle with Citrix pushing MCS so hard when PVS is, to me, a better solution. Cache in RAM? Um… yes please! PVS was ignored for a while but seems to be getting some more love lately.

    • Paul I feel exactly the same way. I am familiar with both products extensively and I truly have seen that the benefits and drawbacks of each are a total wash with infrastructure. However IMAGE MANAGEMENT WISE, which this article only addresses the executive decision from the standpoint of topology and core infrastructure, PVS absolutely obliterates MCS. I can, WHILE IN PRODUCTION, WITH USERS ON MY XA7.5 servers, make full and complete changes to an image, reboot it, test it out and then deploy… All during working hours. I am a 40hr person with PVS.. MCS not so much. Thanks for this post BARRY!!!!!!

      • I should add, the environment I am speaking of does NOT have XD or VDI of any kinds. Strictly published desktops and apps.

  2. In VDI context, I think size of pools matter.. if you are refreshing 1000’s of VDI desktops – the amount of time this takes in PVS vs MCS can be quite differentiated – in favor of PVS.

  3. Hi I have decided to us PVS because of the scaling, but I have question regarding the hardware. If I put the PVS on the xenserver guest, can I use local disk or prefer using network storage for performance ?

  4. To be honest the issue of multiple targets for MCS could be greatly mitigated by running the SR copies in parallel and not in series! Surely this can’t be difficult to code on XS….

  5. How does hypervisor play into this decision? Is there additional benefits to using XenServer with one or the other? Many of my clients use VMware 5.x or newer so does one play better with ESXi than the other?