Re: [Qemu-devel] QMP, HMP: introduce 'writeconfig' command

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Vadim Galitsyn (address@hidden) wrote:
>> Hi Guys,
>> 
>> This thread is a continuation of discussion started in
>> http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg03182.html.
>> 
>> This series introduces ‘writeconfig’ command support for QMP and HMP
>> monitors. This functionality might be useful for live migration for
>> cases when guest configuration was modified in runtime (for example
>> as a result of hot- plug/unplug operations) and actual Qemu command
>> line no longer reflects setup exposed to guest.
>> 
>> Original series has ‘qemu_opts’ patch as well
>> (http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg03183.html)
>> because HMP’s ‘object_add’ result was not reflected in ‘writeconfig’
>> output. Later I found that QMP’s ‘object-add’ has the same
>> issue. Anyway, I don’t include ‘qemu_opts’ patches here because
>> Markus mentioned (here
>> http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg03476.html)
>> that this functionality is going to be reworked in some future and
>> such patches might collide with the rework process.

This is item 1 of my reply.  Item 3 is more important:

   The accuracy of QemuOpts information is doubtful.

   Completeness: only certain kinds of configuration are done with
   QemuOpts.  Incompleteness makes -writeconfig less useful than it
   could be, but it's still useful.  Monitor command writeconfig could
   be similarly useful.

   Correctness: configuration gets stored in QemuOpts when we parse
   KEY=VALUE,... strings.  It can also be constructed and updated
   manually.  At certain points in time, bits from QemuOpts are used to
   actually configure stuff.

   Example: -device creates an entry in the "device" configuration
   group, which is later used to actually create and configure a device
   object.

   My point is: whenever we manipulate the actual objects, we may
   invalidate information stored in QemuOpts.  We can try to keep it in
   sync, and we do at least sometimes.  But this is a game we can only
   lose, except for the period(s) of time where QemuOpts is all there
   is, i.e. before actual objects get created.  Note that -writeconfig
   runs before objects get created, so it's not affected by this issue.

   Out-of-sync QemuOpts is harmless unless something relies on it being
   accurate.  I know we currently rely on QemuOpts IDs to catch
   duplicate IDs for some of the configuration groups.  I doubt there's
   much else.

   If we add your monitor command, out-of-sync QemuOpts goes from
   harmless to serious bug.  In other words, we'd create a new class of
   bugs, with an unknown number of existing instances that are probably
   hard to find and fix.  Probably a perpetual source of new instances,
   too.

   Feels like a show stopper to me.

Message-ID: <address@hidden>

>> Markus, could you please post if you have an update on this topic?
>> Current ‘master’ branch (9993c82dc2f5ce58b41d708b765e1a717ad4281d)
>> still has the issue.

There's my "[RFC PATCH 00/32] Command line QAPIfication"
Message-Id: <address@hidden>
https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg00209.html

There's also my KVM Forum presentation.  Permanent links to slides and
hopefully video should appear at
http://www.linux-kvm.org/page/KVM_Forum_2017 "soon".  Until then, you
can also get my slides from
https://events.linuxfoundation.org/sites/events/files/slides/armbru-qapi-cmdline_1.pdf

>> Also, Markus mentioned that once configuration was changed during
>> live migration -- it might be an issue because ‘writeconfig’ data
>> became outdated (and might be make sense to think about to embed this
>> data into migration stream itself). In the same time David said that
>> this is another problem which is unrelated to this patch series. What
>> is your current opinion on this topic? Can we consider these patches
>> to be included into ‘master’ taking into account that not all
>> configuration is dumped by ‘writeconfig’ (‘object_add’ problem), but
>> this can be fixed later?
>
> I don't see anything wrong with having a 'writeconfig' command - we
> already have the command line equivalent - that is assuming hotplug
> etc all cause the values written to be correct.

In the current state of things, this assumption is somewhere between
reckless and wrong.  See "this is a game we can only lose" above.

> The data becoming outdated doesn't sound like a big issue to me;
> it's the management layer that's doing any hotplugs, it can reissue
> another 'writeconfig' command.

It can, but how would it use the data?  It already started the
destination QEMU with configuration derived from the first writeconfig,
plus -incoming.  Source configuration may change until we're ready to
pivot from to the destination.  A second writeconfig only tells the
management application what configuration it has to reach on the
destination, but not how it could be done.  Perhaps that helps, perhaps
it doesn't.

All theoretical, because the data cannot be relied on anyway.