[libvirt] [PATCH 1/6] Introduce new domain create APIs to pass pre-opened FDs to LXC

Daniel P. Berrange berrange at redhat.com
Mon Jul 15 09:56:32 UTC 2013


On Sat, Jul 13, 2013 at 01:35:53PM +0800, Daniel Veillard wrote:
> On Fri, Jul 12, 2013 at 04:38:27PM +0100, Daniel P. Berrange wrote:
> > From: "Daniel P. Berrange" <berrange at redhat.com>
> > 
> > With container based virt, it is useful to be able to pass
> > pre-opened file descriptors to the container init process.
> > This allows for containers to be auto-activated from incoming
> > socket connections, passing the active socket into the container.
> > 
> > To do this, introduce a pair of new APIs, virDomainCreateXMLWithFiles
> > and virDomainCreateWithFiles, which accept an array of file
> > descriptors. For the LXC driver, UNIX file descriptor passing
> > will be used to send them to libvirtd, which will them pass
> > them down to libvirt_lxc, which will then pass them to the container
> > init process.
> > 
> > This will only be implemented for LXC right now, but the design
> > is generic enough it could work with other hypervisors, hence
> > I suggest adding this to libvirt.so, rather than libvirt-lxc.so
> > 
> > Signed-off-by: Daniel P. Berrange <berrange at redhat.com>
> [...]
> >  /**
> > + * virDomainCreateXMLWithFiles:
> > + * @conn: pointer to the hypervisor connection
> > + * @xmlDesc: string containing an XML description of the domain
> > + * @nfiles: number of file descriptors passed
> > + * @files: list of file descriptors passed
> > + * @flags: bitwise-OR of supported virDomainCreateFlags
> > + *
> > + * Launch a new guest domain, based on an XML description similar
> > + * to the one returned by virDomainGetXMLDesc()
> > + * This function may require privileged access to the hypervisor.
> > + * The domain is not persistent, so its definition will disappear when it
> > + * is destroyed, or if the host is restarted (see virDomainDefineXML() to
> > + * define persistent domains).
> > + *
> > + * @files provides an array of file descriptors which will be
> > + * made available to the 'init' process of the guest. The file
> > + * handles exposed to the guest will be renumbered to start
> > + * from 3 (ie immediately following stderr). This is only
> > + * supported for guests which use container based virtualization
> > + * technology.
> 
>   Hum, at least now the semantic is clear so big improvement from v1,
> but can we avoid that magic '3' buried here, and add a firstfile or
> start file which would give the start index. This extension is already
> very specific to LXC, no need to make it more specific than needed,
> maybe other container technologies would appreciate to pass stdin
> or start from a higher boundary.

I don't think we want that. The reason for starting from 3 is that the
application inheriting the file descriptor can immediately discover
whether it has been passed any file descriptors, by checking whether
FD 3 is open or not. If we allowed arbitrary offset, then the application
has much more complex code to determine if it has inherited any FDs.

>   We must specify what a negative fd passed in the array means, it
> could mean don't override the existing fd if opened, or close that fd
> etc ... this extensions could then be used for purpose we don't expect
> just from as systemd->LXC current use case.

Use of a negative FD is not allowed - you can't pass across a closed
FD with SCM_RIGHTS of course, so there's no way to represent that in
the remote protocol.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|




More information about the libvir-list mailing list