On Thu, Jul 21, 2011 at 11:25 AM, Kevin Wolf <kwolf@xxxxxxxxxx> wrote:
> 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.
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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list