PVS vs MCS – Part 5: On-Going Maintenance


This is part of a series comparing Provisioning Services and Machine Creation Services

Deploying Machine Creation Services is extremely easy as there is nothing to deploy.

Deploying Provisioning Services is easier with Hyper-V Gen2 VM support and the single-stage Boot Device Manager.

This sounds great, but what about on-going maintenance?  (something many fail to consider)

Overall, the update process for both imaging technologies are simple to perform through the respective consoles.  However, with Provisioning Services, there have historically been some special considerations in order to update the Boot Device Manager file as well as updating the Provisioning Services Agent that we must take into account.

Boot Device Manager

If you assign the BDM file to each virtual machine, you need to ask yourself how you update the file if your Provisioning Services infrastructure changes?

Before the XenApp and XenDesktop 7.9 release, this often meant the admin must update each virtual machine. This is not a very good admin experience.  That experience drastically changed.

With three clicks of the mouse totaling about 15 seconds of time, the admin can update all target devices with an updated BDM file.

BDM Update

Provisioning Services Agent Update

Next, we have to concern ourselves with updating the Provisioning Services Agent contained within our master image file.  Unfortunately, treating an agent update like any other update to the image would result in a non-responsive system.

To utilize a PVS image, the virtual machine requires a constant network connection, but updating the PVS agent will result in the network going offline as the network drivers are updated.  Once the network drops, the VM can no longer function and the update never completes.

Historically, this process meant we had to do a process called reverse imaging where we take the network-streamed image file and rebuild a traditional virtual machine based on storage. This removed the constant network connection requirement, and allows the admin to update the agent successfully.

Although reverse imaging does work, it isn’t a very efficient admin experience for updating the PVS Agent. In the 7.9 release, the admin experience changed.

With 7.9, updating the PVS agent follows the same process as other updates. Look at how updating the PVS agent has changed over the past few PVS releases, taken from docs.citrix.com.

Updates

The image is too small to read the details, but look at the differences in the length of this process. The number of steps in this process has quickly decreased from multiple pages to just 2 lines.

Image Life Cycle

Certain organizations require image updates to go through multiple user acceptance testing deployment stages of

  • Development: Phase for the admin to make the necessary changes to the image
  • Test: Deployment to a small group of users to validate implemented changes
  • Production: Deployment too all users

The entire process should be accomplished without impacting the current production users.

Machine Creation Services image life cycle focuses on Development and Production.

Provisioning Services image life cycle focuses on Development, Test and Production.

Fast Image Update/Rollback

In addition to the image life cycle process, certain organizations require the ability to quickly roll out new updates and instantaneously rollback to a previous version. Unfortunately, mistakes will be made in an image update potentially resulting in issues for the users, requiring the admin to roll back to a previous version until the issue can be resolved.

If the issue impacts a mission critical component for the organization, the admin will need to roll back as fast as possible.

Machine Creation Services can roll out new image updates and rollback to previous versions. However, this process, is not instantaneous as a new version of the image must get cloned from the correct VM snapshot. The cloning process can take some time to complete.  The speed of this process is based on the underlying storage subsystem as well as any optimizations utilized within the hypervisors (VAAI/ODX as examples).

Provisioning Services, on the other hand, is able to rollout/rollback changes in the time it takes to reboot the virtual machines by using the vDisk version wizard.

Summary

So where does that leave us in the Machine Creation Services and Provisioning Services comparison?

UpdatesProvisioning Services does edge out Machine Creation Services with the ability to instantaneously update/rollback images and having a more traditional life cycle process focusing on development, test and production phases.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

Advertisements

2 thoughts on “PVS vs MCS – Part 5: On-Going Maintenance”

  1. With PVS 7.9, assuming there is a VMxnet3 driver update, would a VMTools update require traditional reverse imaging? I have seen some “hacks” using VMWorkstation or Hyper-V to mount the VHD/VHDX to get around this, but curious if the driver update will still cause a failure due to the streaming nature of vDisks. Hoping you can answer before I trail/error it to find out. 🙂 Thanks!

    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