On 07/20/11 11:38, Daniel P. Berrange wrote: > 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. I have pointed out repeatedly why you do not need to do this. It is horrendous that libvirt didn't seek a proper solution to this problem before going on and implementing this current mess. Jes -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list