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.
  7. Automatic Step: MCS adds these newly created desktops into Active Directory, utilizing the identities created

The differences appear when the desktops are put into production:

Pooled-Static Pooled-Random Dedicated
First logon User-to-desktop association stored permanently in the SQL Database User-to-desktop association stored temporarily in the SQL Database User-to-desktop association stored permanently in the SQL Database
Logout User-to-desktop association remains User-to-desktop association removed User-to-desktop association remains
Subsequent logons XenDesktop Controller directs the user to the permanent desktop association XenDesktop Controller picks any available desktop and temporarily stores the association in SQL Database XenDesktop Controller directs the user to the permanent desktop association
Reboot Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk is permanent

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

Daniel – Lead Architect
XenDesktop Design Handbook

Advertisements

9 thoughts on “Machine Creation Services Primer – Part 1”

  1. Good article Dan…

    I must be missing a use case but what would be the reason to use Pooled-Static over Pooled-Random or vice-versa? If the differencing disk is being deleted after reboot what’s the point? It seems like using Pooled-Static may just cause headaches if something happened to the VM or the association in SQL with Active Directory, plus your not getting the benefit of a persistent differencing disk. Pooled-Random and Dedicated make sense, and I have use cases for them, but not so sure about Pooled-Static…

    Like

  2. Scott, as I understand it the pooled-static use case is where the user needs to maintain the same MAC or IP address each time they use the client but isn’t allowed to customise the client

    Like

  3. Gary, you nailed it. certain apps are only accessible via an IP or MAC. For some call centers, the IP address of the virtual desktop is linked to a phone in a particular location, this allows the app to show a persons information on the screen while routing the phone call to the appropriate phone.

    Like

  4. Hi Daniel

    Looking to seek some clarification on the following statement in your article.

    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.

    If this is on NFS then the differencing disk will be thin provisioned, correct? If this is on block storage that doesn’t support thin provisioning then what happens? Does the difference disk become the full size of the base VM. Someone told me this but I haven’t been able to get that verified anywhere.

    Like

    1. Correct. If your storage doesn’t support thin provisioning, the differencing disk will be created at the same size as your master disk image. That is one reason why we recommend NFS. Thin provisioning. Second reason is because it is easy. Don’t really have to worry about how many VMs per LUN like we do with other storage options.

      Like

  5. Daniel, I am just looking into XenDeskop and Machine Creation Services. I am curious, is there any way to split the full copy of the point in time snapshot (created in point 4) and the unique identity disk/difference disk on different storage repositories? I’d like the full copy of the point in time snapshot to be pleased on storage optimized for read IOPS (e.g. SSD) and the unique identity disk/difference disk on storage optimized for write IOPS.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s