Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy

[Stefan Hajnoczi]

On Wed, Feb 23, 2011 at 3:31 PM, Avi Kivity <address@hidden> wrote:
> On 02/23/2011 04:35 PM, Anthony Liguori wrote:
>>
>> QEMU uses the state database to store information that is created
>> dynamically.  For instance, devices added through device_add.  A device
>> added via -device wouldn't necessary get added to the state database.
>>
>> Practically speaking, it let's you invoke QEMU with a fixed command line,
>> while still using the monitor to make changes that would otherwise require
>> the command line being updated.
>
> Then the invoker quickly loses track of what the actual state is.  It can't
> just remember which commands it issued (presumably in response to the user
> updating user visible state).  It has to parse the stateful config file qemu
> outputs.  But at which points should it parse it?
>
> I don't think it's reasonable to have three different ways to interact with
> qemu, all needed: the command line, reading and writing the stateful config
> file, and the monitor.  I'd rather push for starting qemu with a blank guest
> and assembling (cold-plugging) all the hardware via the monitor before
> starting the guest.

This is why I asked about unifying the stateful config with qdev or
QemuOpts in the machine init mailing list thread.  If we have n
different ways of toggling things inside QEMU including command-line,
HMP, QMP, and stateful config, then a large chunk of QEMU is just
going to be parsing and formatting these external interfaces.

Stefan