On Thu, Feb 16, 2017 at 09=53=22AM +0000, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (arm...@redhat.com) wrote:
> > Eduardo Otubo <eduardo.ot...@profitbricks.com> writes:
> > > This first patch extends the command line option `-writeconfig <file>' to
> > > a
> > > command on HMP and QMP monitors. This is useful when live migrating after
> > > a
> > > series of device hot plug events. One can just generate an updated config
> > > file
> > > for the vm, transport it to the target host and start the vm with
> > > `-readconfig
> > > <file>'.
> > >
> > > The second patch re-includes the reference of the memory object on the
> > > config
> > > file generated.
> > The high-level idea of having QEMU regurgitate its configuration for the
> > migration target sounds nice, but there are several issues with
> > regurgitating QemuOpts state with writeconfig:
> > 1. Our needs have outgrown QemuOpts' design. We have accumulated
> > various hacks and work-arounds to make do, and it's still not enough.
> > Instead of adding more, I want to revise its design. The work has
> > started, but it'll take some time. Adding creative new uses of
> > QemuOpts while this work is in progress can only make it harder.
> > If this issue was the only one, I'd take the hit for the team.
Certainly this series is part of the QemuOpts refactoring, right?
[PATCH 00/24] QemuOpts util/cutils: Fix and clean up number conversions
I'm not sure what's the big picture you have in mind, but I can help you
> > 2. Transmitting configuration at the beginning of migration doesn't
> > fully solve the problem. What about configuration changes during
> > migration? Think of hot plug. Doesn't mean transmitting
> > configuration is a bad idea, only means there's more to the problem
> > than a naive observer might think.
> > In my opinion, the proper solution is to transmit configuration
> > information in the migration stream, complete with updates as it
> > changes. Hard to do, which is why it hasn't been done.
> > If we can't have the proper solution now, a less-than-ideal partial
> > solution may still be better than nothing.
> That's a separate problem from the one Eduardo is trying to solve;
> I wouldn't trust migration to survive a device hotplugged during the migration
> as it is. So I wouldn't worry about it as a reason against this series.
Can't we lock hotplug operations while a live migration is being
performed? Not exactly return an error, but perhaps delay the hotplug
until the migration is finished.
> > 3. 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.
> Hmm this does seem a bigger problem.
Yes, this looks bad. Does your QemuOpts redesign considers these
problems as well? I mean, proper work with devices and objects to
actually update QemuOpts as soon as they change, etc.