On Tue, Jun 22, 2010 at 05:40:02PM +0100, Jamie Lokier wrote: > 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.
FYI, in the scenario where you've moved backing files around, you can use qemu-img to update the location qemu-img rebase -u -b /path/to/newbackingfile.img demo.img Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
