Bug 970761

Summary:	libvirt should minimize use of drive_del
Product:	[Community] Virtualization Tools	Reporter:	Eric Blake <eblake>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	armbru, jtomko, rbalakri, shyu
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-18 07:33:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Eric Blake 2013-06-04 19:32:08 UTC

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 07:02:36 UTC

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 07:33:17 UTC

commit 0635785b6e97a8a6ac818d9711633043f895f659
Author:     Jiri Denemark <jdenemar>
AuthorDate: 2014-05-27 12:09:09 +0200
Commit:     Jiri Denemark <jdenemar>
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>

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