Published: 03 Feb 2010
Following patch management best practices for your virtual hosts can save you from a lot of headaches and late nights in the IT department.
The first part of this two-part tip covered three server patch management best practices for virtual hosts: finding the latest patches, coordinating patches and decreasing the hypervisor's footprint. Part two covers three additional patch management best practices to keep your virtual hosts running smoothly and securely.
Server patch management strategy No. 4: Implementing a clustered environment
The live migration functionality was not designed specifically for patch management. But it aids greatly with the ability to move VM workloads seamlessly to other virtual cluster nodes when updating an evacuated host. Moving VMs from host to host within a cluster until all nodes are patched is a great improvement over running standalone hosts, which require saving or shutting down VMs to patch and reboot a host.
My wife loves this feature, but she just doesn't know it. It allows me to get to bed at a reasonable time because the patching process doesn't have to happen in the middle of the night.
Note: Patches that modify the hypervisor version may have special requirements in regards to your VMs. Some require a shutdown of every VM before you can fail VMs to unpatched nodes.
Server patch management strategy No. 5: Creating service levels
In my environment, there are three VM service levels:
- production VMs that reside on clustered hosts, which provide high availability and maximum uptime;
- legacy VMs on standalone hosts; and
- test/development VMs, which reside on standalone hosts.
From the standpoint of patching, clustered virtual hosts provide the best availability for VMs because they can be migrated to other nodes during the host patching process.
Because of the resource requirements in this type of high-availability environment, it makes sense that this setup is the most expensive. The other two environments that reside on standalone hosts cost less but cause more disruptions to the VMs during virtual host server restarts because VMs cannot be migrated to alternate hosts.
If your business model mandated that all VMs have to be available at all times, then you need a cluster host environment. But in most organizations, there are different service levels for various application workloads. Considering your overall business model for each VM may lead you to design your architecture around multiple service levels -- which, in turn, can reduce complexity and save your organization money.
Server patch management strategy No. 6: Accounting for business hours
Business hours are an important factor in how systems are patched, and it potentially dictates the level of complexity within a virtual host environment. If your business is a standard 9 a.m. to 5 p.m. establishment, there may be more flexibility for downtime during the off hours, when VMs can be momentarily put into a "saved state" while the virtual host system is patched and re-booted.
Having a high-availability environment can minimize the blow of hardware failures, but a sense of security can be fulfilled with less expensive spare hardware instead of adding the complexity of clustering and a shared-storage infrastructure.
A 24/7 infrastructure is on the other end of the spectrum and requires a more complex environment. Still, some workloads could go on less robust hardware and storage infrastructures and be interrupted for short periods of time. Again, knowing your business model and profiling your VMs to particular host types can make patching a virtual host server much easier.
Also remember that patches can come from any number of software products. Supporting software -- such as host backup agents, drivers and firmware, as well as management, monitoring and antivirus software -- may result in the need to restart virtual hosts from time to time.
Your design objective should be to follow server patch management best practices with as few disruptions to your most critical VMs. Being proactive, setting service-level expectations with customers and reserving regular downtime will define how long and when VM workloads can be disrupted.
There are so many unexpected aspects to working with technology, but the need to patch your virtual host servers should not be one of them. Some patches require virtual hosts to go down. And if you ignore server patch management best practices, it's just a matter of time before you experience significant downtime.
Have you encountered any virtual host server nightmares from not patching or a patch snafu ? My horror story involved rebuilding half my virtual cluster nodes. So what's yours? Send along your experiences and add to the conversation.
About the expert
Rob McShinsky is a senior systems engineer at Dartmouth Hitchcock Medical Center in Lebanon, N.H., and has more than 12 years of experience in the industry -- including a focus on server virtualization since 2004. He has been closely involved with Microsoft as an early adopter of Hyper-V and System Center Virtual Machine Manager 2008, as well as a customer reference. In addition, he blogs at VirtuallyAware.com, writing tips and documenting experiences with various virtualization products.