From: Markus Armbruster <armbru@redhat.com>
References: <1370271492-5259-1-git-send-email-stefanha@redhat.com>
	<87ppw1rfw8.fsf@blackfin.pond.sub.org> <51AE1E3B.9030006@redhat.com>
	<87fvwxllwo.fsf@blackfin.pond.sub.org> <51AE40E0.2010401@redhat.com>
Date: Wed, 05 Jun 2013 09:09:00 +0200
In-Reply-To: <51AE40E0.2010401@redhat.com> (Eric Blake's message of "Tue, 04
	Jun 2013 13:32:48 -0600")
Message-ID: <878v2pavar.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH] blockdev: reset werror/rerror on drive_del
To: Eric Blake <eblake@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>, dron@redhat.com

Eric Blake <eblake@redhat.com> writes:

> On 06/04/2013 01:24 PM, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> 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.