[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: Eric Blake <eblake redhat com>
- Cc: Kevin Wolf <kwolf redhat com>, Stefan Hajnoczi <stefanha linux vnet ibm com>, "libvir-list redhat com" <libvir-list redhat com>, QEMU Developers <qemu-devel nongnu org>, Anthony Liguori <anthony codemonkey ws>
- Subject: Re: [libvirt] [Qemu-devel] live snapshot wiki updated
- Date: Thu, 21 Jul 2011 10:02:42 +0200
On 07/20/11 15:46, Eric Blake wrote:
> On 07/20/2011 07:25 AM, Jes Sorensen wrote:
>>> I think if libvirt wants qemu to use an fd instead of a file name, it
>>> shouldn't pass a file name but an fd in the first place. Which means
>>> that the two that we need are support for an fd: protocol (patches on
>>> the list, need review), and a way for libvirt to override the backing
>>> file of an image.
>>
>> The problem is that QEMU will find backing file file names inside the
>> images which it will be unable to open. How do you suggest we get around
>> that?
>
> We've already told you - qemu must have a way to be passed fds which are
> associated with names, and when a file refers to another backing file by
> name, then qemu falls back on its fd/name mapping to use the
> already-passed fd instead. Which implies that someone else, either
> libvirt or a qemu-maintained libblockformat.so, needs to have a stable
> interface for parsing the backing file name out of an arbitrary qcow2
> file, and that this interface must work no matter how many other
> extensions are added to qcow2.
As I replied to you earlier, libvirt is *not* allowed to be messing with
internals of image files! Passing in backing file fds as a result of
libvirt messing around in internals of the image headers is utterly
broken and is not going to happen!
Jes
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]