A virtual host server houses numerous virtual machine (VM) workloads, so it's imperative to keep it secure and bug free.
It's important to design a virtual server infrastructure that can accommodate patches for virtual hosts and updates based on your business model and agreed-upon service levels. Some forward thinking translates into a high level of quality and security for your organization. This two-part tip covers how to develop a server patch management strategy for a virtual host server based on particular business models.
Server patch management strategy No. 1: Finding the latest patches
How important is a patch management strategy for virtual hosts? Microsoft and VMware Inc. have been exchanging blog barbs on this topic. (See "Hypervisor Footprint Debate Part 1" and "Hypervisor Footprint Debate Part 1 Update".) Who is correct, though, is probably a matter of perspective. The point is that virtual servers need patches quite regularly no matter which vendor you choose.
In the past, finding new virtual host server patches, or hot fixes, was confusing. Luckily, the method for finding these updates from the major virtualization vendors has gotten easier, but there is still room for improvement. Here are the main locations for virtual host server patches from the major vendors that I've found helpful:
Note: Blogs and forums are other places where professionals indicate the latest patches that can remedy a problem you may have. If you run a production virtual environment, it's important to find and stay connected to these resources.
Server patch management strategy No. 2: Patch coordination
For the most part, your patching mechanism is irrelevant. The coordination of your virtual host server patches, however, is important. Consider the following questions that need to be answered:
- Does this update need a reboot or the host?
- Do your VMs need to be in a shut down state when the patches are applied?
- Do your VMs need updated components before or after a particular patch is applied?
In my experience with Hyper-V (and this is true of most vendors), these answers can be found in a patch's release notes. Read these notes carefully, because patching virtual hosts affects more than a single server.
Luckily, the method for installing patches is usually pretty easy. The most time -consuming part is arranging the necessary downtime and preparing for potential side effects of the patches.
Server patch management strategy No. 3: Decreasing the hypervisor's footprint
Basically, Hyper-V Server is a slimmed-down version of Windows Server 2008 that lacks components such as Windows Media Player, Internet Explorer, etc. It is a specific bare install, similar to Windows Server Core, but with the functionality specific to running only the Hyper-V role.
Hyper-V Server R2 has recently added extended features (i.e., Live Migration) and, for the most part, is comparable to VMware ESXi. The benefit of these small, slimmed-down versions is their attack surfaces. Fewer components installed translate to a decreased number of patches needed for the host and, in turn, less disruption to your virtual environment.
I use Hyper-V Server R2 exclusively for my test-and-development environment. These hosts have gone months at a time without a necessary security patch. Because there are fewer components eating memory -- the one resource I always seem to fall short on -- I can provision more VMs to these hosts. There are some tradeoffs, however: less functionality in these versions and a learning curve if you are accustomed to working at the server's desktop. But this setup reduces the headaches associated with frequent patching.
In part two of this tip on patch management best practices, I discuss the roles of clustered environments, service levels and business hours on the server patch management process.
About the author:
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.