[libvirt] [Qemu-devel] [PATCH v7 1/3] qmp: adding 'wakeup-suspend-support' in query-target

Markus Armbruster armbru at redhat.com
Wed Jun 20 07:09:00 UTC 2018


Daniel Henrique Barboza <danielhb at linux.ibm.com> writes:

> Hi,
>
> Sorry for the delay. I'll summarize what I've understood from the discussion
> so far:
>
> - query-target is the wrong place for this flag. query-machines is
> (less) wrong
> because it is not a static property of the machine object
>
> - a new "query-current-machine" can be created to host these dynamic
> properties that belongs to the current instance of the VM
>
> - there are machines in which the suspend support may vary with a
> "-no-acpi" option that would disable both the suspend and wake-up
> support. In this case, I see no problem into counting this flag into
> the logic (assuming it is possible, of course) and setting it as "false"
> if there is -no-acpi present (or even making the API returning "yes",
> "no" or "acpi" like Markus suggested) somewhere.
>
>
> Based on the last email from Eduardo, apparently there is a handful
> of other machine properties that can be hosted in either this new
> query-current-machine API or query-machines. I believe that this is
> more of a long term goal, but this new query-current-machine API
> would be a good kick-off and we should go for it.
>
> Is this a fair understanding? Did I miss something?

Sounds fair to me.

Adding query-current-machine on the evidence of just one flag would be
questionable, but Eduardo expects there to be more, so it's okay.

Whether a property is static or dynamic can change over time, which
makes the choice of query-machines vs. query-current-machine
non-trivial.  We better write down how we plan to handle mispredictions,
i.e. what to do when a property we put into query-machines turns out to
be dynamic, or a property we put into query-current-machine turns out to
be static, or we'd like query-machines to cover a property that is
static except for a few machines.

Eduardo, anything to add?




More information about the libvir-list mailing list