Red Hat Bugzilla – Bug 1231739
qmp should give friendly hints when can not use __com.redhat_drive_del to delete device
Last modified: 2017-08-01 23:22:27 EDT
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:
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.
(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.
The fate of blockdev-add in RHEL-7 is still undecided.
Part of the work related to blockdev-add (Bug 750801). Reassigning to Kevin.
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.
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