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

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Sep 29, 2016 at 04:43:25PM +0800, Fam Zheng wrote:
> 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.

Clearly I'm not aware of that :-)  It seems libvirt does not yet use
blockdev-mirror either, which is where I got the original bug report
about drive-mirror from.

I'll submit a patch to mark drive-mirror as deprecated and point the
otherwise ignorant reader towards blockdev-mirror instead....

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