Re: [Qemu-devel] Re: block: format vs. protocol, and how they stack

[Jamie Lokier <jamie@shareable.org>]

Kevin Wolf wrote:
> > The "protocol" parlance breaks down when we move away from the simple
> > stuff.  For instance, qcow2 needs two children: the block driver
> > providing the delta bits (in qcow2 format), and the block driver
> > providing the base bits (whose configuration happens to be stored in the
> > delta bits).  
> 
> Backing files are different. When talking about opening images (which is
> what we do here) the main difference is that they can be opened only
> after the image itself has been opened. I don't think we should include
> them in this discussion.

Imho, being unable to override the qcow2 backing file from the command
line / monitor is very annoying, if you've moved files from another
machine or just renamed them for tidiness.  It's especially bad if the
supplied qcow2 file has an absolute path in it, quite bad if it has
subdirectories or ".." components, annoying if you've been given
several qcow2 files all of which have the name "backing-file" stored
in them which are different images because they were originally on
different machines, and awful if it has the name of a block device in it.

So, imho, for the discussion of command line / QMP options, there
should be reserved a place for giving the name of the backing file
through command line/monitor/QMP, along with the backing file's
formats/protocols/transports/options, and so on recursively in a tree
structure of arbitrary depth.

There is also the matter of qcow2 files encoding the path, but not
necessarily all the blockdev options that you might want to use to
access the backing file, such as cache=.

In QMP it's obviously quite simple to accept a full child blockdev
specification object as a qcow2-specific parameter, thus not needing
any further discussion in this thread.  It's less obvious how to do it
on the command line or human monitor.

-- Jamie