qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] live snapshot wiki updated


From: Michael Roth
Subject: Re: [Qemu-devel] live snapshot wiki updated
Date: Thu, 21 Jul 2011 13:56:08 -0500
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0

On 07/19/2011 11:47 AM, 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:
[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.

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.

How wrong would it be to call out to qemu-img to handle this instead? Seems like a more stable interface (assuming the output of `qemu-img info` is treated as an API of sorts, or perhaps some other output mode is added to qemu-img that is considered stable).


Daniel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]