On 11/12/2010 11:23 AM, Ryan Harper wrote:
Currently libvirt doesn't confirm whether the guest has responded to the disk removal request. In some cases this can leave the guest with continued access to the device while the mgmt layer believes that it has been removed. With a recent qemu monitor command[1] we can deterministically revoke a guests access to the disk (on the QEMU side) to ensure no futher access is permitted.
s/futher/further/
This patch adds support for the drive_del() command and introduces it in the disk removal paths. If the guest is running in a QEMU without this command we currently explicitly check for unknown command/CommandNotFound and log the issue.
If QEMU supports the command we issue the drive_del command after we attempt to remove the device. The guest may respond and remove the block device before we get to attempt to call drive_del. In that case, we explicitly check for 'Device not found' from the monitor indicating that the target drive was auto-deleted upon guest responds to the device removal notification.
It looks like this one has gone in upstream to qemu. Is there anything else that would/should force us to delay putting this into libvirt?
src/qemu/qemu_driver.c | 28 +++++++++++++++++++++ src/qemu/qemu_monitor.c | 19 ++++++++++++++ src/qemu/qemu_monitor.h | 3 ++ src/qemu/qemu_monitor_json.c | 38 +++++++++++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 3 ++ src/qemu/qemu_monitor_text.c | 54 ++++++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_monitor_text.h | 3 ++ 7 files changed, 148 insertions(+), 0 deletions(-)
At any rate, the code looks okay to me, so once we decide that it is safe to apply, you have my: ACK -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org