On Wed, Jul 20, 2011 at 11:50:53AM +0200, Kevin Wolf wrote: > Am 19.07.2011 18:46, schrieb Daniel P. Berrange: > > On Tue, Jul 19, 2011 at 04:14:27PM +0100, Stefan Hajnoczi wrote: > >> On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> wrote: > >>> On 07/19/11 16:24, Eric Blake wrote: > >>>> [adding the libvir-list] > >>>> On 07/19/2011 08:09 AM, Jes Sorensen wrote: > >>>>> Urgh, libvirt parsing image files is really unfortunate, it really > >>>>> doesn't give me warm fuzzy feelings :( libvirt really should not know > >>>>> about internals of image formats. > >>>> > >>>> But even if you add new features to qemu to avoid needing this in the > >>>> future, it doesn't change the past - libvirt will always have to know > >>>> how to parse image files understood by older qemu, and so as long as > >>>> libvirt already knows how to do that parsing, we might as well take > >>>> advantage of it. > >>> > >>> What has been done here in the past is plain wrong. Continuing to do it > >>> isn't the right thing to do here. > >>> > >>>> Besides, I feel that having a well-documented file format, so that > >>>> independent applications can both parse the same file with the same > >>>> semantics by obeying the file format specification, is a good design goal. > >>> > >>> We all know that documentation is rarely uptodate, new features may not > >>> get added and libvirt will never be able to keep up. The driver for a > >>> file format belongs in QEMU and nowhere else. > >> > >> It should be a goal to avoid dependencies in multiple layers of the > >> stack because it becomes are to add new features - they require > >> coordinated changes in multiple layers. Having both QEMU and libvirt > >> know the internals of image files is such a multi-dependency. If I > >> want to add a new format or change an existing format I have to touch > >> both layers. > >> > >> 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. > > > > 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. > > What's the real problem with this approach? Parsing the data meant for > humans, from an interface that is potentially unstable? If this is it, > it should be easy enough to add a JSON output mode to qemu-img info. It is a really heavyweight solution to have to spawn qemu-img every time we need to access this data, when it can be done with a trivial open+read+close sequence. In addition the output data format is not entirely pleasant for machine reading (some fields only have data rounded up to MB, not the raw byte count). Finally, we also wanted to be able to extract some basic metdata about disk image formats on non-QEMU hosts, for our storage management APIs which are used on Xen or VMWare hosts where many of these same disk image formats are also used. A JSON output mode would be helpful, but unfortunately can't really address the other issues. > > 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. > > I'm afraid the block drivers have too many dependencies on the qemu core > for this to be an option without investing a lot of effort. That's why I sort of think there is value in having someone provide a standalone library API for querying some core set of block format metadata. QEMU is but one project with virtual disk formats, there are plenty of others out there in existance, so while reusing QEMU block code would be nice, it isn't leading to any significant reduction in copies of block format parsing code amongst all the virt projects in existance. Regards, 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list