[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
- From: Jes Sorensen <Jes Sorensen redhat com>
- To: "Daniel P. Berrange" <berrange redhat com>
- Cc: "libvir-list redhat com" <libvir-list redhat com>, QEMU Developers <qemu-devel nongnu org>, Stefan Hajnoczi <stefanha linux vnet ibm com>
- Subject: Re: [libvirt] [Qemu-devel] live snapshot wiki updated
- Date: Thu, 21 Jul 2011 10:09:04 +0200
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]