Re: Preliminary patch to support remote driver / libvirtd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Before getting into more discussion on the URI issue, I'll copy the "Architecture & Notes" section here so that everyone can actually read it first.

/* Architecture and notes:
 *
 * virConnectOpen ("remote:....") invokes this driver.  Depending
 * on the exact contents of the ellipsis "...." in the name string
 * we will try some method to connect to a libvirtd daemon, running
 * on a remote machine (or sometimes running on the local machine).
 *
 * All other vir* calls made on this connection are forwarded
 * to the libvirtd daemon which carries out the requested action.
 * So for example if you call virDomainCreateLinux, then the
 * domain gets created on the remote machine, and virConnectListDomains
 * lists domains running on the remote machine.
 *
 * Connections can be authenticated and encrypted -- it depends
 * on the transport selected by the name string.
 *
 * The current implementation uses SunRPC layered over one of:
 *  - GnuTLS (an SSL/TLS library providing enterprise-level
 *      authentication and encryption)
 *  - a local Unix domain socket
 *  - ssh or another external program such as rsh
 *  - a plain TCP socket (unencrypted, not recommended for production)
 *
 * See http://et.redhat.com/~rjones/secure_rpc for an insight into
 * the thinking that went into the selection of SunRPC.  In
 * the future we may use a different RPC system - for example
 * XML-RPC would be a logical choice - so for now you should regard
 * the protocol used as private and subject to change in future
 * versions of libvirt without notice.
 *
 * The name string selects the transport to use and the type of
 * virtualisation at the remote end.  The general format is:
 *
 *  "remote:<protocol>:<path> var=value var=value ..."
 *
 * Some examples:
 *
 *  "remote:unix:/var/run/libvirtd/socket"
 *  "remote:tls:myxenserver"
 *  "remote:ssh:myserver name=qemud"
 *  "remote:ssh:myserver command=/opt/openssh/bin/ssh"
 *
 * The <protocol> is one of: tls, unix, ssh, ext or tcp.
 * The <path> is protocol specific:
 *
 *   Protocol   Path-format
 *   -----------------------------------------
 *   tls        hostname[:port]
 *   unix       Path to local socket
 *   ssh        hostname[:port]
 *   ext        Name or path of external program
 *   tcp        hostname[:port]
 *
 * For tls, the default port is 16514.  For tcp, the default port is
 * 16509 (but note that tcp is almost never enabled because it is
 * insecure - it's only there for testing).
 *
 * For ssh: The default port for ssh is 22.  You should configure ssh
 * so that it doesn't ask for a password (eg. using ssh-agent).  The
 * remote server should have a recent version of the the netcat program
 * installed as 'nc', and the remote libvirtd must be configured to
 * listen on a Unix domain socket.  The following full command is run:
 *   ssh -p $port $hostname nc -U /var/run/libvirtd/socket
 *
 * For ext: Only the command you specify is run.  It is up to you to
 * write this command so that it somehow makes a connection to a
 * remote libvirtd, and passes input and output over its stdin/stdout.
 *
 * The var=value pairs provide optional extra information:
 *
 *   Variable    Protocols     Meaning
 *   -----------------------------------------
 *   name        (all)         Name used in remote virConnectOpen
 *                               (default is NULL).
 *   command     ssh           Name or path of external program (instead
 *                               of "ssh").
 *
 * The value is %-escaped (just like URL encoding), so if you want it
 * to contain a literal space use "%20" or "+", if you want it to have
* a literal + character use "%2b", and for a literal % character use "%25".
 *
 * To provide some forwards compatibility, variables which are not
 * understood are ignored (but a warning is printed on stderr).
 *
 * Several shorthand syntaxes are available:
 *
 *   "remote:/var/run/libvirtd/socket"  connect to Unix domain socket
 *   "remote://server"                  connect to TLS socket on server
 *   "remote://server:9000"             connect to TLS server port 9000
 *
 * For the details of the implementation of SunRPC over GnuTLS, etc.
 * please see http://et.redhat.com/~rjones/secure_rpc which contains
 * simple code samples which will allow you to understand what's
 * going on here.
 */



--
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421
 "[Negative numbers] darken the very whole doctrines of the equations
 and make dark of the things which are in their nature excessively
 obvious and simple" (Francis Maseres FRS, mathematician, 1759)


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]