[Qemu-block] RFC: handling image options with drive-mirror/drive-backup

[Daniel P. Berrange]

I got a report that the LUKS block driver was not working in combination
with the drive-mirror command and have been investigating possible fixes
for this.

The core problem here is dealing with the target image. If you try to
run with a pre-created target that is a LUKS image, it will fail because
we have no way to provide the "key-secret" option required to open the
target.  If you try to tell drive-mirror to create a new target with
LUKS format, it will fail trying to create the image, again because
no "key-secret" option can be provided.

While this is a fundamental blocker problem for LUKS, it also affects
other image formats. For example, if you're telling drive-mirror to
create a new qcow2 volume, its impossible to control desirable attributes
like cluster-size, or compat-level. If you're mirroring a qcow2 file to
a new qcow2 file, it is impossible to maintain any custom runtimes opts
yuou might have set on the source - eg 'lazy-refcounts', or the various
discard settings will all be stuck on defaults for the target.

You can workaround the problem of being able to create new volumes by
just creating them using qemu-img ahead of time instead.

Dealing with the problem of opening images, requires that we have some
way to provide block options to the drive-mirror command. The naive
approach would to just add a new parameter

    'options': ['str']

but IMHO this is just perpetuating the broken design of drive-mirror.

The core problem is that this command should not have been using a
plain target + format pair of strings in the first place. Instead it
should have had a single

   "target": "BlockdevOptions"

So my suggestion is that we deprecate "drive-mirror" and define a fixed
command "drive-mirror-blockdev" (or "blockdev-mirror" ?) that accepts
the proper BlockdevOptions QAPI type for the target as above.

This only solves the "open an existing image" case - if we want to
have drive-mirror be able to create new images, then we need to have
a new struct "BlockdevCreateOptions", since creation options are a
superset of the "BlockdevOptions". I'm inclined to say that the
"drive-mirror" command should *not* have the ability to create new
images, as I can't see a compelling reason to overload that functionality
in the same command.

Instead we should add a "blockdev-create" QMP command for doing that
action explicitly, that apps can invoke just prior to running the
drive-mirror command. We'd also want "blockdev-delete" to allow it
to be deleted on failure.

It looks like the same design problem of drive-mirror also applies
to drive-backup.

Co-incidentally I had already been experimenting with the creation
of a "BlockdevCreateOptions" QAPI type, in order to support the
fully-nested block device creation with 'qemu-img create'.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|