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 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.
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.