How To… Patch Hyper-V Virtual Machines and Host

Hyper-V is Microsoft’s answer to hardware virtualization, so that you can run virtual machines complete with an operating system, applications and programs, each in its own isolated environment. Ongoing maintenance is necessary for performance and security, but patching Hyper-V is not without its complexities! Let’s take a look at how people use Hyper-V, and what you can do to stay up to date with patch management on guest and host environments.

What Do Organizations Use Hyper-V Virtual Machines for?

Hyper-V VMs are used for creating or growing your private cloud environment. You can use shared resources to create a really flexible service and scale it as you need with exactly the right utilization for your demand. On the hardware side, you can then reduce the number of servers and workloads you need, (as Hyper-V offers more power and control) getting more with less. No need to buy and maintain hardware in the physical sense – let Microsoft do that on your behalf, and just focus on what you’re using the VM to achieve.

Many organizations use Hyper-V for creating Virtual Desktop Infrastructure, with Hyper-V and RD Virtualization on the same server. When set up this way, personal virtual desktops can be used by all of your end users, and as an MSP for example, you have greater visibility, agility, security and compliance.

Patching Hyper-V Host and Guest VMs

If you’re working in IT, you already know the term “Patch Tuesday”, signalling the second Tuesday in the month where Microsoft (and many other tech giants) release their patches. On your end, the importance of patch management probably doesn’t need explaining to you – keeping systems at good performance and safe from cyberattacks.

Of course, any patching schedule needs to take into account the likelihood of system performance or downtime for your clients or end users. In terms of Hyper-V, when you apply a patch, you shouldn’t experience any services or apps being taken offline, other than during the reboot portion of the patching process. However, if you patch the management operation system, this could impact the performance of your virtual machines, especially if you have heavy resource utilization like disk activity.

How the guest VMs are handled will relate to whether they are HA (highly-available). If they are highly available, these will be automatically handled by the cluster service before the Hyper-V host shuts down. These are then migrated when the host reboot is done. If your guest VMs are not HA, then the local system will decide what happens to them, for example saving the state, and then following the automatic start action which has been pre-set.

Options for Patching Hyper-V

When you’re thinking about patch management, you really need to strike a balance between manually patching everything, which takes an excessive amount of time, and places the system at a great deal of risk due to technician mistakes and gaps, and automatically patching as soon as a patch is available, which can put you at risk of faulty patches making it into your environment.

One way to manage this balance is to create a delay, whether that’s using a test environment which replicates your production environment, or updating a small section first before rolling patches out across all of your environment. You can also set up patching automation to check patches and then deploy them at a set date, for example critical patches immediately, and less critical patches at a scheduled time within a week or two.

Patching Guests vs Patching Hosts

There is a difference between the approach for patching hosts and guests in the world of virtual machines. While the guests will run on the virtual machines, and be pretty straightforward to patch (think of them like any other physical system in your patching routine) – it can be more complicated to patch the host, which runs on the hardware directly. As a result, any downtime that the host experiences will impact the guest VMs, too.

First, ask yourself what your Auto Shut Down action is set to for your virtual machines. If they are all set to save, then your patching schedule won’t have any lasting impact on guest performance. When a host is taken offline due to patching, the guest will save, and then resume as normal when the host is rebooted and comes back online.

If, on the other hand, some of your guests are set to Shut Down, then you don’t want the patching schedule of the host to interfere with the guest VMs. If you can schedule the host to update one day or time, and the guests at another day or time, then this makes it less likely that a host shutdown will cause downtime to guest activity. Of course, this doubles the amount of downtime that your servers will experience, one for the host patching and one for the guest VMs. There is currently no simple way to coordinate host and guest patching to happen simultaneously which would offer a single reboot time.

Best-practices for Patching VM environments

Firstly, make sure that you are using Hyper-V Server not Windows Server, as Hyper-V does have fewer patches. Think about ways to minimize the roles and services so that patch management has less of an impact on operations. For example, where possible run anything that can be inside a guest outside of the management operating system, as this is where the patches could have a knock-on effect on guest services.

Whatever process you choose, make sure to communicate any impact of downtime on your end users. They will appreciate your transparency and feel more in control if they can choose when the downtime should occur, or be aware that you are working with their business continuity in mind.

For more information on setting up automation for patch management within the Atera platform – check out this Knowledge Base article.