[libvirt] [PATCH v3] Add support for fd: protocol

[Eric Blake]

On 07/26/2011 06:51 AM, Corey Bryant wrote:
> There are some additional features provided by certain image types
> where Qemu reopens the image file. All of these scenarios will be
> unsupported for the fd: protocol, at least for this patch:
>
>    - The -snapshot command line option
>    - The savevm monitor command
>    - The snapshot_blkdev monitor command
>    - Use of copy-on-write image files
>    - The -cdrom command line option
>    - The -drive command line option with media=cdrom
>    - The change monitor command
>
> The thought is that this support can be added in the future, but is
> not required for the initial fd: support.

Libvirt will eventually need support for fd passing on savevm, 
snapshot_blkdev, and change monitor commands, as well as for -cdrom, 
before this feature can be used to provide the desired security 
enhancements.  I agree that for an incremental patch, you don't have to 
solve all points at once, but until all places have been modified to 
support fd usage, you aren't gaining any security, except for severely 
constrained guests.

Furthermore, how do you plan to map fd: to filename?  There's already 
been big threads on why snapshot_blkdev needs both the new fd: and the 
name of the old backing file at the same time, so that qemu can write 
the correct headers into new qcow2 files.  But your proposal precludes 
that, since "qemu -drive file=fd:4,format=qcow2" is not letting qemu 
know the file name of fd:4 that would later have to be written into a 
qcow2 header.  I'm afraid that we need a better solution that gets both 
fd and filename mapped together, before this stands a chance of being 
useful.  That said, I'm strongly in favor of getting the open() burden 
moved out of qemu into libvirt, because of the potential it has for 
increased security.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org