http://bugzilla.opensuse.org/show_bug.cgi?id=1174365
http://bugzilla.opensuse.org/show_bug.cgi?id=1174365#c17
--- Comment #17 from James Fehlig
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 -- You are receiving this mail because: You are on the CC list for the bug.