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(a)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(a)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 :|