Eric Blake <ebl...@redhat.com> writes: > On 06/04/2013 01:24 PM, Markus Armbruster wrote: >> 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). >>> > >> 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.
