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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 02/23/2011 11:18 AM, Avi Kivity wrote:
>> On 02/23/2011 06:28 PM, Anthony Liguori wrote:
>>>
>>>>> Well specifically, it has to ask QEMU and QEMU can tell it the
>>>>> current state via a nice structured data format over QMP.  It's a
>>>>> hell of a lot easier than the management tool trying to do this
>>>>> outside of QEMU.
>>>>
>>>> So, if qemu crashes, the management tool has to start it up to
>>>> find out what the current state is.
>>>
>>> Depends on how opaque we make the state file.  I've been thinking a
>>> simple ini syntax with a well supported set of keys.  In that case,
>>> a management tool can read it without starting QEMU.
>>
>> Then the management stack has to worry about yet another way of
>> interacting via qemu.
>
> { 'StateItem': { 'key': 'str', 'value': 'str' } }
> { 'StateSection': { 'kind': 'str', 'name': 'str', 'items': [
> StateItem' ] } }
> { 'StateInfo': { 'sections': [ 'StateSection' ] } }
>
> { 'query-state', {}, {}, 'StateInfo' }
>
> A management tool never need to worry about anything other than this
> command if it so chooses.  If we have the pre-machine init mode for
> 0.16, then this can even be used to inspect state without running a
> guest.
>
> The fact that the state is visible in the filesystem is an
> implementation detail.
>
>>   I'd like to limit it to the monitor.
>>
>>>>
>>>> Doesn't the stateful non-config file becomes a failure point?  It
>>>> has to be on shared and redundant storage?
>>>
>>> It depends on what your availability model is and how frequently
>>> your management tool backs up the config.  As of right now, we have
>>> a pretty glaring reliability hole here so adding a stateful
>>> "non-config" can only improve things.
>>
>> I think the solutions I pointed out close the hole with the existing
>> interfaces.
>
> It doesn't work for eject unless you interpose an acknowledged event.
> Ultimately, this is a simple problem.  If you want reliability, we
> either need symmetric RPCs so that the device model can call (and
> wait) to the management layer to acknowledge a change or QEMU can post
> an event to the management layer, and maintain the state in a reliable
> fashion.
>
>>>
>>>> To me, it seems a lot easier to require management to replay any
>>>> commands that hadn't been acknowledged (due to management
>>>> failure), or to query qemu as to its current state (if it is
>>>> alive). 
>>>
>>> You still have the race condition around guest initiated events
>>> like eject.  Unless you have an acknowledged event from a
>>> management tool (which we can't do in QMP today) whereas you don't
>>> complete the guest initiated eject operation until management ack's
>>> it, we need to store that state ourself.
>>
>> I don't see why.
>>
>> If management crashes, it queries the eject state when it reconnects
>> to qemu.
>> If qemu crashes, the eject state is lost, but that is fine.  My
>> CD-ROM drive tray pulls itself in when the machine is started.
>
> Pick any of a number of possible events that change the machine's
> state.  We can wave our hands at some things saying they don't matter
> and do one off solutions for others, or we can just have a robust way
> of handling this consistently.

What machine state is to be preserved across crashes?  Maybe I'm naive,
but I can't think of anything but non-volatile device memory,
e.g. disks, RTC CMOS, EEPROM.

I can't quite see why we need conceptually different mechanisms for
disks and all the rest.

[...]