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 choice of transport is determined by the URI scheme, with tls as the default if no explicit transport is requested.

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 adding a LIBVIRTD_ARGS="--listen" line to /etc/sysconfig/libvirtd.
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="` Any matches in the string matches any number of consecutive characters, like a simplified `glob(7)`. 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. To make it easy to see the order of the fields in the DN a helper executable `virt-pki-query-dn` is provided for this particular use case.

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.