[libvirt] [PATCH v3 0/5] file descriptor passing using pass-fd

Eric Blake eblake at redhat.com
Wed Jun 20 11:24:56 UTC 2012


On 06/20/2012 02:31 AM, Daniel P. Berrange wrote:

>> This might mean that libvirt should only closefd the file when it
>> becomes unused (like after hot unplug); or that qemu must keep it open
>> internally even after closefd as long as the block device is still in use.
> 
> As it works today, the only time libvirt would call "closefd", is if
> the monitor command it was trying to use the FD with (eg drive_add)
> failed. If drive_add was successfully run, then libvirt would not be
> invoking closefd.

But right now, the only time libvirt uses 'getfd' is with commands like
'migrate' that implicitly close the fd after it is used by name; we
don't have any experience in using fds by '/dev/fd/nn' notation instead
of name.  It is the fact that /dev/fd/nn will allow us to use 'pass-fd'
in more situations in before, by dup()ing the fd, that libvirt all the
sudden becomes responsible for using 'closefd' at the appropriate moments.

I guess I can live with a rule that libvirt must not call 'closefd' on
any fd that it might later want to reassign to a new copy of the fd;
that is, with backing chains, if libvirt originally calls 'pass-fd
drive-virtio1' with an O_RDONLY fd and gets back 21, then libvirt must
not call 'closefd drive-virtio1' until it knows drive-virtio1 is no
longer needed.  Converting the 'drive-virtio1' fd to O_RDWR while still
keeping it at /dev/fd/21 could be done via 'pass-fd -f drive-virtio1',
where -f is an optional bool parameter to force a reassociation of a
given name back to the previously assigned value instead of the normal
error path for accidentally passing an fd to an already in-use name.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120620/63c266a2/attachment-0001.sig>


More information about the libvir-list mailing list