[libvirt] [PATCH 3/9] qemu: Reuse qemuBlockStorageSourceAttachApply in disk hotplug
Ján Tomko
jtomko at redhat.com
Sat Jun 2 15:39:51 UTC 2018
On Fri, Jun 01, 2018 at 05:51:06PM +0200, Peter Krempa wrote:
>Create a new "Prepare" function and move the drive add code into the new
>helpers. This will eventually allow to simplify and unify the attaching
>code for use with blockdev at the same time as providing compatibility
>with older qemus.
>
>Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>---
> src/qemu/qemu_block.c | 18 ++++++++++++++++++
> src/qemu/qemu_block.h | 4 ++++
> src/qemu/qemu_command.c | 29 ++++++++++++++++++++++++++++-
> src/qemu/qemu_command.h | 8 ++++----
> src/qemu/qemu_hotplug.c | 26 +++++++++-----------------
> 5 files changed, 63 insertions(+), 22 deletions(-)
>
>diff --git a/src/qemu/qemu_block.c b/src/qemu/qemu_block.c
>index 85176925c9..73aab9d73a 100644
>--- a/src/qemu/qemu_block.c
>+++ b/src/qemu/qemu_block.c
>@@ -24,9 +24,12 @@
>
> #include "viralloc.h"
> #include "virstring.h"
>+#include "virlog.h"
>
> #define VIR_FROM_THIS VIR_FROM_QEMU
>
>+VIR_LOG_INIT("qemu.qemu_block");
>+
> /* qemu declares the buffer for node names as a 32 byte array */
> static const size_t qemuBlockNodeNameBufSize = 32;
>
>@@ -1482,6 +1485,8 @@ qemuBlockStorageSourceAttachDataFree(qemuBlockStorageSourceAttachDataPtr data)
>
> virJSONValueFree(data->storageProps);
> virJSONValueFree(data->formatProps);
>+ VIR_FREE(data->driveCmd);
>+ VIR_FREE(data->driveAlias);
> VIR_FREE(data);
> }
>
>@@ -1563,6 +1568,13 @@ qemuBlockStorageSourceAttachApply(qemuMonitorPtr mon,
> data->formatAttached = true;
> }
>
>+ if (data->driveCmd) {
>+ if (qemuMonitorAddDrive(mon, data->driveCmd) < 0)
>+ return -1;
>+
>+ data->driveAdded = true;
>+ }
>+
> return 0;
> }
>
>@@ -1591,6 +1603,12 @@ qemuBlockStorageSourceAttachRollback(qemuMonitorPtr mon,
> if (data->storageAttached)
> ignore_value(qemuMonitorBlockdevDel(mon, data->storageNodeName));
>
>+ if (data->driveAdded) {
>+ if (qemuMonitorDriveDel(mon, data->driveAlias) < 0)
>+ VIR_WARN("Unable to remove drive %s (%s) after failed "
>+ "qemuMonitorAddDevice", data->driveAlias, data->driveCmd);
>+ }
>+
> virErrorRestore(&orig_err);
Even though this call is unrelated to the other two, shouldn't rollback
be in reverse order?
Reviewed-by: Ján Tomko <jtomko at redhat.com>
Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180602/05c51a04/attachment-0001.sig>
More information about the libvir-list
mailing list