Re: [Qemu-devel] live snapshot wiki updated

[Blue Swirl]

On Wed, Jul 20, 2011 at 8:47 PM, Eric Blake <address@hidden> wrote:
> On 07/20/2011 11:27 AM, Blue Swirl wrote:
>>>
>>> We've already told you - qemu must have a way to be passed fds which are
>>> associated with names, and when a file refers to another backing file by
>>> name, then qemu falls back on its fd/name mapping to use the
>>> already-passed
>>> fd instead.  Which implies that someone else, either libvirt or a
>>> qemu-maintained libblockformat.so, needs to have a stable interface for
>>> parsing the backing file name out of an arbitrary qcow2 file, and that
>>> this
>>> interface must work no matter how many other extensions are added to
>>> qcow2.
>>
>> I'd avoid any name based access in this case. If QEMU has write access
>> to main file, it could forge the backing file name in main file to
>> point to for example /etc/shadow and then request libvirt to perform
>> the opening.
>
> Won't work.  Well, it might work within the context of a single qemu
> process.  But when that process ends, then libvirt would have to touch up
> the qcow2 headers of that file to replace the /etc/shadow name with the real
> backing file name, otherwise, the next time you restart qemu-img or a new
> qemu guest using the same image, the information has been lost, since the fd
> has been closed in the meantime.

How would libvirt know to do this touch up?

> We really _do_ need a way to give qemu both an fd and the name of the file
> that the fd is tied to.  On Linux, qemu could use /proc/self/fd to
> reconstruct the name from fd, but that's not portable to other OS.  And
> we've already discussed how in the libvirt model, that libvirt is deemed
> more secure than qemu.  Therefore, I think it is reasonable for qemu to make
> the assumptions that if it exposes a monitor command where the supervisor
> (libvirt or otherwise) can pass in both an fd and a file name, that either
> the supervisor is passing in correct information, or that the bug is in the
> supervisor and not in qemu if the supervisor passes in wrong information and
> things blow up.

Yes, I'm not worried about QEMU getting confused by libvirt.

> And the snapshot_blkdev monitor command is a case where qemu needs to create
> a new qcow2 image on the fly, while referencing the name of an existing
> file.  What backing name do you put in the new qcow2 file unless you already
> have a name association for all fds already open for the existing backing
> file?

For backing file with original name of "/path/in/storage", QEMU could
present the fd and the backin path by requesting something like
"fd:12,/path/in/storage". The next file in chain "/path2/file" would
be "fd:12,fd:34,/path2/file". Or if possible, -fd 12 -backing
/path/in/storage with spaces and funny characters escaped etc.