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

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(a)redhat.com&gt; > > > > 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.