Red Hat Bugzilla – Bug 970761
libvirt should minimize use of drive_del
Last modified: 2015-03-18 03:33:17 EDT
Description of problem:
Libvirt uses qemu's drive_del command in too many cases. See
for some of the negative results that can happen in a guest when we rip out a hard drive from under the guest rather than waiting for clean removal.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
libvirt should wait to call drive_del until after device_del has received feedback from qemu that the guest has reacted, rather than ripping it out right away
Inconsistency alert: destroying a device model (e.g. successful
device_del) automatically destroys any block backends ("drives") still
connected to it. This is *not* the case for other kinds of backends.
Why? Lack of adult supervision, I guess. Can't be changed now.
It can (and in my opinion should) be changed for block backends
created by a future replacement of -drive and drive_add.
Sane uses for drive_del:
* Violently revoke a guest's access to a drive when peaceful methods
failed. Typical example: device_del doesn't complete within a
reasonable time, say because the guest doesn't honor ACPI unplug.
* Delete a drive that is not connected to a device model. Currently,
a drive can only be unconnected when it has never been connected.
In the future, we might have ways to disconnect.
I'm quite suspicious of other uses.
Author: Jiri Denemark <firstname.lastname@example.org>
AuthorDate: 2014-05-27 12:09:09 +0200
Commit: Jiri Denemark <email@example.com>
CommitDate: 2014-06-03 10:58:06 +0200
qemu: Remove disk backend only after frontend is gone
In general, we should only remove a backend after seeing DEVICE_DELETED
event for a corresponding frontend. This doesn't make any difference for
disks attached using -drive or drive_add since QEMU automatically
removes their backends but it's still better to make our code
consistent. And it may start making difference in case we switch to
attaching disks using -blockdev.
Signed-off-by: Jiri Denemark <firstname.lastname@example.org>
git describe: v1.2.5-32-g0635785 contains: v1.2.6-rc1~210