Re: [Qemu-devel] [PATCH] Add support for fd: protocol

[Jamie Lokier]

Markus Armbruster wrote:
> Anthony Liguori <address@hidden> 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).)

-- Jamie