Re: [Qemu-devel] live snapshot wiki updated

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Jul 20, 2011 at 10:23:12AM +0200, Jes Sorensen wrote:
> On 07/19/11 18:46, Daniel P. Berrange wrote:
> > On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote:
> >> For fd-passing perhaps we have an opportunity to use a callback
> >> mechanism (QEMU request: filename -> libvirt response: fd) and do all
> >> the image format parsing in QEMU.
> > 
> > The reason why libvirt does the parsing of file headers to determine
> > backing files is to maintain the trust boundary. Everything run from
> > the exec() of QEMU onwards is considered untrusted code. So having
> > QEMU parsing the file headers & passing back open() requests to libvirt
> > is breaking the trust boundary.
> 
> Pardon, but I fail to see the issue here. If QEMU passes a filename back
> to libvirt, libvirt still gets to make the decision whether or not it is
> legitimate for QEMU to get that file descriptor or not. It doesn't
> change anything wrt who actually opens the file, hence the 'trust' is
> unchanged.

To make the decision whether the filename from QEMU is valid, we have
to parse the master image header data to see if the filename actually
matches the backing file required by the image assigned to the guest.

> > NB, i'm not happy about libvirt having to have knowledge of file format
> > headers, but we needed something more efficient & reliable than invoking
> > qemu-img info & parsing the output. Ideally QEMU (or something else)
> > would provide a library libblockformat.so with stable APIs for at least
> > reading metadata about image formats. If it had APIs for image creation,
> > etc too that would be a bonus, but we're more or less ok spawning qemu-img
> > for those cases currently.
> 
> Even having a library for libvirt to link against is suboptimal here.
> Two processes shouldn't be fighting over the internals of metadata, the
> ownership of the metadata belongs solely with QEMU. In addition you have
> the constant issue of dependencies there, hence if QEMU is updated and
> it provides a newer block format library, it may prevent libvirt from
> running forcing an update of libvirt as well. That is not acceptable for
> development.

We're not fighting over the internals of metadata. We just need to know
ahead of launching QEMU, what backing files an image has & what format
they are in. We do that by reading at the metadata headers of the disk
images. We never attempt to write to the disk images. Either someone
provides a library todo that, or we write the probing code for each
file format in libvirt. Currently we have the latter.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|