Re: [Qemu-devel] Proposal for extensions of block job commands in QEMU 1.2

[Paolo Bonzini]

Il 21/05/2012 15:07, Kevin Wolf ha scritto:
> Am 21.05.2012 13:02, schrieb Paolo Bonzini:
>> Il 21/05/2012 12:32, Kevin Wolf ha scritto:
>>> Am 21.05.2012 12:02, schrieb Paolo Bonzini:
>>>> Il 21/05/2012 11:29, Kevin Wolf ha scritto:
>>> If source/target is really the distinction we want to have, should the
>>> available options be specific to the job type, so that you could have
>>> src_error and dst_error for mirroring?
>>
>> Yes, that would make sense.
> 
> Of course, at the same time it also makes the implementation a bit more
> complicated.

Not much, I'd have rerror/werror already split if I followed my spec.

>>> Management doesn't necessarily exist.
>>
>> Even a human sitting at a console is management.  (Though I don't plan
>> HMP to expose rerror/werror; so you can assume in some sense that
>> management exists).
> 
> But it's management that cares about good defaults. :-)
> 
> Why not expose the options in HMP?

Honestly, because it's a pain.  HMP doesn't have options with arguments,
and I don't really care if HMP users curse at me because they end
out-of-disk-space and their migration is dropped.  If you're using HMP,
more than likely: 1) you can just stop the VM and copy the storage
manually; 2) even if you can't, if you get an EIO you can just stop the
VM and figure the root cause.

As far as storage migration is concerned (and quite a few other
scenarios) HMP is a nice debugging tool, nothing more.

>>>> Management may want to keep the VM stopped even for an error on the
>>>> target, as long as mirroring has finished the initial synchronization
>>>> step.  The VM can perform large amounts of I/O while the job is paused,
>>>> and then completing the job can take a large amount of time.
>>>
>>> If management wants to limit the impact of this, it can decide to
>>> explicitly stop the VM when it receives the error event.
>>
>> That can be too late.
>>
>> Eric, is it a problem for libvirt if a pause or target error during
>> mirroring causes the job to exit steady state?  That means that after a
>> target error the offset can go back from 100% to <100%.
> 
> "too late" in what respect?

Too late to properly show the error... though actually there is no
guarantee that the VM will not clobber the error even with vm_stop, so
it doesn't make a big difference in that, too.

>> So for now I'll keep my proposed extension of query-block-jobs; later it
>> can be modified so that the target will have a name if you started the
>> mirroring with blockdev_mirror instead of drive_mirror.
> 
> You mean the same QMP field is a string when the block device was added
> with blockdev_add and a dict when it was added with drive_add?
> Maintaining this sounds like a nightmare to me.

No, the same QMP field is a dict.  With blockdev_add it will have a
name, and it will just be a shortcut to info block/info blockstat.  With
drive_add it will have no name.

Paolo