Bug 1231739 - qmp should give friendly hints when can not use __com.redhat_drive_del to delete device
Summary: qmp should give friendly hints when can not use __com.redhat_drive_del to del...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev   
(Show other bugs)
Version: 7.2
Hardware: x86_64
OS: All
medium
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: CongLi
URL:
Whiteboard:
Keywords:
Depends On: 750801
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-06-15 10:25 UTC by quxiaoya
Modified: 2017-08-02 03:22 UTC (History)
13 users (show)

Fixed In Version: qemu 2.8.0
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 23:27:12 UTC
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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description quxiaoya 2015-06-15 10:25:35 UTC
Description of problem:
When use  __com.redhat_drive_del to delete block device, qmp will give "An undefined error has occurred".


Version-Release number of selected component (if applicable):

qemu-kvm-rhev-2.3.0-2.el7.x86_64
kernel-3.10.0-263.el7.x86_64

How reproducible:
100%


Steps to Reproduce:
1.Boot up a guest with QEMU

/usr/libexec/qemu-kvm -m 2G -smp 4 -boot menu=on -drive file=/home/RHEL-Server-7.2-64-virtio.raw,snapshot=off,if=none,id=img,cache=none,format=raw -device virtio-blk-pci,drive=img,id=sys-img,bootindex=1 -drive file=/home/data.raw,if=none,id=disk1,format=raw -device virtio-scsi-pci,id=scsi0 -device scsi-hd,bus=scsi0.0,drive=disk1,id=data-disk1 -monitor stdio -spice port=5932,disable-ticketing -netdev tap,id=tap0,script=/etc/qemu-ifup -device virtio-net-pci,netdev=tap0,mac=24:be:05:14:95:12 -qmp tcp::8886,server,nowait

2.Hot-plug this disk to guest via 'blockdev-add' with discard enabled specified

{ "execute": "blockdev-add", "arguments": {'options' : {'driver': 'raw', 'id':'drive-disk1', 'discard':'unmap', 'rerror':'stop', 'werror':'stop', 'file': {'driver': 'host_device', 'filename': '/dev/sdb'}, 'cache': { 'writeback': false, 'direct': true, 'no-flush': false }}} }

3.unplug the disk

{ "execute": "blockdev-add", "arguments": {'options' : {'driver': 'raw', 'id':'drive-disk1', 'discard':'unmap', 'rerror':'stop', 'werror':'stop', 'file': {'driver': 'host_device', 'filename': '/dev/sdb'}, 'cache': { 'writeback': false, 'direct': true, 'no-flush': false }}} }


Actual results:

After step3, qmp will give following hints:
{"error": {"class": "GenericError", "desc": "An undefined error has occurred"}}

Expected results:
1, delete block device via __com.redhat_drive_del successfully.
2, Or give more friendly hints.


Additional info:

Comment 5 Markus Armbruster 2015-06-26 06:10:50 UTC
Step 3 is the same as step 2, but under expected results you say
"delete block device via __com.redhat_drive_del successfully".
Are you sure you pasted the correct step 3?

My best guess is:

3. { "execute": "__com.redhat_drive_del", "arguments": { 'id':'drive-disk1' } }

Produces your actual result, and spews "Deleting device added with
blockdev-add is not supported" to stderr.

blockdev-add is not fully functional, yet.  We're working on it
upstream.  One missing part is blockdev-del (bug 1086193).  drive_del
does not work for drives added with blockdev-add, by design (NOTABUG
bug 1086190).

Until blockdev-del is available, there is no way to delete drives
added with blockdev-add.

When blockdev-add is ready, upstream is expected to deprecate HMP
commands drive_add and drive_del.

As an interim solution for RHEL-6 QMP, we added QMP commands
__com.redhat_drive_add and __com.redhat_drive_del.  Since blockdev-add
is taking longer than hoped, we forward ported them to RHEL-7.

The forward port of __com.redhat_drive_del has a flaw: when trying to
delete a drive added with blockdev-add, it reports the specific error
to stderr, and returns an unspecific "undefined error" to QMP.  This
is what this bug is about.

Libvirt should not use blockdev-add in its current state, so fixing
the error reporting isn't necessary now.  Should we backport a fully
functional blockdev-add along with its libvirt support, we'll want to
fix it.

So I'll leave this bug open until we know what we'll do about
blockdev-add in RHEL-7.

Comment 6 Jun Li 2015-06-26 08:39:40 UTC
(In reply to Markus Armbruster from comment #5)
> Step 3 is the same as step 2, but under expected results you say
> "delete block device via __com.redhat_drive_del successfully".
> Are you sure you pasted the correct step 3?
> 

yes, it's a typo. :)

> My best guess is:
> 
> 3. { "execute": "__com.redhat_drive_del", "arguments": { 'id':'drive-disk1'
> } }
> 
> Produces your actual result, and spews "Deleting device added with
> blockdev-add is not supported" to stderr.
> 

Yes, this is my original meaning.

> blockdev-add is not fully functional, yet.  We're working on it
> upstream.  One missing part is blockdev-del (bug 1086193).  drive_del
> does not work for drives added with blockdev-add, by design (NOTABUG
> bug 1086190).
> 
> Until blockdev-del is available, there is no way to delete drives
> added with blockdev-add.
> 
> When blockdev-add is ready, upstream is expected to deprecate HMP
> commands drive_add and drive_del.
> 
> As an interim solution for RHEL-6 QMP, we added QMP commands
> __com.redhat_drive_add and __com.redhat_drive_del.  Since blockdev-add
> is taking longer than hoped, we forward ported them to RHEL-7.
> 
> The forward port of __com.redhat_drive_del has a flaw: when trying to
> delete a drive added with blockdev-add, it reports the specific error
> to stderr, and returns an unspecific "undefined error" to QMP.  This
> is what this bug is about.

Yes.

> 
> Libvirt should not use blockdev-add in its current state, so fixing
> the error reporting isn't necessary now.  Should we backport a fully
> functional blockdev-add along with its libvirt support, we'll want to
> fix it.
> 

Ok, thank you for your detailed explanations.

> So I'll leave this bug open until we know what we'll do about
> blockdev-add in RHEL-7.

Comment 9 Markus Armbruster 2016-07-22 08:11:13 UTC
The fate of blockdev-add in RHEL-7 is still undecided.

Comment 11 Ademar Reis 2017-01-17 17:00:34 UTC
Part of the work related to blockdev-add (Bug 750801). Reassigning to Kevin.

Comment 12 Kevin Wolf 2017-01-18 10:32:25 UTC
The upstream version of blockdev-add doesn't support the 'id' option any more
(since commit 9ec8873), so the problem has disappeared.

Note that HMP 'drive_del' (and therefore also QMP '__com.redhat_drive_del') can
remove individual nodes that are identified by their node name, and were either
added by HMP 'drive_add -n' (which adds only a node, not a BlockBackend) or by
blockdev-add.

Comment 19 errata-xmlrpc 2017-08-01 23:27:12 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 20 errata-xmlrpc 2017-08-02 01:04:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 21 errata-xmlrpc 2017-08-02 01:56:50 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 22 errata-xmlrpc 2017-08-02 02:37:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 23 errata-xmlrpc 2017-08-02 03:02:18 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Comment 24 errata-xmlrpc 2017-08-02 03:22:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392


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