Machine Creation Services Primer – Part 2


In the first part of the Machine Creation Services Primer, we focused on the creation of Pooled-Random, Pooled-Static and Dedicated desktops. The process was very similar. However, at this point, items start to change and I want to focus on updating the master image, as this question usually comes up pretty quickly.

With Machine Creation Services, we have a master virtual machine somewhere within our environment. This master is what is used to create all of our MCS-provisioned desktops. On a weekly or monthly basis, many organizations will want to update the master image to include the latest updates. Easy enough, you just go to the master VM, and update it like any other VM. Once the master image is updated, you go into Desktop Studio and run the Update option. Here is where things start to be unique.

With pooled-random and pooled-static desktops, a new complete clone is created from the master image (just like when we create new VMs in Part 1). During reboot of the pooled-random and pooled-static desktops, a switch is made to tell the VMs to start reading from the latest cloned image. As the difference disks are deleted during reboot, there is no issue with the swapping of the master image. However, dedicated desktops are different.

With dedicated desktops, the difference disk does not get deleted on each reboot. This gives the users greater ability to customize their desktop. When we update the master VM image, the dedicated desktops are NOT told to use the latest cloned version of the master. Instead, they continue to use the cloned image from which they were created from. Only newly created dedicated desktops will use the latest image.

This is a very important point. If you use pooled-static or pooled-random desktops, updating the master image will update all virtual desktops based on that master image. If you use dedicated desktops, once they are created, their link to the master VM is severed. If you want to update the desktops, without losing all user changes, you must use your enterprise desktop management tools.

This process is important to note as I’ve had many people ask me why they have a lot of space being used by the master images. Let’s think about this from a storage perspective. Let’s say we are in the middle of a rollout with dedicated desktops. During the rollout, I’ve had to keep updating the master VM. Each time I update and create new dedicated desktops, that image is fully cloned and placed on my storage. If the image is 30GB in size (10GB thin provisioned), that means each storage repository containing the dedicated desktops will utilize 150GB (50GB thin provisioned) of storage space for the 5 difference images. As you continue and add more desktops with more updates, you will continue to increase storage space needs.

With dedicated desktops, managing the updates should be done with desktop management tools to the actual VMs and not the master image. The master image is there to help you quickly build desktops. It is not there to help you maintain dedicated desktops. However, with Pooled-Random and Pooled-Static desktops, the master image is there to help you with desktop maintenance and management.

Daniel – Lead Architect
XenDesktop Design Handbook

Advertisements

3 thoughts on “Machine Creation Services Primer – Part 2”

  1. Hi Daniel,

    That last part is spot-on! Dedicated desktops should be managed the ‘traditional’ way; not with MCS or PVS for that matter. This is something that’s often a discussion. Good to read this statement!

    Thanks

    Like

  2. Hi Daniel

    Loving the site, it’s been of great help for some PVS and MCS sizing excercises recently.

    I’m trying to get an understanding of how the master image changes affect the deployment of those images around individual datastores.

    1) if I change a master image (apply MS patches for instance) is a new copy rolled out to every datastore (the ones listed within the storage repository of the host connection).

    2) Would I be right in assuming that as well as the new master image the old master image needs to be maintained for a period of time until all desktops linking to the old master image have been rebooted?

    3) Do you need to allow for extra capacity in a datastore to host multiple master images (number of images depends on update frequency and reboot frequency of linked VMs)

    4) Do you only have to maintain the master image in one single location place or do you have to manage it in every datastore. i.e. would more VM’s per datastore be easier from a master image management perspective?

    Hope you can help clear up some of my confusion, keep up the blogging some really good stuff in here and on your employers site :o)

    Like

    1. 1. Yes.
      2. Yes
      3. Yes, but this is minimal. The database for XenDesktop 5 doesn’t get very large. What does get large is the transaction file, but creating a new image or updating an image has little impact on that.
      4. Only one location. 😄 5 will push it out to the right locations based on your host configurations within Desktop Studio.

      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