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>
Date: Tue, 04 Jun 2013 21:24:07 +0200
In-Reply-To: <51AE1E3B.9030006@redhat.com> (Paolo Bonzini's message of "Tue,
	04 Jun 2013 19:04:59 +0200")
Message-ID: <87fvwxllwo.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: Paolo Bonzini <pbonzini@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, dron@redhat.com, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

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).
>
>> Re "the guest gets the ENOMEDIUM error": depends on the device.  I doubt
>> disks can signal "no medium", and even if they could, I doubt device
>> drivers are prepared for it.
>
> SCSI disks can signal whatever they want.  Device drivers will just
> treat it as any other error (sense code) they don't recognize.

My point is: the commit message claims "the guest gets the ENOMEDIUM
error", which isn't really true.  No biggie, of course.

>> Re "this scenario actually happens sometimes during libvirt disk hot
>> unplug, where device_del is followed by drive_del": if I remember
>> correctly, libvirt disk hot unplug runs drive_del right after
>> device_del, opening a window where the guest sees a dead device.  That's
>> asking for trouble, and trouble is known to oblige.
>
> I think it's causing too much trouble though, and Stefan's patch is
> making the trouble evident to the guest.  Surprise removal is a fact of
> life, I don't think it makes sense to stop the machine on surprise
> removal.  It's very different from I/O errors.

I don't disagree with Stefan's patch, or your defense of it.

Except I'm reluctant to not document something non-obvious because "you
don't need to know" when I can document it in less time it would take me
to overcome my resistance to "you don't need to know" arguments ;)

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.