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

[Fam Zheng]

On Thu, 09/29 09:34, Daniel P. Berrange wrote:
> 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.

Are you aware that there is already a blockdev-mirror command? Supposedly it
can do what you need, together with blockdev-add once the latter is deemed
ready.

> 
> 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.

Images can be created out of bound with qemu-img, and opened with blockdev-add.

> 
> 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.

There is also blockdev-backup already.

Fam

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