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

Am 20.07.2011 19:20, schrieb Blue Swirl: > On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf <kwolf(a)redhat.com&gt; wrote: >> Am 20.07.2011 15:25, schrieb Jes Sorensen: >>> On 07/20/11 12:01, Kevin Wolf wrote: >>>>>> Right, we're stuck with the two horros of NFS and selinux, so we need >>>>>> something that gets around the problem. In a sane world we would simply >>>>>> say 'no NFS, no selinux', but as you say that will never happen. >>>>>> >>>>>> My suggestion of a callback mechanism where libvirt registers the >>>>>> callback with QEMU for open() calls, allowing libvirt to perform the >>>>>> open and return the open file descriptor would get around this problem. >>>> To me this sounds more like a problem than a solution. It basically >>>> means that during an open (which may even be initiated by a monitor >>>> command), you need monitor interaction. It basically means that open >>>> becomes asynchronous, and requires clients to deal with that, which >>>> sounds at least "interesting"... Also you have to add some magic to all >>>> places opening something. >>>> >>>> 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? >> >> This is the part with allowing libvirt to override the backing file. Of >> course, this is not something that we can add with five lines of code, >> it requires -blockdev. > > There could still be some issues: > Let's have files A, B, C etc. with backing files AA etc. How would > libvirt know that when QEMU wants to write to file CA, this is because > it's needed to access C, or is it just trickery by a devious guest to > corrupt storage? > > This could be handled so that instead of naming the backing file, QEMU > asks for a descriptor for the backing file by presenting the > descriptor to main file C, qemu shouldn't ask for anything. libvirt shouldn't give it a filename in the first place. It should do something like this: { "execute": "blockdev_add", "arguments"= {  "driver": "fd," "fd": "4", "backing-file": {    "driver": "fd," "fd": "5"  } }} And then qemu doesn't even have a reason to know that there is something called CA.

> but I think the real solution is that > libvirt should handle the storage formats completely and it should > present QEMU with only a raw file like interface (read/write/seek) for > the data. Then any backing files would be handled within libvirt. > Performance could suffer, though. I like your humour. :-)