Heinz Graalfs <[email protected]> writes: > Hi Kevin, > > doing a > > virsh detach-device ... > > ends up in the following QEMU monitor commands: > > 1. device_del ... > 2. drive_del ... > > qmp_device_del() performs the device unplug path. > In case of a block device do_drive_del() tries to > prevent further IO against the host device. > > However, bdrv_find() during drive_del() results in > an error, because the device is already gone. Due to > this error all the bdrv_xxx calls to quiesce the block > driver as well as all other processing is skipped. > > Is the sequence that libvirt triggers OK? > Shouldn't drive_del be executed first?
No. drive_del is nasty. Its purpose is to revoke access to an image even when the guest refuses to cooperate. To the guest, this looks like hardware failure. If you drive_del before device_del, even a perfectly well-behaved guest guest is exposed to a terminally broken device between drive_del and completion of unplug. Always try a device_del first, and only if that does not complete within reasonable time, and you absolutely must revoke access to the image, then whack it over the head with drive_del.
