Bug 970761 - libvirt should minimize use of drive_del
libvirt should minimize use of drive_del
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-04 15:32 EDT by Eric Blake
Modified: 2015-03-18 03:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-18 03:33:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Blake 2013-06-04 15:32:08 EDT
Description of problem:
Libvirt uses qemu's drive_del command in too many cases.  See
https://lists.gnu.org/archive/html/qemu-devel/2013-06/msg00520.html
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):
v1.0.6

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:
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

Additional info:
Comment 1 Markus Armbruster 2013-06-05 03:02:36 EDT
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.
Comment 2 Ján Tomko 2015-03-18 03:33:17 EDT
commit 0635785b6e97a8a6ac818d9711633043f895f659
Author:     Jiri Denemark <jdenemar@redhat.com>
AuthorDate: 2014-05-27 12:09:09 +0200
Commit:     Jiri Denemark <jdenemar@redhat.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 <jdenemar@redhat.com>

git describe: v1.2.5-32-g0635785 contains: v1.2.6-rc1~210

Note You need to log in before you can comment on or make changes to this bug.