Forum Discussion
Windows Server 2022 Hyper-V guest state not saved on host reboot
Hi again!
By any chance running a guest with FreeBSD or other OS not handling the VSS service?
I found this in the comments, solved my guest shutdown problem. Looks like this single guest mess it up for the whole Hyper-V shutdown procedure...
https://www.altaro.com/hyper-v/extending-hyper-vs-guest-grace-period-host-shutdown/
Check the comment from "Jon W September 2, 2018 at 9:29 am"
Ok i found a way to replicate the issue. If you install anything based on freebsd 11.2 on hyper-v it will log an error “freebsd kernel: hvvss0: Unknown opt from host: 4” when a shutdown or reboot of the host is initiated. It looks like windows attempts to do something with VSS before issuing a shutdown command and it is failing on the freebsd VM causing the whole vss system to fail on Hyper-v causing all the vm’s power to be pulled even Windows VM’s.
A fix for me was to disable VSS guest services and the vm’s all reboot as normal now.
(I think I've solved this once before but totally forgot about it... it was way back in 2018 also...)
This was driving me insane until I found your post. I spent hours checking my setting and doubting my abilities but in the end I feel vindicated that it wasn't "my issue".
On my Hyper-V host I have 3 Windows Server 2022, 1 PfSense (based on BSD) and 1 Open VPN Access Server (Ubuntu). PfSense was the culprit. After removing the integration service named "Backup (volume shadow copy)" the automatic stop actions started working.
The weird part for me is that it was only happening on 1 out of the 3 Windows Server 2022 VMs. I suspect it had to do with the order in which the VMs were being processed.
Thank you!
Hi!
Happy to hear you resolved the issue and regained your peace of mind!🙂
I've experienced similar behavior, in my case it was OPNsense. I've had servers where it worked too, and maybe you're onto something here. If FreeBSD is the last one "out the door," the others may have time to shut down properly. Put a lot of time into this but, as you, could not solve it.
I went as far as creating my own solution before I found out that it was FreeBSD causing this issue. I totally customized the shutdown and startup PowerShell procedure to handle what Hyper-V should do.
As figured. A much easier solution is just to disable the VSS service.
Recently, I tested again with the latest FreeBSD 14.2 (and Server 2022 and 2025), and unfortunately, the behavior is not fixed. So until it is, we'd better disable that integrated service.