Re: [Qemu-devel] [PATCH v5 07/10] qemu-img: allow specifying image as a set of options args

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

On Thu, Feb 04, 2016 at 05:06:06PM +0100, Kevin Wolf wrote:
> Am 04.02.2016 um 16:47 hat Daniel P. Berrange geschrieben:
> > On Thu, Feb 04, 2016 at 04:42:06PM +0100, Kevin Wolf wrote:
> > > Am 02.02.2016 um 13:57 hat Daniel P. Berrange geschrieben:
> > > > @@ -1956,7 +2034,13 @@ static int img_convert(int argc, char **argv)
> > > >          goto out;
> > > >      }
> > > >  
> > > > -    out_blk = img_open("target", out_filename, out_fmt, flags, true, quiet);
> > > > +    /* XXX we should allow --image-opts to trigger use of
> > > > +     * img_open() here, but then we have trouble with
> > > > +     * the bdrv_create() call which takes different params.
> > > > +     * Not critical right now, so fix can wait...
> > > > +     */
> > > > +    out_blk = img_open_file("target", out_filename,
> > > > +                            out_fmt, flags, true, quiet);
> > > 
> > > So is the plan to add another option (like --target-image-opts) when
> > > this call is converted?
> > 
> > Well I was hoping --image-opts would affect both source and target,
> > but i guess if we ship it only affecting source, we can't extend
> > it to also affect target without back compat issues, so that might
> > force adding a --target-image-opts
> 
> Yes, that's exactly why I'm asking. We need to decide now whether this
> would be an acceptable outcome or whether we shouldn't have --image-opts
> in this command for now at all.

I thinking having '--target-image-opts' wouldn't be the end of the world.
I also get the feeling that solving the target problem may well require
new cli args regardless, since there's multiple sets of options we care
about - the image creation options are separate from the image runtime
options in the block layer, and so given the image creation options theres
no obvious way to extrapolate the subset which are also valid runtime
options. Also AFAICT, we can't actually specify options at all for the
layer below - it just assumes a plain file backend, so there's no way
to pass options to express creation of qcow2-on-nbd for example, or
formatting of luks-on-rbd, etc - only qcow2-on-file or luks-on-file.


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