Re: Making QEMU easier for management tools and applications

[Markus Armbruster]

Daniel P. Berrangé <address@hidden> writes:

> On Wed, Jan 15, 2020 at 01:15:17PM +0100, Markus Armbruster wrote:
>> Christophe de Dinechin <address@hidden> writes:
>> 
>> > Thanks a bunch. This clarifies a number of my misconceptions about
>> > how this is currently used. Most notably this one:
>> >
>> >> On 15 Jan 2020, at 10:20, Markus Armbruster <address@hidden> wrote:
>> >> 
>> >>> We don’t want the QAPI to let arbitrary fields of a QOM object
>> >>> be modified, do we?
>> >> 
>> >> We already do: QMP command qom-set.  If it breaks your guest, you get to
>> >> keep the pieces.
>> >
>> > Ouch. I certainly did not expect that.
>> >
>> > "It is not what you don’t know that kills you, it is what you know that 
>> > ain’t so".
>> 
>> Do we have a legitimate use for qom-set right now?  Hmm, let's check
>> libvirt... aha:
>> 
>> * qemuMonitorJSONSetMemoryStatsPeriod() uses it to control
>>   virtio-balloon's guest-stats-polling-interval property, in accordance
>>   with docs/virtio-balloon-stats.txt.
>> 
>> * qemuMonitorJSONSetIOThread() uses it to control iothread's properties
>>   poll-max-ns, poll-grow, poll-shrink.  Their use with -object is
>>   documented (in qemu-options.hx), their use with qom-set is not.
>> 
>> Oh well.
>
> Libvirt is of course happy to switch to something else instead of
> qom-set for these features if QEMU wants to provide a safer
> alternative.

Noted.

libvirt's use of qom-set is okay.  What's not okay is the near-complete
lack of QOM documentation, its poor QMP interface, in part due to
non-integration with QAPI, and last but not least the lack of QOM
leadership leaving it adrift.