[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/2] add writeconfig command on monitor
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH 0/2] add writeconfig command on monitor |
Date: |
Thu, 16 Feb 2017 10:23:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
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.
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.