Re: [libvirt] [Qemu-devel] live snapshot wiki updated

On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen <Jes.Sorensen(a)redhat.com&gt; 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.