Paolo Bonzini <pbonz...@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.
