On Wed, Jul 10, 2013 at 09:31:52AM +0100, Daniel P. Berrange wrote: > 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@xxxxxxxxxx> > > > > > > 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. Okay, let's just make that clear :-) Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard@xxxxxxxxxx | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list