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
