Mastering Windows Server 2016 Hyper-V

via Group Policy is one option, but there are other enterprise solutions. System Center
Configuration Manager, for example, leverages WSUS to ascertain that patches are
available but then allows them to be packaged and targeted to different groups of
servers at specific times with granular tracking and reporting.

Patching Hyper-V Clusters

The technologies I’ve been talking about are not specific to Hyper-V, which is logical
since Hyper-V is a role within Windows Server and therefore its patch mechanisms
are the same as for any other Windows Server machine. The good news is that the
same patch deployment solution can be used for the Hyper-V hosts and for the virtual
machines running Windows Server. There are, however, some solutions specific to
Hyper-V patching and specific to patching clusters.

IF  YOU CARE    ABOUT   VM  AVAILABILITY,   DON’T   USE STAND-

ALONE   HYPER-V HOSTS

As  I   have    already mentioned,  there   are not really  any special solutions   to  patch   a

stand-alone Hyper-V host.   If  you are deploying   stand-alone Hyper-V hosts,  you

don’t   really  care    about   the availability    of  the virtual machines,   so  there   are no

special technologies    in-box  to  patch   stand-alone hosts   and use Shared  Nothing

Live    Migration   to  move    VMs prior   to  the reboot  and bring   the VMs back.   If  you

had that    hardware    available,  you would   have    clustered   them    already,    considering

an  SMB 3   file    share   can be  used    for the storage if  a   SAN is  not available;  you could

even    use a   clustered   external    storage enclosure   connected   to  both    hosts   and

clustered   storage spaces  to  provide shared  access, or  for Windows Server  2016,

use Storage Spaces  Direct  to  take    advantage   of  local   storage in  each    node.   The

only    time    you should  have    an  unclustered Hyper-V host    is  if  you have    a   location

with    only    one Hyper-V server.

Consider a clustered Hyper-V environment with shared storage either through a SAN,
SMB share, clustered Storage Spaces, or Storage Spaces Direct, and the ability to move
virtual machines between hosts. In your Hyper-V environment, you are already using
Server Core or maybe Nano Server to minimize the number of patches that are
applicable and therefore reducing the number of reboots. However, reboots will still
be required for patching and other purposes. Utilizing the ability to move virtual
machines between nodes with no downtime using Live Migration prior to reboots
makes the impact of a Hyper-V node reboot in a cluster zero for the virtual machines.
This means no loss of availability for the virtual machines, and only some minor
administrative effort. This is why, when you hear people hung up on having to patch
Hyper-V, it’s generally overblown as a real issue. Yes, you might need to patch, and at
times you might need to reboot, but it has no impact on the availability of the virtual
machines, which is what you care about in a virtual environment. The ideal process in
a clustered environment is as follows: