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

[Markus Armbruster]

Avi Kivity <address@hidden> writes:

> On 02/23/2011 04:35 PM, Anthony Liguori wrote:
>> On 02/23/2011 07:01 AM, Avi Kivity wrote:
>>> On 02/23/2011 01:14 AM, Anthony Liguori wrote:
>>>>
>>>> -drive already ties into the qemuopts infrastructure and we have
>>>> readconfig and writeconfig.  I don't think we're missing any major
>>>> pieces to do this in a more proper fashion.
>>>
>>> The problem with qemu config files is that it splits the
>>> authoritative source of where images are stored into two.  Is it in
>>> the management tool's database or is it in qemu's config file?
>>
>> I like to use the phrase "stateful config file".  To me, it's just a
>> database for QEMU to persist data about the VM.  It's the only way
>> for QEMU to make certain transactions atomic in the face of QEMU
>> crashing.
>>
>> The user visible config file is a totally different concept.  A
>> management tool launches QEMU and tells it where to keep it's state
>> database.  The management application may prepopulate the state
>> database or it may just use an empty file.
>
> In that case the word 'config' is misleading.  To me, it implies that
> the user configures something, and qemu reads it, not something mostly
> internal to qemu.
>
> Qemu does keep state.  Currently only images, but in theory also the
> on-board NVRAM.
>
>>
>> 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.

Exactly.  And qdev has brought his within our reach.

[...]