Suggestions for patching Hyper-V
I am looking for advice on how to best patch my Hyper-v hosts and guests. I am currently setting up 2 different patch automatons, one for the hosts and one for the guests. The hosts run first on a Saturday and the guests run next on the following Sunday. My fear is that if I do them together in one automation that the host could reboot prior to a guest completing the patching process rendering the guest unbootable. Am I thinking to much into this? Any suggestions would be welcomed and appreciated.
Comments
-
@ppryor Your concerns are valid. For safety, it's good practice to stagger your updates for Hyper-V hosts and guest systems. Cluster-Aware Updating can be helpful if you're using a failover cluster. Always ensure to have backups if something goes go wrong. Then you can at least fall back to that. I would run image backups on Friday night before the updates. That way, come Monday, if there is an issue, you can revert to the backups taken after hours on Friday. (If work is not performed over the weekend, of course. If so, then take backups just before the updates.)
3 -
As @tanderson says, always have a backup! But you may not need to worry about this all that much. When a Hyper-V host restarts, it will suspend all running VMs before going down. Even if those VMs are in the process of installing updates themselves, the suspension will pause all VM activity, write memory to disk, then perform a restart of itself. When the host comes back up it will resume the VMs and they can carry on with whatever they were doing.
For most services, this isn't a big issue. However, I would not recommend you do this is with transactionally sensitive applications, like databases or Active Directory. If your Hyper-V host runs an AD GC DC in a VM, you probably want to make sure it shuts down and doesn't get suspended. Suspending a DC can lead to AD getting mixed up with future replication and increment values coming from client machines or partner DCs.
All that said - I think what you're currently doing is just fine! I actually use 1 patch management task which does not reboot. This task runs weekly for servers. Then I have multiple tasks that reboot at various times. A reboot task is added to a folder in Atera and all endpoints are sorted into folders (like workstations or servers). For special purpose endpoints like a Hyper-V host, the desired reboot task is applied just to that endpoint. I find this gives me more control over the update and reboot schedules while still allowing things to be automated.
4 -
1
Topics
- All Topics
- 40 Getting started
- 24 Read before posting
- 8 Meet and greet
- 219 General
- 59 News and announcements
- Swag
- 1 Roadmap updates
- 68 Resources
- 9 Knowledge Base
- 13 Webinars
- 1 Shared Script Library
- 2 Blog
- 15 Pro Tips
- 26 Got an idea?
- 1 Atera Academy
- 1 ActionAI
- 1 Copilot
- 123 Remote Monitoring and Management
- 77 Remote Monitoring
- 23 Patch Management
- 98 Professional Services Automation
- 61 Helpdesk
- 17 Billing
- 18 Reporting
- 33 Integrations & add-ons
- 19 Integrations
- 10 Add-ons
- 99 Scripting and automations
- 58 Scripts
- 29 Automations