On Thu, Jul 21, 2011 at 11:25 AM, Kevin Wolf <kwolf@redhat.com> wrote:
Am 20.07.2011 19:20, schrieb Blue Swirl:
On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf <kwolf@redhat.com> 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.
Yes, that's better.
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. :-)
Well, for some applications, security is more important than performance or convenience.