qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] live snapshot wiki updated


From: Kevin Wolf
Subject: Re: [Qemu-devel] live snapshot wiki updated
Date: Wed, 20 Jul 2011 15:51:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]