[Libvir] Preliminary patch to support remote driver / libvirtd

[Richard W.M. Jones]

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)