Stefan Hajnoczi wrote: > On Mon, May 23, 2011 at 11:49 PM, Jamie Lokier <ja...@shareable.org> wrote: > > Being able to override the backing file path would be useful anyway. > > > > I've already had problems when moving established qcow2 files between > > systems, that for historical reasons contain either an absolute path > > inside for the backing file, or some messy "../../whatever", or > > "foo/bar/whatever", or "backing.img" (lots of different ones with the > > same name), all of which are a pain to work around. ... > Try the qemu-img rebase -f command: > > qemu-img uses the unsafe mode if "-u" is specified. In this mode, only the > backing file name and format of filename is changed without any > checks on the > file contents. The user must take care of specifying the correct new > backing > file, or the guest-visible content of the image will be corrupted. > > This mode is useful for renaming or moving the backing file to somewhere > else. It can be used without an accessible old backing file, i.e. you can > use it to fix an image whose backing file has already been moved/renamed.
Yes indeed. That feature was added after the last time I dealt with this problem. However, I have wanted to open *precious*, *read-only* qcow2 images, for example with -snapshot or the explicit equivalent, and for those precious images I am loathe to let any tool write a single byte to them. The files are kept read-only, and often with the "immutable" attribute on Linux, backed up and checksummed just to be sure. I'd rather just override the value on the command line, so if that feature may turn up for fd: related reasons, it'll be handy for the read-only moved qcow2 file reason too. -- Jamie
