On Mon, May 23, 2011 at 11:49 PM, Jamie Lokier <ja...@shareable.org> wrote:
> Markus Armbruster wrote:
>> Anthony Liguori <anth...@codemonkey.ws> writes:
>>
>> > On 05/23/2011 05:30 AM, Daniel P. Berrange wrote:
>> >> It feels to me that turning the current block driver code which just does
>> >> open(2) on files, into something which issues events& asynchronously
>> >> waits for a file would potentially be quite complex.
>> >>
>> >> You also need to be much more careful from a security POV if the mgmt
>> >> app is accepting requests to open arbitrary files from QEMU, to ensure
>> >> the filenames are correctly/strictly validated before opening them and
>> >> giving them back to QEMU. An architecture where the mgmt app decides
>> >> what FDs to supply upfront, has less potential for security errors.
>> >>
>> >> To me the ideal would thus be that we can supply FDs for the backing
>> >> store with -blockdev syntax, and that places where QEMU re-opens files
>> >> would be enhanced to avoid that need. If there are things we can't do
>> >> without closing& re-opening the same file, then perhaps we need some
>> >> new ioctl()/fcntl() calls to change those file attributes on the fly.
>> >
>> > I agree. But my view of blockdev is that you wouldn't set an fd
>> > attribute but rather the backing file name and use the fd protocol.
>> > For instance:
>> >
>> > -blockdev id=foo-base,path=fd:4,format=raw
>> > -blockdev id=foo,path=fd:3,format=qcow2,backing_file=foo
>>
>> I guess you mean backing_file=foo-base.
>>
>> If none is specified, use the backing file specification stored in the
>> image.
>>
>> Matches my current thinking.
>
> 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.
>
> (Imho, it would also make sense if qcow2 files contained a UUID for
> their backing file to verify you've given the correct backing file,
> and maybe help find it (much like Linux finds real disk devices and
> filesystems when mounting these days).)
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.
Stefan
