Getty Images/iStockphoto
5 best practices for VM patch management
'Patching is my favorite!' said no IT admin, ever. Reduce the headache by patching everything -- even the hard-to-reach components -- and testing patches before rollout.
There's more to patch management than enabling automatic updates -- you can't just set it and forget it.
That approach might work for a while, but it's only a matter of time before an automatic update introduces a problem with your virtualization infrastructure. Your organization must take a formal and methodical approach to patch management that covers all the bases.
Patch management in virtualized environments is often centered on VMs and the software that runs on them, but host servers and supporting infrastructure need patching, too.
Include supporting components
In some organizations, virtualization hosts are joined to a management domain to make the infrastructure easier to manage and secure. This domain is separate from the one where user accounts and other production resources live.
If your organization groups its virtualization hosts into a separate domain, you must patch the domain components alongside the virtualization hosts. This includes domain controllers and DNS servers, but it can also include additional components that must be addressed as part of your patching strategy.
Remember firmware updates
Virtualization host servers seldom require firmware updates, but virtual hard disks do. Storage vendors tend to release firmware updates more frequently than server vendors. Virtual hard disks typically reside on a cluster shared volume, which is normally hosted on external storage arrays. Firmware updates for virtual hard disks might address newly discovered vulnerabilities, correct bugs related to iSCSI or Fibre Channel connectivity, or optimize storage performance.
Not every automated patch management system can deploy firmware updates. You might have to use a proprietary tool from your hardware vendor to check for, download and deploy firmware updates.
Minimize disruptions
In production environments, virtualization hosts are almost always clustered. This is primarily for fault tolerance; if a cluster node fails, the VMs that run on the cluster node can fail over to healthy nodes where VMs run uninterrupted. This same architecture is also useful for patching. Patching a host server almost always requires a reboot, and cluster-aware updating architectures can migrate VMs from host to host as necessary during patching.
Even still, patching can be disruptive. Applying patches to a virtualization host isn't usually a problem because tools apply patches to the C: drive -- and VMs reside elsewhere. If the patching process happens during a busy time of the day, a host that is already stretched thin might have further diminished performance if it must absorb VMs from a host that is being patched. Plan to apply patches during off-peak hours to mitigate this issue.
Consider multiple patch management tools
You might need more than one patch management tool. For example, a patch management tool that works for Hyper-V hosts won't necessarily work for vSphere hosts. Similarly, VMs that live in AWS, Azure or Google clouds don't require host-level patching because the cloud provider handles it.
You may find that there are supporting infrastructure components that require patching. Depending on what those infrastructure components are and where they reside, you might need a separate tool.
Determine a patch management workflow
Develop a formalized patch management workflow. This workflow defines the steps that will be taken within the patch management process. The patch management workflow should address the following:
- how you will discover and download new patches;
- which tools you will need to deploy patches;
- how you will test patches;
- how long the testing process should last;
- how quickly you will deploy critical patches;
- the procedure for rolling back a problematic patch; and
- who is responsible for the patch management process.
Test your patches
Test the patches that you plan to apply to your virtualization hosts. One way to do this is to create a small test/dev environment that is configured to mimic production. This environment helps you run test/dev workloads and patch testing to ensure patch updates don't disrupt online infrastructure.
