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@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 > > > > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx> > [...] > > /** > > + * 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list