Patch Planning and Implementation
In the previous chapter, I talked about some key processes and actions that you must
take on your Windows Server 2016 Hyper-V servers. One of them was patching, and in
this section, I dive into some additional detail, consider some options, and cover some
other factors that need to be considered in your patch solution planning.
In a virtual environment, there are at least two workloads that you have to consider
patching:
The Hyper-V host itself. The hypervisor itself would be updated via updates sent to
the host.
The virtual machines that are running on the Hyper-V hosts, including updates to
Integration Services for Hyper-V (although this should not update frequently
between versions of Hyper-V). The virtual machines may be running Windows
operating systems but also Linux. I focus on Windows updating in this discussion,
but you would also need processes to ensure that all workloads are updated.
Virtual machines that are offline for long periods of time may also need to be
patched, which can be accomplished using the same processes discussed in
Chapter 5, “Managing Hyper-V,” related to patching templates, such as using
Deployment Image Servicing and Management (DISM).I said at least two workloads because you most likely will need to ensure that items
such as the management infrastructure (for instance, System Center) are patched and
that firmware in hardware is kept up-to-date (for example, that updated drivers from
vendors are downloaded and applied). These are not considerations specific to Hyper-
V. They apply to any infrastructure, but it’s especially important to ensure that your
Hyper-V environment is patched and stable because it’s not responsible for one
operating system but instead is hosting possibly hundreds of operating systems.
If you already have a patching solution for your Windows-based servers, most likely
that same solution can be leveraged to patch your Hyper-V servers. What is important
is that patches are tested in a test environment prior to implementation in production,
and also that care be taken when applying patches that require reboots. Remember, if
the Hyper-V host reboots, then all virtual machines on the host will shut down for
stand-alone hosts or be moved to other hosts in a clustered environment. It’s
therefore important to have the ability to define specific maintenance windows for
your Hyper-V hosts, delaying reboots until that maintenance window is reached. In a
cluster environment, you would make sure that the maintenance windows are
staggered to ensure that all hosts don’t apply patches and reboot at the same time.
There are better solutions for cluster environments, though, which I touch on later in
this chapter.
If you have stand-alone Hyper-V hosts in Windows Server 2012 or above, it would be
possible to perform a Shared Nothing Live Migration of virtual machines between