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.