icetray - Fotolia
Every virtual machine is based on software that includes the hypervisor, the guest operating system and the actual workload (application) running in each virtualized instance. As with any software, it can be important to apply patches and updates when security flaws are corrected, software bugs are fixed, performance or compatibility improvements become available or desirable new capabilities appear.
Generally, there is no set schedule for patching hosts or virtual machines, but there are some VM patch management guidelines. Software developers may try to release patches on a regular basis, though critical patches may be released at any time. The challenge for IT professionals is to recognize that a patch is available, then determine if the patch corrects a problem or adds value that will benefit the business. For example, if a software vendor releases an emergency patch to fix a glaring security flaw, a business will typically work to test and install the patch as soon as possible -- even tolerating a small amount of service disruption or downtime in order to complete the patch. By comparison, a patch that fixes spelling errors or changes tool tip layouts will most probably wait for a more convenient patch window.
However, all VM patch management should start with a review of software dependencies and a proof-of-concept test in a lab environment before the patch is rolled out to production systems. The goal is to ensure first that any supporting software required by the patch is also updated and see that the patch process is understood and working properly, then to verify that all related procedures continue to operate as expected. For example, if Hyper-V servers require a System Center Data Protection Manager update, it may be necessary to update Integration Components (drivers) to the latest-version before applying the DPM patch. Otherwise backups through DPM might be affected.
It's best to evaluate the patch and look for unforeseen consequences in a lab rather than risking extensive disruption of production platforms if the patch goes sideways. If a problem is actually identified in the lab, a business will have the option of further study and time to discover workarounds, or there may be an option to wait for a subsequent patch that will address the issue.
The actual patching process depends on the tools that are deployed, such as Windows Server Update Services (WSUS), VMware vSphere Update Manager, System Center Configuration Manager or third-party VM patch management tools like Shavlik Patch. But there is no substantial difference between patching virtualized and nonvirtualized systems. In addition, it is possible to use a mix of tools to patch different platforms. For example, WSUS can patch Windows servers, while Linux VMs can easily be patched manually from the Linux console.
Dig Deeper on Virtualization security and patch management
Related Q&A from Stephen J. Bigelow
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading
ALM and SDLC both cover much of the same ground, such as development, testing and deployment. Where these lifecycle concepts differ is the scope of ... Continue Reading
Eliciting performance requirements from business end users necessitates a clearly defined scope and the right set of questions. Expert Mary Gorman ... Continue Reading