Re: [Qemu-devel] [PATCH 0/2] add writeconfig command on monitor

[Dr. David Alan Gilbert]

* Markus Armbruster (address@hidden) wrote:
> Eduardo Otubo <address@hidden> 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.
> 
> 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.

> 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.

Dave

--
Dr. David Alan Gilbert / address@hidden / Manchester, UK