[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] [Qemu-devel] live snapshot wiki updated
- From: Blue Swirl <blauwirbel gmail com>
- To: Jes Sorensen <Jes Sorensen 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>
- Subject: Re: [libvirt] [Qemu-devel] live snapshot wiki updated
- Date: Thu, 21 Jul 2011 22:34:29 +0300
On Thu, Jul 21, 2011 at 11:07 AM, Jes Sorensen <Jes Sorensen redhat com> wrote:
> On 07/20/11 21:51, Blue Swirl wrote:
>>> And the snapshot_blkdev monitor command is a case where qemu needs to create
>>> > a new qcow2 image on the fly, while referencing the name of an existing
>>> > file. What backing name do you put in the new qcow2 file unless you already
>>> > have a name association for all fds already open for the existing backing
>>> > file?
>> For backing file with original name of "/path/in/storage", QEMU could
>> present the fd and the backin path by requesting something like
>> "fd:12,/path/in/storage". The next file in chain "/path2/file" would
>> be "fd:12,fd:34,/path2/file". Or if possible, -fd 12 -backing
>> /path/in/storage with spaces and funny characters escaped etc.
>
> Rather than trying to do this by mangling files on the disk, I would
> suggest we allow registering a call-back open function, which calls back
> into libvirt and requests it to open a given file. It can then do all
> it's security foo to decide whether or not to allow the file to be open.
Just to clarify: I was not proposing any mangling of the files.
> This is relatively clean and avoids the mess of relying on outside
> processes messing about in the images.
>
> Cheers,
> Jes
>
>
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]