[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [libvirt] RFC: API additions for enhanced snapshot support
- From: Stefan Hajnoczi <stefanha gmail com>
- To: Eric Blake <eblake redhat com>
- Cc: Kevin Wolf <kwolf redhat com>, "libvir-list redhat com" <libvir-list redhat com>, Jes Sorensen <Jes Sorensen redhat com>, Jagane Sundar <jagane sundar org>, "wdongxu cn ibm com" <wdongxu cn ibm com>
- Subject: Re: [libvirt] RFC: API additions for enhanced snapshot support
- Date: Fri, 8 Jul 2011 09:58:56 +0100
On Thu, Jul 7, 2011 at 8:34 PM, Eric Blake <eblake redhat com> wrote:
> On 07/07/2011 03:13 AM, Stefan Hajnoczi wrote:
>> On Wed, Jul 6, 2011 at 3:03 PM, Eric Blake <eblake redhat com> wrote:
>>> In other words, it looks like we are stuck with updating XML to track
>>> new file names any time we take a snapshot.
>>
>> Yes, but QEMU's snapshot_blkdev command takes a filename argument so
>> at least you get to specify that new filename.
>
> Well, the best thing (from libvirt's point of view) would be if
> snapshot_blkdev took a single string argument, which is either a
> /path/to/filename (and qemu does open()) or fd:name notation (to refer
> to a previously-named fd passed via the getfd monitor command, so that
> libvirt does open()). This would make SELinux integration easier, as
> one of the sVirt goals is to get to the point where we can use SELinux
> to forbid qemu from open()ing files on NFS shares, while still
> permitting all other operations on already-open fds passed in from libvirt.
Today QEMU supports /path/to/filename. An fd argument to
snapshot_blkdev requires a little bit of work since the QEMU block
layer .bdrv_create() interface takes a filename and tries to create
it.
Jes: Is the fd argument to snapshot_blkdev in your plans?
Stefan
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]