[Libvir] Preliminary patch to support remote driver / libvirtd

[Richard W.M. Jones]

This is the updated proposal for URIs.  Code to follow ...

/* Architecture and notes:
  *
  * virConnectOpen in this driver looks for remote URLs and will
  * try some method to connect to a libvirtd running on a remote
  * machine.
  *
  * Local URLs are the standard URLs used by other drivers -
  * for example "qemud:///system".
  *
  * Remote URLs contain either a server name or a remote transport
  * name.  For example: "qemud://server.example.com/system" contains
  * a server name (server.example.com), and "qemud+unix:///system"
  * contains a transport (unix).  Commonly remote URLs contain
  * both, for example: "qemud+tls://server.example.com/system"
  * (transport tls, server name server.example.com).
  *
  * 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.
  *
  * 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 URL (name parameter to virConnectOpen) is a URL of the
  * following general form:
  *
  *  "driver+transport://server:port/path?var=value&var=value&..."
  *
  * Transport, server and port are all optional (except that you must
  * have either transport or server as explained above).  You may
  * have zero or more variables (or omit the query string entirely).
  * Driver is the usual libvirt driver, as used on the remote
  * machine, and path is specific to driver.
  *
  * Some examples:
  *
  *  "xend://server/"              Remote xend, using TLS, port 16514
  *  "qemud+unix:///session"       Communicate over Unix domain socket
  *                                  to a local libvirtd.
  *  "qemud+ssh://server/session?command=/opt/openssh/bin/ssh"
  *                                Communicate over ssh to a remote
  *                                  libvirtd on server.  Control qemu
  *                                  on remote.  ssh command is located
  *                                  in a non-standard place.
  *  "qemud+tcp://server:5000/session"
  *                                Unencrypted TCP, port 5000.
  *  "xend+ext:///?command=my_shell_script"
  *                                Run my_shell_script which uses its own
  *                                method (eg. rsh, ssh, ...) to talk to
  *                                the remote libvirtd, controlling a
  *                                remote xend.
  *
  * [To emphasise - in ALL instances communication is with a remote
  * libvirtd, even if that remote libvirtd itself talks to another
  * daemon such as xend or qemud].
  *
  * The transport is one of: tls, unix, ssh, ext or tcp.  If no
  * transport is given, the default is to use tls.
  *
  * 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    Transport     Meaning
  *   -----------------------------------------
  *   command     ssh,ext       Name or path of external program.
  *                               For ssh this defaults to "ssh".
  *                               For ext you must supply it.
  *   name        (all)         Optionally the name used in remote
  *                               virConnectOpen.  The default is to
  *                               construct the name by removing
  *                               transport, server name, port and
  *                               variables from the remote URL to
  *                               form a local URL.  But if this
  *                               doesn't give the desired result you
  *                               may specify the exact name here.
  *   socket      unix,ssh,ext  Name of the Unix domain socket.  The
  *                               default is in <remote_internal.h>.
  *   netcat      ssh           Name of the netcat program on the
  *                               remote server.  Default is "nc".
  *
  * 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).
  *
  * 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)