提交 00331bfb 编写于 作者: E Eric Blake

qemu: better error message when block job can't succeed

https://bugzilla.redhat.com/show_bug.cgi?id=1140981 reports that
the qemu-kvm shipped as part of RHEL 7.0 intentionally[1] cripples
block jobs by removing the 'block-stream' QMP command, while still
leaving 'block-job-cancel' as an unusable no-op.  Meanwhile, we
already had existing code that checked whether block jobs were
completely missing (such as qemu 0.15), old style (cancel is
synchronous, and all commands spelled with '_'), or new style
(cancel is asynchronous, and all commands spelled with '-'), and
used that three-way probe to give decent error messages.  At the
time that code was added, all existing qemu versions fell in one
of three buckets, and the code was using the presence of
'block-job-cancel' as the witness of which of the three buckets.
But now that RHEL qemu has shipped with intentionally crippled
'block-stream', we have a fourth bucket, which results in ugly
error messages when trying 'virsh blockpull':

 error: Requested operation is not valid: Command 'block-stream' is not found

In reality, the fourth bucket should be treated the same as the
first bucket (no block job support); we can do that by realizing
that no existing build of qemu has working block-stream while
lacking block-job-cancel, so it is easiest to change our witness
to the command that starts a job rather than ends one.  We still
act correctly regarding command spelling and whether cancel is
asynchronous.  And on crippled RHEL builds, we now get the desired:

 error: unsupported configuration: block jobs not supported with this qemu binary

[1] The intentional cripple is limited to qemu-kvm of RHEL; when using
qemu-kvm-rhev of RHEV, block job functionality is supported.  Don't ask
me to explain the "why" behind it all - I'm just dealing with fallout
from someone else's decision.

* src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC): Tweak comment.
* src/qemu/qemu_capabilities.c (virQEMUCapsCommands): Look for stream
rather than cancel when determining the flavor of block jobs supported.
Signed-off-by: NEric Blake <eblake@redhat.com>
上级 95a56835
......@@ -1422,8 +1422,8 @@ struct virQEMUCapsStringFlags {
struct virQEMUCapsStringFlags virQEMUCapsCommands[] = {
{ "system_wakeup", QEMU_CAPS_WAKEUP },
{ "transaction", QEMU_CAPS_TRANSACTION },
{ "block_job_cancel", QEMU_CAPS_BLOCKJOB_SYNC },
{ "block-job-cancel", QEMU_CAPS_BLOCKJOB_ASYNC },
{ "block_stream", QEMU_CAPS_BLOCKJOB_SYNC },
{ "block-stream", QEMU_CAPS_BLOCKJOB_ASYNC },
{ "dump-guest-memory", QEMU_CAPS_DUMP_GUEST_MEMORY },
{ "query-spice", QEMU_CAPS_SPICE },
{ "query-kvm", QEMU_CAPS_KVM },
......
......@@ -127,8 +127,8 @@ typedef enum {
QEMU_CAPS_SCSI_DISK_CHANNEL = 87, /* Is scsi-disk.channel available? */
QEMU_CAPS_SCSI_BLOCK = 88, /* -device scsi-block */
QEMU_CAPS_TRANSACTION = 89, /* transaction monitor command */
QEMU_CAPS_BLOCKJOB_SYNC = 90, /* RHEL 6.2 block_job_cancel */
QEMU_CAPS_BLOCKJOB_ASYNC = 91, /* qemu 1.1 block-job-cancel */
QEMU_CAPS_BLOCKJOB_SYNC = 90, /* old block_job_cancel, block_stream */
QEMU_CAPS_BLOCKJOB_ASYNC = 91, /* new block-job-cancel, block-stream */
QEMU_CAPS_SCSI_CD = 92, /* -device scsi-cd */
QEMU_CAPS_IDE_CD = 93, /* -device ide-cd */
QEMU_CAPS_NO_USER_CONFIG = 94, /* -no-user-config */
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册