Re: [Qemu-devel] [PATCH] blockdev: reset werror/rerror on drive_del

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> On 06/04/2013 01:24 PM, Markus Armbruster wrote:
>> Paolo Bonzini <address@hidden> writes:
>> 
>>> Il 04/06/2013 18:37, Markus Armbruster ha scritto:
>>>> I figure the bit that can't be resolved now is letting the user switch
>>>> off "stop on error" safely before a drive_del.  Even if we had a command
>>>> for that, there'd still be a window between that command's execution and
>>>> drive_del's.  Your patch solves the problem by having drive_del switch
>>>> it off unconditionally.  Oookay, but please document it, because it's
>>>> not exactly obvious.
>>>
>>> It is not obvious, but it is not surprising either when you see it (i.e.
>>> you won't really be surprised by the errors in the guest and won't need
>>> to know that, under the hood, rerror has been changed from the value you
>>> specified).
>>>
>
>> This is drive_add's documentation in hmp-commands.hx:
>> 
>>     Remove host block device.  The result is that guest generated IO is
>>     no longer submitted against the host device underlying the disk.
>>     Once a drive has been deleted, the QEMU Block layer returns -EIO
>>     which results in IO errors in the guest for applications that are
>>     reading/writing to the device.
>> 
>> Suggest to add:
>> 
>>     These errors are always reported to the guest, regardless of the
>>     drive's error actions (drive options rerror, werror).
>> 
>> Independently, libvirt needs fixing.
>
> Total agreement that libvirt needs to use a saner disk hot-unplug
> sequence when it is known that qemu provides one.  I've filed
> https://bugzilla.redhat.com/show_bug.cgi?id=970761
> to remind us to fix libvirt.

Sane sequence

1. device_del

2. Wait for DEVICE_DELETED

3. if timeout, drive_del

Might make sense to offer a choice in the API between "fail" and
"destroy the block device" if guest doesn't cooperate.