Machine Creation Services Primer – Part 1

I get a lot of questions about different components of XenDesktop. What are they? How do they work? Should I use it? I’ve decided to spend some cycles trying to provide information about some of these components. The first one we will hit is Machine Creation Services.

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. Let’s say we want to create a catalog of desktops with MCS, you can pick either:

• 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.

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

1. Manual Step: 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.
2. Manual Step: Within Desktop Studio, you create a catalog for a pooled desktop and you have to select the master virtual machine you want to base other VMs on. This is the one you installed and configured with the OS and applications.
3. Automatic Step: MCS creates a snapshot (thin) of the master VM unless you selected a snapshot, which will not create another snapshot. This uses minimal space
4. Automatic Step: 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.
5. Automatic Step: MCS adds these desktops into Active Directory. This step creates the unique AD identities to be used later in the process
6. Automatic Step: 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 be stored in the same storage repository. 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.

The differences appear when the desktops are put into production:

In the upcoming Part II, we will focus on what happens when we need to make updates