On Thu, Apr 11, 2019 at 13:49:03 +0200, Michal Privoznik wrote: > On 4/11/19 12:19 PM, Peter Krempa wrote: > > On Thu, Apr 11, 2019 at 11:58:04 +0200, Michal Privoznik wrote: > > > On 4/11/19 10:39 AM, Peter Krempa wrote: > > > > On Thu, Apr 11, 2019 at 10:25:11 +0200, Michal Privoznik wrote: [...] > > If you are upgrading the capabilities parsed from the status XML won't > > have the bit representing the presence of the query command. This means > > that new libvirt would still attempt the suspend ignoring whether it is > > supported or not. I don't think it makes sense to re-detect presence of > > stuff which was done prior to upgrading. > > Well, then mere upgrade of libvirt won't fix this bug for you. You'd have to > restart the domain to make this bug go away. That is true. On the other hand a "mere" upgrade of libvirt will help in this case only if you start a VM with qemu-4.0.0 or newer (unreleased). With libvirt 5.2 or older and then upgrade to a new libvirtd. Older qemus can't be fixed as they don't support the command and starting with newer libvirt would not have the problem even if we cache the presence of query-current machine. Said that I find it perfectly acceptable to call query-current-machine unconditionally in qemuDomainPMSuspendForDuration, I just don't see a problem in caching presence of query-current-machine.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
