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