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/ :|