On Wed, Jul 20, 2011 at 10:26:49AM +0200, Jes Sorensen wrote: > On 07/19/11 18:47, Daniel P. Berrange wrote: > > On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote: > >> On 07/19/11 16:24, Eric Blake wrote: > >>> 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. > > > > This would be possible if QEMU to provide a libblockformat.so library > > which allowed apps to extract metadata from file formats using a stable > > API. > > There is no reason for libvirt or any external process to mess about > with the internals of image files. You have the same problem if the > image file is encrypted. Just repeating "libvirt doesn't need todo this" many times doesn't make it true. I have described why we need to read the disk image to determine its backing files ahead of QEMU being launched quite clearly. 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