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

Re: [Libvir] Preliminary patch to support remote driver / libvirtd



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)


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