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. Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list