[libvirt] [PATCH] RFC: Introduce new domain create APIs to pass pre-opened FDs to LXC

[Daniel P. Berrange]

On Wed, Jul 10, 2013 at 01:28:41PM +0800, Daniel Veillard wrote:
> On Tue, Jul 09, 2013 at 05:15:55PM +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
> 
>  No problem with the principle, but a bit confused by the arguments.
> 
> >  /**
> > + * 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. This is
> > + * only supported for guests which use container based virtualization
> > + * technology.
> 
>   Hum, say you want to pas 4 fd, one for 0 stdin, one for 1 stdout
> one for 2 stderr, and somehow one for 4 a preopened fd, what would the
> files and nfiles contain ?
> 
>  5 , [stdin, stdou, stderr, -1, fd4] ?
> 
> basically is -1 used for holes in the list, shouldn't we instead pair
> (index for fd, fd) and provide an array of them ?

The container already has stdin/out/err preset by libvirt and won't be
changed here. This is about passing in additional FDs beyond that, so
fd >= 3. I'm not intending to support arbitrary mapping of FD numbers,
these are just exposed to the guest linearly from FD==3 onwards. So if
you pass an array containing 5 FDs, they'll get exposed to the guest
as FD numbers 3, 4, 5, 6, 7.

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 :|