Citrix Machine Creation Services (MCS) is already available for a pretty long time. Developed as an alternative for Citrix Provisioning Services (and a reaction to VMware Linked Clones). A topic for discussion between the MCS proponents and the PVS proponents. Loved by the easiness to use it, however also not much documentation available about it (because of the easiness??). In this article I would try to demystify Machine Creation Service, based on practical experiences with (troubleshooting) MCS at a customer.
I just stated that there is not much documentation available, but actually I needed to say that the information is pretty scattered and a bit difficult to correlate together. I’m trying to write down everything I know, found on the Internet and my experiences with MCS. This article series is written with help of several people. As the article series is still being written I will thank them at the end of the article series.
Master Image
Just most image techniques we need a master machine, on which the “old style” installation needs to be performed. Smart IT organizations will arrange that this master image is enrolled based on an fully automated methodology (check the articles of Aaron “Stealthpuppy” Parker and Trond Ervik “XenAppBlog” Haverstein for more details). This master image includes the Citrix XenDesktop VDA agent as well. There is specific parameter to set-up the VDA agent to be used as a master image, however I don’t think it is really necessary. I used several default installed VDAs in combination with UCS and that worked without issues. However not recommended as Citrix did not create that option without a purpose.
When the master image is ready we can really start using MCS. But before we start the MCS process you should already consider which type of MCS VDIs you would like to enroll.
MCS deployment types
First you need to determine if you would like to use MCS for a pooled or dedicated VDI. With a pooled VDI a user will get a random VDI when a session is started. When the user logs off the VDI will be become available for another user (after the machine is reverted back to his original state). In the other case a specific VDI will be assigned to a user. When the user logs on later again he will get exactly the same VDI again.
When choosing this flavor another decision needs be made. Need the changes be made retained or deleted when the session is ended. In the case the changes will be discarded at logoff the VDA will be restored to his original values (how this is done will be described later on this article series). When changed need to be retained you still can choose between two options, however one of the options is deprecated (personal vDisk). In other words, this feature will not be enhanced anymore and probably removed from the product. Currently Citrix is working on User Layers in Citrix App Layering, which will be successor of this deprecated Personal vDisk feature. I would not recommend to start using this option anymore for new deployed MCS based infrastructures, also as there is not huge base using this feature. At this moment the only option is saving the changes on the local disk.
When choosing for retaining the changes one last choice need to be made (if you are running XenDesktop 7.12 or higher): use the fast clone or the full clone methodology. Unfortunate both techniques have advantaged and challenges, so it is not easy to make a decision between those. Fast clone has the advantage that the creation of the VDI is much quicker (only two small disks need to be created, will explain this in more detail later) and if you have a thin based storage system you have will have less disk space requirements. However a connection with the basedisk (a fully copy of master image) is always available and cannot be replaced by a new version. In the case you want to update the basedisk, you need to create a new MCS based machine catalog next to the existing. In a longer timeframe you can end up with a lot of Machine Catalogs. Using the full clone technology, the base disk will be fully copies for each VDA created. As it is a full copy there is not direct connection with the base disk (it works without the base disk available). Logically this requires more disk space on the storage level. The advantage is that you can lower IOPS than with the fast clone technology (but not necessary). However when you would like to have an updated base disk you have the same challenges as with the Fast Clone. The Machine Catalog cannot be updated, so a new one needs to be created if the basedisk needs to be updated (in theory you can delete the old basedisk, to save some disk space). An advantage against the Full Clone is that back-up programs can back-up the VDI, while with the fast clone this is difficult or not possible at all (depending on the back-up product).
I have measured the difference in creation of a Fast Clone and Full Clone on the same type of storage. Logically the Fast Clone goes way quicker, especially after the first VM (as with the first one the basedisk need to be created/copied (more on this later on).
In below shown figure you can see the actual differences.
For both methodologies don’t forget that you a need to have a system management system available to update the machines with updates and additional software.
That is understandable but in which case you would select which type of MCS deployment
- Random assigned: Probably the most used MCS deployment. Perfect for VDIs which have all software installed (so no personalized software is required) and retaining user data and settings is not required or accomplished via another methodology like Citrix User Profile Manager (UPM). This is also labeled as a Pooled VDI.
- Static assigned, discard changes: I don’t see much use cases for this variant as it requires a specific VDI for each user. In comparison with Random Assigned you need to have more disk space available as you need more VDIs. Did not see this option running at a customer and the only reason that I can think of that you always know you have a VDI available for each user.
- Static, retain settings, fast clone: Very useful if you the need for quickly delivering new VDIs is high and/or when thin based storage is available in the infrastructure in scenarios where user settings need to be retained and users have needs for specific software within the VDI.
- Static, retain settings, full clone: Exactly the same reasons for choosing a Static with retaining settings and Fast Clone. Choosing Full Clone above Fast Clone can be lower IOPS and the possibility to back-up the VDI.
Summarization
In this first part article we discussed the first steps for creating and maintaining Citrix Machine Creation Services (MCS). We talked quickly about creating the master image, followed by the available MCS deployment type with their characteristics. In the next article we will discuss what happens under the hood when creating a MCS machine catalog per deployment type.