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).
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
