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.
1.
http://thread.gmane.org/gmane.comp.emulators.qemu/84745
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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org