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

Michael Roth mdroth at linux.vnet.ibm.com
Thu Jul 21 18:56:08 UTC 2011


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




More information about the libvir-list mailing list