"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * Vadim Galitsyn (vadim.galit...@profitbricks.com) 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: <87k28qlca9....@dusky.pond.sub.org> >> 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: <20171002152552.27999-1-arm...@redhat.com> 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.
