On 4/11/19 8:43 AM, Peter Krempa wrote:
On Thu, Apr 11, 2019 at 13:37:49 +0200, Michal Privoznik wrote:
On 4/11/19 12:12 PM, Daniel Henrique Barboza wrote:
<snip/>
All that said, I think a good solution would be (2). dompmsuspend isn't a
performance sensitive command, thus the extra time to execute the API
can be ignored. Also, we can still check for
QEMU_CAPS_QUERY_CURRENT_MACHINE
inside qemuDomainPMSuspendForDuration to avoid firing up an error in a
QEMU version that doesn't know the API.
That's the thing. We can't. The capability doesn't exist yet. So every
domain that is currently running thinks that qemu doesn't have the
capability. And when updating libvirt to say next release only freshly
started domains might/will have the capability. For all already running
domains libvirt thinks the capability is not there. Only freshly started
domains will get the capability. IOW, upgrading libvirt won't help you
unless you restart your domains (might not want to do that).
If you just go ahead with the PM suspend in case the capability bit for
the presence of query-current-machine is not present you just will keep
the existing behaviour. I think that is perfectly tolerable.
Error should be reported only if query-current-machine is supported and
it returns false for wakeup-suspend-support. (Obviously also if our caps
indicate that query-current-machine is supported but returns an error).
I agree with this approach.
Michal, do you agree agree with this? If so, let me know if you plan
to re-spin this series again. Otherwise I can do it.
Thanks,
DHB
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
