Remote support

Libvirt allows you to access hypervisors running on remote machines through authenticated and encrypted connections.

Basic usage

On the remote machine, libvirtd should be running in general. See the section on configuring libvirtd for more information.

Not all hypervisors supported by libvirt require a running libvirtd. If you want to connect to a VMware ESX/ESXi or GSX server then libvirtd is not necessary. See the VMware ESX page for details.

To tell libvirt that you want to access a remote resource, you should supply a hostname in the normal URI that is passed to virConnectOpen (or virsh -c ...). For example, if you normally use qemu:///system to access the system-wide QEMU daemon, then to access the system-wide QEMU daemon on a remote machine called compute1.libvirt.org you would use qemu://compute1.libvirt.org/system.

The section on remote URIs describes in more detail these remote URIs.

From an API point of view, apart from the change in URI, the API should behave the same. For example, ordinary calls are routed over the remote connection transparently, and values or errors from the remote side are returned to you as if they happened locally. Some differences you may notice:

Additional errors can be generated, specifically ones relating to failures in the remote transport itself.
Remote calls are handled synchronously, so they will be much slower than, say, direct hypervisor calls.

Transports

Remote libvirt supports a range of transports:

tls: TLS 1.0 (SSL 3.1) authenticated and encrypted TCP/IP socket, usually listening on a public port number. To use this you will need to generate client and server certificates. The standard port is 16514.
unix: Unix domain socket. Since this is only accessible on the local machine, it is not encrypted, and uses Unix permissions or SELinux for authentication. The standard socket names are /var/run/libvirt/libvirt-sock and /var/run/libvirt/libvirt-sock-ro (the latter for read-only connections).
ssh: Transported over an ordinary ssh (secure shell) connection. Requires Netcat (nc) installed and libvirtd should be running on the remote machine. You should use some sort of ssh key management (eg. ssh-agent) otherwise programs which use this transport will stop to ask for a password.
ext: Any external program which can make a connection to the remote machine by means outside the scope of libvirt.
tcp: Unencrypted TCP/IP socket. Not recommended for production use, this is normally disabled, but an administrator can enable it for testing or use over a trusted network. The standard port is 16509.
libssh2: Transport over the SSH protocol using libssh2 instead of the OpenSSH binary. This transport uses the libvirt authentication callback for all ssh authentication calls and therefore supports keyboard-interactive authentication even with graphical management applications. As with the classic ssh transport netcat is required on the remote side.
libssh: Transport over the SSH protocol using libssh instead of the OpenSSH binary. This transport uses the libvirt authentication callback for all ssh authentication calls and therefore supports keyboard-interactive authentication even with graphical management applications. As with the classic ssh transport netcat is required on the remote side.

The default transport, if no other is specified, is tls.

Remote URIs

Remote URIs have the general form ("[...]" meaning an optional part):

driver[+transport]://[username@][hostname][:port]/[path][?extraparameters]

Either the transport or the hostname must be given in order to distinguish this from a local URI.

Some examples:

xen+ssh://rjones@towada/system
— Connect to a remote Xen hypervisor on host towada using ssh transport and ssh username rjones.
xen://towada/system
— Connect to a remote Xen hypervisor on host towada using TLS.
xen://towada/system?no_verify=1
— Connect to a remote Xen hypervisor on host towada using TLS. Do not verify the server's certificate.
qemu+unix:///system?socket=/opt/libvirt/run/libvirt/libvirt-sock
— Connect to the local qemu instances over a non-standard Unix socket (the full path to the Unix socket is supplied explicitly in this case).
test+tcp://localhost:5000/default
— Connect to a libvirtd daemon offering unencrypted TCP/IP connections on localhost port 5000 and use the test driver with default settings.
qemu+libssh2://user@host/system?known_hosts=/home/user/.ssh/known_hosts
— Connect to a remote host using a ssh connection with the libssh2 driver and use a different known_hosts file.
qemu+libssh://user@host/system?known_hosts=/home/user/.ssh/known_hosts
— Connect to a remote host using a ssh connection with the libssh driver and use a different known_hosts file.

Extra parameters

Extra parameters can be added to remote URIs as part of the query string (the part following ?). Remote URIs understand the extra parameters shown below. Any others are passed unmodified through to the back end. Note that parameter values must be URI-escaped.

Name	Transports	Meaning
`name`	any transport	The name passed to the remote virConnectOpen function. The name is normally formed by removing transport, hostname, port number, username and extra parameters from the remote URI, but in certain very complex cases it may be better to supply the name explicitly.
		Example: `name=qemu:///system`
`tls_priority`	tls	A vaid GNUTLS priority string
		Example: `tls_priority=NORMAL:-VERS-SSL3.0`
`mode`	unix, ssh, libssh, libssh2	`auto` automatically determine the daemon `direct` connect to per-driver daemons `legacy` connect to libvirtd Can also be set in `libvirt.conf` as `remote_mode`
		Example: `mode=direct`
`command`	ssh, ext	The external command. For ext transport this is required. For ssh the default is `ssh`. The PATH is searched for the command.
		Example: `command=/opt/openssh/bin/ssh`
`socket`	unix, ssh, libssh2, libssh	The path to the Unix domain socket, which overrides the compiled-in default. For ssh transport, this is passed to the remote netcat command (see next).
		Example: `socket=/opt/libvirt/run/libvirt/libvirt-sock`
`netcat`	ssh, libssh2, libssh	The name of the netcat command on the remote machine. The default is `nc`. For ssh transport, libvirt constructs an ssh command which looks like: command -p port [-l username] hostname netcat -U socket where port, username, hostname can be specified as part of the remote URI, and command, netcat and socket come from extra parameters (or sensible defaults).
		Example: `netcat=/opt/netcat/bin/nc`
`keyfile`	ssh, libssh2, libssh	The name of the private key file to use to authentication to the remote machine. If this option is not used the default keys are used.
		Example: `keyfile=/root/.ssh/example_key`
`no_verify`	ssh, tls	SSH: If set to a non-zero value, this disables client's strict host key checking making it auto-accept new host keys. Existing host keys will still be validated. TLS: If set to a non-zero value, this disables client checks of the server's certificate. Note that to disable server checks of the client's certificate or IP address you must change the libvirtd configuration.
		Example: `no_verify=1`
`no_tty`	ssh	If set to a non-zero value, this stops ssh from asking for a password if it cannot log in to the remote machine automatically (eg. using ssh-agent etc.). Use this when you don't have access to a terminal - for example in graphical programs which use libvirt.
		Example: `no_tty=1`
`pkipath`	tls	Specifies x509 certificates path for the client. If any of the CA certificate, client certificate, or client key is missing, the connection will fail with a fatal error.
		Example: `pkipath=/tmp/pki/client`
`known_hosts`	libssh2, libssh	Path to the known_hosts file to verify the host key against. LibSSH2 and libssh support OpenSSH-style known_hosts files, although LibSSH2 does not support all key types, so using files created by the OpenSSH binary may result into truncating the known_hosts file. Thus, with LibSSH2 it's recommended to use the default known_hosts file is located in libvirt's client local configuration directory e.g.: ~/.config/libvirt/known_hosts. Note: Use absolute paths.
		Example: `known_hosts=/root/.ssh/known_hosts`
`sshauth`	libssh2, libssh	A comma separated list of authentication methods to use. Default (is "agent,privkey,password,keyboard-interactive". The order of the methods is preserved. Some methods may require additional parameters.
		Example: `sshauth=privkey,agent`

libvirtd configuration file

Libvirtd (the remote daemon) is configured from a file called /etc/libvirt/libvirtd.conf, or specified on the command line using -f filename or --config filename.

This file should contain lines of the form below. Blank lines and comments beginning with # are ignored.

setting = value

The following settings, values and default are:

Line	Default	Meaning
listen_tls [0\|1]	1 (on)	Listen for secure TLS connections on the public TCP/IP port. Note: it is also necessary to start the server in listening mode by running it with --listen or editing /etc/sysconfig/libvirtd by uncommenting the LIBVIRTD_ARGS="--listen" line to cause the server to come up in listening mode whenever it is started.
listen_tcp [0\|1]	0 (off)	Listen for unencrypted TCP connections on the public TCP/IP port. Note: it is also necessary to start the server in listening mode.
tls_port "service"	"16514"	The port number or service name to listen on for secure TLS connections.
tcp_port "service"	"16509"	The port number or service name to listen on for unencrypted TCP connections.
unix_sock_group "groupname"	"root"	The UNIX group to own the UNIX domain socket. If the socket permissions allow group access, then applications running under matching group can access the socket. Only valid if running as root
unix_sock_ro_perms "octal-perms"	"0777"	The permissions for the UNIX domain socket for read-only client connections. The default allows any user to monitor domains.
unix_sock_rw_perms "octal-perms"	"0700"	The permissions for the UNIX domain socket for read-write client connections. The default allows only root to manage domains.
tls_no_verify_certificate [0\|1]	0 (certificates are verified)	If set to 1 then if a client certificate check fails, it is not an error.
tls_no_verify_address [0\|1]	0 (addresses are verified)	If set to 1 then if a client IP address check fails, it is not an error.
key_file "filename"	"/etc/pki/libvirt/ private/serverkey.pem"	Change the path used to find the server's private key. If you set this to an empty string, then no private key is loaded.
cert_file "filename"	"/etc/pki/libvirt/ servercert.pem"	Change the path used to find the server's certificate. If you set this to an empty string, then no certificate is loaded.
ca_file "filename"	"/etc/pki/CA/cacert.pem"	Change the path used to find the trusted CA certificate. If you set this to an empty string, then no trusted CA certificate is loaded.
crl_file "filename"	(no CRL file is used)	Change the path used to find the CA certificate revocation list (CRL) file. If you set this to an empty string, then no CRL is loaded.
tls_allowed_dn_list ["DN1", "DN2"]	(none - DNs are not checked)	Enable an access control list of client certificate Distinguished Names (DNs) which can connect to the TLS port on this server. The default is that DNs are not checked. This list may contain wildcards such as `"C=GB,ST=London,L=London,O=Libvirt Project,CN="` See the POSIX `fnmatch` function for the format of the wildcards. Note that if this is an empty list, no client can connect*. Note also that GnuTLS returns DNs without spaces after commas between the fields (and this is what we check against), but the `openssl x509` tool shows spaces.

IPv6 support

The libvirtd service and libvirt remote client driver both use the getaddrinfo() functions for name resolution and are thus fully IPv6 enabled. ie, if a server has IPv6 address configured the daemon will listen for incoming connections on both IPv4 and IPv6 protocols. If a client has an IPv6 address configured and the DNS address resolved for a service is reachable over IPv6, then an IPv6 connection will be made, otherwise IPv4 will be used. In summary it should just 'do the right thing(tm)'.

Limitations

Fine-grained authentication: libvirt in general, but in particular the remote case should support more fine-grained authentication for operations, rather than just read-write/read-only as at present.

Please come and discuss these issues and more on the mailing list.