Blame SOURCES/kvm-QMP-Forward-port-__com.redhat_drive_del-from-RHEL-6.patch

0a122b
From 7cba796b16325e96d01e65bd265b4073ab103157 Mon Sep 17 00:00:00 2001
0a122b
Message-Id: <7cba796b16325e96d01e65bd265b4073ab103157.1387385974.git.minovotn@redhat.com>
0a122b
From: Markus Armbruster <armbru@redhat.com>
0a122b
Date: Tue, 17 Dec 2013 06:46:35 +0100
0a122b
Subject: [PATCH 1/5] QMP: Forward-port __com.redhat_drive_del from RHEL-6
0a122b
0a122b
RH-Author: Markus Armbruster <armbru@redhat.com>
0a122b
Message-id: <1387262799-10350-3-git-send-email-armbru@redhat.com>
0a122b
Patchwork-id: 56292
0a122b
O-Subject: [PATCH v2 2/6] QMP: Forward-port __com.redhat_drive_del from RHEL-6
0a122b
Bugzilla: 889051
0a122b
RH-Acked-by: Fam Zheng <famz@redhat.com>
0a122b
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
0a122b
RH-Acked-by: Luiz Capitulino <lcapitulino@redhat.com>
0a122b
0a122b
From: Markus Armbruster <armbru@redhat.com>
0a122b
0a122b
Upstream has drive_del, but only in HMP.  The backport to RHEL-6 added
0a122b
it to QMP as well.  Since the QMP command is a downstream extension,
0a122b
it needs the __com.redhat_ prefix.  Since RHEL-6 doesn't have separate
0a122b
definition of QMP and HMP commands, both the QMP and the HMP command
0a122b
got the prefix.
0a122b
0a122b
RHEL-7 inherits HMP command drive_del from upstream.  Add QMP command
0a122b
__com.redhat_drive_del for RHEL-6 compatibility.
0a122b
0a122b
If we needed similar compatibility for the HMP command, we'd have to
0a122b
add __com.redhat_drive_del as alias for drive_del.  But we don't.
0a122b
0a122b
Code copied from RHEL-6's qemu-monitor.hx as of
0a122b
qemu-kvm-0.12.1.2-2.418.el6.  It has a "drive_del" without the prefix
0a122b
in the documentation.  Fixed here.  Hardly worth fixing in RHEL-6 now.
0a122b
0a122b
Signed-off-by: Markus Armbruster <armbru@redhat.com>
0a122b
---
0a122b
 qmp-commands.hx | 31 +++++++++++++++++++++++++++++++
0a122b
 1 file changed, 31 insertions(+)
0a122b
0a122b
Signed-off-by: Michal Novotny <minovotn@redhat.com>
0a122b
---
0a122b
 qmp-commands.hx | 31 +++++++++++++++++++++++++++++++
0a122b
 1 file changed, 31 insertions(+)
0a122b
0a122b
diff --git a/qmp-commands.hx b/qmp-commands.hx
0a122b
index cedcd17..0ae9204 100644
0a122b
--- a/qmp-commands.hx
0a122b
+++ b/qmp-commands.hx
0a122b
@@ -108,6 +108,37 @@ Note: The "force" argument defaults to false.
0a122b
 EQMP
0a122b
 
0a122b
     {
0a122b
+        .name       = RFQDN_REDHAT "drive_del",
0a122b
+        .args_type  = "id:s",
0a122b
+        .params     = "device",
0a122b
+        .help       = "remove host block device",
0a122b
+        .user_print = monitor_user_noop,
0a122b
+        .mhandler.cmd_new = do_drive_del,
0a122b
+    },
0a122b
+
0a122b
+SQMP
0a122b
+__com.redhat_drive_del
0a122b
+----------
0a122b
+
0a122b
+Remove host block device.  The result is that guest generated IO is no longer
0a122b
+submitted against the host device underlying the disk.  Once a drive has
0a122b
+been deleted, the QEMU Block layer returns -EIO which results in IO
0a122b
+errors in the guest for applications that are reading/writing to the device.
0a122b
+These errors are always reported to the guest, regardless of the drive's error
0a122b
+actions (drive options rerror, werror).
0a122b
+
0a122b
+Arguments:
0a122b
+
0a122b
+- "id": the device's ID (json-string)
0a122b
+
0a122b
+Example:
0a122b
+
0a122b
+-> { "execute": "__com.redhat_drive_del", "arguments": { "id": "block1" } }
0a122b
+<- { "return": {} }
0a122b
+
0a122b
+EQMP
0a122b
+
0a122b
+    {
0a122b
         .name       = "change",
0a122b
         .args_type  = "device:B,target:F,arg:s?",
0a122b
         .mhandler.cmd_new = qmp_marshal_input_change,
0a122b
-- 
0a122b
1.7.11.7
0a122b