How To Handle Patch Management in vCloud Director

I have gotten this question a few times and I have seen it on a number of emails.  I wanted to take a moment to address this because there seems to be some confusion on just how to manage your deployed vApps, but also the ones in the vCloud Catalogs.  For the time being we can leave out the Fast Provisioning aspect and assume that everything has been deployed from a full copy.

Patching Deployed vApps

This is pretty simple and I am not sure why I see the question that often.  These are virtual machines, just like any other.  They are on the network and can be patched the same as you always did.  You can use agents, windows update, CRON jobs, whatever you like to patch them.  There is no magic in vCloud Director that helps you patch your vApps, but people seem to think there is.  Bottom line, business as usual here and there is nothing new you need to do.

Patching Catalog Items

Now this can be a little more tricky.  Many of us new to vSphere have been spoiled by the template functionality.  With that, the ability to flip a vShpere Template to a virtual machine, power it on, patch it, and flip it back to a template.  That is easy in vSphere, but not quite the same in vCloud Director.  Remember Catalog vApp templates are NOT marked as a vSphere template, they are in fact just a powered off virtual machine.  For us old guys, this is the same as it used to be in ESX 2.5 with Virtual Center.  The basic process is as follows:

  1. Deploy the vApp Template as a new vApp to an “Operations Org”
  2. Patch the vApp as needed
  3. Remove any changes or customization that was run on deployment
  4. Shutdown the vApp
  5. Copy it back to the Published Catalog
  6. Remove the original vApp Template

This is not so much different from the good old days of 2.5, where we deployed, patched, and saved.  I suspect this process may get easier as we move forward, but that remains to be seen.  For now, just remember it’s not impossible to keep your vApp templates up to date, you just need to work at it a little bit.  In fact I myself have to do this process to update my CentOS 6.2 templates in my vCloud Express to make sure they are up to date and ready for the next use.

This may seem obvious to some, but the fact I have seen and heard this being asked made me feel like I needed to post something.  I was just a little astounded by the question as it implied there was some magic mechanism in vCloud Director to patch you’re vCloud based virtual machines.  Of course you could probably use vCenter Orchestrator to workflow some of this once you have your basic processes figured out to handle a lot of vApp Templates.

 

8 comments

  1. What about patching solutions as an MSP? Staffing a team just to manually update every customer VM seems quite silly. I haven’t seen much offered in the realm of patch management from an MSP perspective. 🙁

    • Wouldn’t customers patch their own in some cases?  Windows machines would need reboots and thus the consumer would need to approve that.  Either way the point is patching is Business as Usual for the most part.  There is no secret sauce because it is in cloud or because is is a virtual machine.  I have just seen people ask the question “how will this make patching easier for me?” and I cannot seem to understand why anyone thinks it is any different.

      • Some cases yes. Most of our customers are looking for a fully managed solution where we do updates, antivirus, etc. We have a published maintenance window where VMs could possibly be unavailable for this reason. Sure we could just turn on automatic updates and tell Windows to automatically install everything but what if an update breaks an application? Without some type of control, there’s no way to tell which update caused the issue then we as the provider are responsible for fixing the application. See the dilemma?

        • That makes sense and I see the issue you have.  However, I think my point still remains that you have to make those operational decisions with or without cloud and/or virtualization.  Those issues do not change just by adding vCloud or vSphere to the mix.  Patching is an Operational deal in most cases, but some still seem to think because they have a virtual machine the process to patch it changes when it has nothing to do with it being physical or virtual.  Would you agree?

          • What about when using fast provisioning aka linked clones… how would you update those?  I figure there would be some catch… Forgive me I haven’t researched but very curious.

            • With those you will patch each VM as normal. Unlike View there is no way to “Re-Compose” them from a previously patched base image, and in reality you would not want to.  The fast provisioned clones are like Persistant Desktops in a sense and if you re-composed you’d lose all the data.  

              Basically patch them like any other VM, there is nothing Fast Provisioning will or will not do to help you here. This applies to provisioned VM’s. As far as catalog VM’s this is a little different. I may have to do some testing. Becuase a shadow VM is created for the linked clones I think you can replace the original catalog VM. I need to really look into this though.

              I have always stored my catalog VM’s in a vDC that is NOT fast provisioned so I can deploy them, Patch, and re-add to the catalog all as thick VM’s. I had seen at one point that if you deploy a catalog VM that is in a fast provisioned vDC, then patch it, and save it back to the catalog, that item is now a linked clone.

              Bottom line You have given me something I wanted to test anyhow a little higher priority. I had it on my blog list to examine exactly the behavior of managing linked clones for patching.

              Want to co-Author it? 🙂

  2. Due to the new Fast Provisioning Chains and limits, I was wondering if it would be wiser to keep a Patching vApp that keeps the VM to patch, then delete the catalog VM and replace it with the newly patch VM, this keeps the number of FP chains low, as well as the OS rearms.  Whacha think

    • I think something like that is reasonable.  I am not sure it will solve the re-arm issue as much, but you can also keep the published templates in a different org that is NOT fast provisioning enabled, then publish and share them out.  Might be easier.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Scroll To Top
%d bloggers like this: