Am 20.07.2011 19:20, schrieb Blue Swirl:
> On Wed, Jul 20, 2011 at 4:51 PM, Kevin Wolf <kwolf@xxxxxxxxxx> 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. :-)
Kevin
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list