Comment # 17 on bug 1174365 from James Fehlig

(In reply to Klaus Mueller from comment #16)
> The question here is: who or what (and how) informs a running libvirtd
> (completely outside of the defined shutdown process of systemd) about the
> shutdown of the host, which in turn suspends the VMs belonging to this
> libvirtd instance? And why can't this be disabled?

Yes, who is asking libvirtd to suspend the VMs is the key question. AFAIK, the
libvirt-guests service is the only thing that will suspend VMs on host
shutdown. It is disabled by default, and you also verified it was disabled on
your system. And FYI, libvirt-guests default action is to shutdown running VMs
at host shutdown, not suspend them.

Maybe we can get an idea about who is asking libvirtd to suspend the VMs by
enabling debug logging in the remote driver and API. E.g. a log_filters in
libvirtd.conf along the lines of

log_filters="1:remote 1:libvirt"

> BTW: If the VM contains a passed through PCIe card (something like a PCIe
> network card), e.g., the suspend isn't executed (it gives an error), because
> VMs containing passed through devices can't be suspended - those VMs are
> therefore always processed via the subsequent service definition and not
> before!

Right. VMs with physical hardware passed through cannot be suspended (aka
saved) or migrated.

> Another bad thing (that's maybe the primary point, why it is a problem to
> suspend VMs at all): If the suspended VM is restarted again, the VM proceeds
> with the wrong time (it is the time it has been shutdown). I found no way to
> fix the time on resume.

Yeah, that's a classic problem with save/restore. NTP in the guest helps to
some extent. If the guest has been suspended for long periods of time, 'virsh
domtime ...' or the qemu guest agent 'guest-set-time' command can be used to
correct the  guest's clock

https://qemu.readthedocs.io/en/latest/interop/qemu-ga-ref.html#qapidoc-19