Machine Creation Services is simple to operate: it is integrated right into XenDesktop and you don’t  have to build and maintain a separate infrastructure like with PVS

Machine Creation Services (MCS) is one option for desktop image delivery. It simply uses the hypervisor APIs (XenServer, Hyper-V, and vSphere) to create, start, stop, and delete virtual machines. While MCS was originally developed ,it meant for the VDI based VM’s .  From XenDesktop 7.X, it now also supports the provisioning  of server Operating Systems.

Next to Provisioning Services, MCS is the second option that we have regarding(automated) desktop image delivery and single image management within XenDesktop. MCS is designed such a way that it will communicate directly with Hypervisor API(Application Program Interface) to care of things like VM creation, starting and stopping of VMs(Power Management),delete VMs and so on..

It support Microsoft’s Hyper-v using SCVMM,VMware vSphere through vCenter, Citrix Xen Serve through XenCenter, Azure Cloud & Nutanix. As with PVS, it all starts with a master VM,the template machine , Golden image whatever you would like to call it. A Master VM is nothing more than a Virtual Machine with everything installed and configured exactly what you want to present it to your users. When you create a Machine Catalog from Studio(based on MCS technology) you will be asked to select this master VM, which will then serve as a Base image from where all other VMs will be automatically provisioned.

MCS uses copies of a master VM, called linked clones, to provision virtual desktops. The clones include a differencing disk, an identity disk and optionally a personal vDisk, which is Citrix’s name for a dedicated virtual disk that stores users’ files, settings and other data.

MCS is based on Differencing Disk technology, which is similar to that of Linked Clones, used VMware for example. Using MCS we can provision 3 different types of desktops(catalog),

Admin can create 3 type of catalogs with MCS:

Pooled-Random:
Desktops are assigned randomly. When they logoff, the desktop is free for another user. When rebooted, any changes made are destroyed.
Pooled-Static:
Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made are destroyed.
Dedicated:
Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made will persist across subsequent startups.

A quick breakdown on Creation Process

The creation process is as follows regardless if you are doing pooled-static, pooled-random or dedicated:

  1.  Within Desktop Studio, create Machine Catalog by selecting
    1. Operating System(Server,Desktop,Remote PC)
    2. Select Machine Management (PVS,MCS,other service or technology)
    3. Desktop Experience (Random or Static Assigned Desktops)
    4. Select Master VM
    5. VM Config (Like CPU, Memory, Disk Space,No.of Machines)
    6. AD location for Machine account creation and machine account naming scheme.
    7. Summary ->Finish
  2.  First, have your master virtual machine created. This means you need to define the VM (vCPU, RAM, Disk space), install the OS, install the apps and make any configurations you want to be part of your user’s desktops. If you are thin provisioning the disk, you only use the amount needed up to your maximum amount define.
  3. MCS creates an automated snapshot (thin) of the master VM ( or you can create manual snapshot if MCS do not ).
  4. Next this snapshot consolidated(merged) and a Temporary VM will be created.
  5. This temporary Virtual machine will then boot so that certain tasks like DHCP,KMS,etc.. Can be taken care of first before it copied over all data stores which was chosen as part of your VM deployment
  6. MCS creates a full copy of the point in time snapshot and places this on each storage repository defined in the host connection. This will utilize the amount of space used for your complete image.
  7. MCS adds these desktops into Active Directory. This step creates the unique AD identities to be used later in the process
  8. MCS creates the number of VMs specified in the create catalog wizard with two disks defined for each VM. However, in addition to the 2 disks for each VM, a master will also be stored in the same storage repository.
  9.  If you have multiple storage repositories defined, then each one will get the following types of disks
    1. The full snapshot, which is read-only and shared across the VMs just created. Each storage repository will get one. This is the same disk identified in step 4.
    2. A unique identity disk (16MB) used to provide each VM with a unique identity. Functionality within the XenDesktop Controllers creates the identity disks. Each VM gets an identity disk.
    3. A unique difference disk used to store any writes made to the VM. The disk is thin provisioned (if supported by the storage) and will increase to the maximum size of the base VM if required. Each VM gets a difference disk

Why does all this matter?

Each time you create a new master VM, or update an existing one for that matter this process repeats itself. Meaning that if you have multiple master VM’s, let’s say two for VDI (windows 7 and 8) and two for RDSH (Windows Server 2008 R2 and 2012 R2) the system will create a snapshot of every master VM, four in this example, which will then need to be copied over to all of the data stores known to your host connection.

As mentioned, when updating an existing master image, the same process is repeated. The system will basically tread the updated master VM as a new master VM and as such a snapshot will again be created and copied over the accompanying data stores accordingly.

Click to have a look on Snapshots Screenshots

More Considerations when choosing MCS

  • MCS is, or at least can be storage intensive with regards to the (read) IOPS needed. On average it will need around 1.6 times more IOPS when compared to PVS for example, again, mainly read traffic from the master VM as mentioned earlier
  • When looking up IOPS recommendations based on Citrix best practice be aware that these are (almost) exclusively based on stead state operations.
  • A medium workload (based on the medium Login VSI workload) running on a Windows 7 or 8 virtual machine (provisioned with MCS) will need around 12 IOPS during its steady state with a read/write ration of 20/80. During boot these numbers will be the other way around 80/20.
  • Running the same workload on a Server 2012 R2 virtual machine will lead to 9 IOPS during its steady state with a read/write ration of 20/80. Note that this is on a per user basis. And again, during boot this will probably be closer to 80/20 read/write
  • Remember that each time a new master VM is created or one is updated it will need to be copied over to all data stores known to the Host Connection as configured in Citrix Studio.
  • Failing over VM’s while using MCS isn’t a problem, but if you would like to move the accompanying virtual machine disks / files as well, using Storage vMotion, storage Live Migration and/or storage XenMotion for example, you are out of luck. This is not supported.
  • There is a strong dependency between the VM and the Disk ID / data store it resides on (information stored in the Central Site Database), once broken or interrupted your VM will not be able to boot properly. For Example, if you have plan to migrate your Hyper-v cluster or storage migration then you need to recreate all  the catalog
  • Monitor the growth of your differencing disks and size your storage platform accordingly. Do not forget to include the duplicate images of your master VM copied over to each data store when it comes to free GB’s needed
  • Also, when an image is updated, at least temporarily, there will be two full images / master VM’s residing in each datastore, do not forget to include these into your GB calculations as well.
  • As soon as all VM’s within the data store are using the new or updated image the ‘old’ one will be deleted automatically. By default this will happen after a time period of six hours but this is configurable through PowerShell.
  • When you update the master VM /image of a persistent virtual machine’s(static), only newly provisioned persistent VM’s will be able to use the updated master image.
  • When dealing with non-persistent VM’s this works different. Once the new or updated image is assigned and the VM’s reboot, the old image will be discarded and the new one will be used from then on

Key Takeaways:

  • MCS is considered to be easy. It is managed  and configured directly from studio and you do not need any additional infrastructural components as you do with PVS.
  • MCS is based on differencing disk technology.
  • Your base(Golden Image) will be copied to overall data stores, which are part of hosting connection(storage connection).
  • When using MCS, rollbacks are treated the same way as a new or updated base image : they will again need to be copied over to all data stores involved. Note that in some cases the previous image might still in use by some machines. If so, then no full copy will be needed.