[Qemu-devel] [RFC 0/2] Parse 'filename' option for RBD/iSCSI

[Qemu-devel] [RFC 0/2] Parse 'filename' option for RBD/iSCSI

[Jeff Cody]

We need to be able to parse the 'filename' option for both rbd and iscsi,
because there may exist images in the wild that have json backing files,
that specify the filename argument.

Marking the series as RFC at least partially for the precedence given to
arguments; as written, these patches will give preference to the 'filename'
parameter over passed options.

Jeff Cody (2):
  block/rbd: enable filename option and parsing
  block/iscsi: enable filename option and parsing

 block/iscsi.c | 19 ++++++++++++++++++-
 block/rbd.c   | 19 ++++++++++++++++++-
 2 files changed, 36 insertions(+), 2 deletions(-)

-- 
2.9.3

[Qemu-devel] [RFC 1/2] block/rbd: enable filename option and parsing

[Jeff Cody]

When enabling option parsing and blockdev-add for rbd, we removed the
'filename' option.  Unfortunately, this was a bit optimistic, as
previous versions of QEMU allowed the use of the option in backing
filenames via json.  This means that without parsing this option, we
cannot open existing images that used to work fine.

See bug: https://bugzilla.redhat.com/show_bug.cgi?id=1457088

Signed-off-by: Jeff Cody <jcody@redhat.com>
---
 block/rbd.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/block/rbd.c b/block/rbd.c
index e551639..cbc0b85 100644
--- a/block/rbd.c
+++ b/block/rbd.c
@@ -340,6 +340,10 @@ static QemuOptsList runtime_opts = {
             .type = QEMU_OPT_STRING,
             .help = "Legacy rados key/value option parameters",
         },
+        {
+            .name = "filename",
+            .type = QEMU_OPT_STRING,
+        },
         { /* end of list */ }
     },
 };
@@ -541,12 +545,24 @@ static int qemu_rbd_open(BlockDriverState *bs, QDict *options, int flags,
 {
     BDRVRBDState *s = bs->opaque;
     const char *pool, *snap, *conf, *user, *image_name, *keypairs;
-    const char *secretid;
+    const char *secretid, *filename;
     QemuOpts *opts;
     Error *local_err = NULL;
     char *mon_host = NULL;
     int r;
 
+    /* If we are given a filename, parse the filename, with precedence given to
+     * filename encoded options */
+    filename = qdict_get_try_str(options, "filename");
+    if (filename) {
+        qemu_rbd_parse_filename(filename, options, &local_err);
+        if (local_err) {
+            r = -EINVAL;
+            error_propagate(errp, local_err);
+            goto exit;
+        }
+    }
+
     opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
     qemu_opts_absorb_qdict(opts, options, &local_err);
     if (local_err) {
@@ -665,6 +681,7 @@ failed_shutdown:
 failed_opts:
     qemu_opts_del(opts);
     g_free(mon_host);
+exit:
     return r;
 }
 
-- 
2.9.3

[Qemu-devel] [RFC 2/2] block/iscsi: enable filename option and parsing

[Jeff Cody]

When enabling option parsing and blockdev-add for iscsi, we removed the
'filename' option.  Unfortunately, this was a bit optimistic, as
previous versions of QEMU allowed the use of the option in backing
filenames via json.  This means that without parsing this option, we
cannot open existing images that used to work fine.

See bug: https://bugzilla.redhat.com/show_bug.cgi?id=1457088

Signed-off-by: Jeff Cody <jcody@redhat.com>
---
 block/iscsi.c | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/block/iscsi.c b/block/iscsi.c
index 5daa201..ba50e76 100644
--- a/block/iscsi.c
+++ b/block/iscsi.c
@@ -1732,6 +1732,10 @@ static QemuOptsList runtime_opts = {
             .name = "timeout",
             .type = QEMU_OPT_NUMBER,
         },
+        {
+            .name = "filename",
+            .type = QEMU_OPT_STRING,
+        },
         { /* end of list */ }
     },
 };
@@ -1747,12 +1751,24 @@ static int iscsi_open(BlockDriverState *bs, QDict *options, int flags,
     char *initiator_name = NULL;
     QemuOpts *opts;
     Error *local_err = NULL;
-    const char *transport_name, *portal, *target;
+    const char *transport_name, *portal, *target, *filename;
 #if LIBISCSI_API_VERSION >= (20160603)
     enum iscsi_transport_type transport;
 #endif
     int i, ret = 0, timeout = 0, lun;
 
+    /* If we are given a filename, parse the filename, with precedence given to
+     * filename encoded options */
+    filename = qdict_get_try_str(options, "filename");
+    if (filename) {
+        iscsi_parse_filename(filename, options, &local_err);
+        if (local_err) {
+            ret = -EINVAL;
+            error_propagate(errp, local_err);
+            goto exit;
+        }
+    }
+
     opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
     qemu_opts_absorb_qdict(opts, options, &local_err);
     if (local_err) {
@@ -1967,6 +1983,7 @@ out:
         }
         memset(iscsilun, 0, sizeof(IscsiLun));
     }
+exit:
     return ret;
 }
 
-- 
2.9.3

Re: [Qemu-devel] [RFC 0/2] Parse 'filename' option for RBD/iSCSI

[Richard W.M. Jones]

On Mon, Jun 12, 2017 at 12:05:12AM -0400, Jeff Cody wrote:
> We need to be able to parse the 'filename' option for both rbd and iscsi,
> because there may exist images in the wild that have json backing files,
> that specify the filename argument.
> 
> Marking the series as RFC at least partially for the precedence given to
> arguments; as written, these patches will give preference to the 'filename'
> parameter over passed options.

I tested this as follows:

(1) Prepare a test image.  By using the ‘qemu-img rebase -u’ option we
can set the formerly correct / now incorrect backing option to an
arbitrary json string of our choosing:

$ qemu-img create test.img -f qcow2 10M
$ qemu-img rebase -u -b 'json:{"file.driver":"rbd","file.filename":"rbd:rbd/rbd.img:mon_host=127.0.0.0"}' test.img 

(2) With upstream qemu:

$ qemu-system-x86_64 -hda test.img 
qemu-system-x86_64: -hda test.img: Could not open backing file: Parameters 'pool' and 'image' are required

(3) With upstream qemu + these two patches:

$ ~/d/qemu/x86_64-softmmu/qemu-system-x86_64 -hda test.img
[hangs and eventually reports a timeout because I don't really
have a Ceph server]

So I would say that these patches, superficially at least, do seem to
work.  Although I wasn't able to test them against a real Ceph server.

  Tested-by: Richard W.M. Jones <rjones@redhat.com>

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html