mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-25 01:34:11 +03:00
a8ea89d258
Historically we have used a bare xen:/// URI for connecting to the legacy Xen driver. The new libxl Xen driver follows the new practice of allowing '/system' as a path, as well as bare '/' for compat with the old Xen driver. This documents xen:///system as the preferred format for Xen, leaving xen:/// as an undocumented feature just for back-compat. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
266 lines
8.7 KiB
XML
266 lines
8.7 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html>
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<body>
|
|
<h1 >Connection URIs</h1>
|
|
|
|
<ul id="toc"></ul>
|
|
<p>
|
|
Since libvirt supports many different kinds of virtualization
|
|
(often referred to as "drivers" or "hypervisors"), we need a
|
|
way to be able to specify which driver a connection refers to.
|
|
Additionally we may want to refer to a driver on a remote
|
|
machine over the network.
|
|
</p>
|
|
<p>
|
|
To this end, libvirt uses URIs as used on the Web and as defined in <a href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>. This page
|
|
documents libvirt URIs.
|
|
</p>
|
|
<h2><a id="URI_libvirt">Specifying URIs to libvirt</a></h2>
|
|
|
|
<p>
|
|
The URI is passed as the <code>name</code> parameter to
|
|
<a href="html/libvirt-libvirt-host.html#virConnectOpen">
|
|
<code>virConnectOpen</code>
|
|
</a>
|
|
or
|
|
<a href="html/libvirt-libvirt-host.html#virConnectOpenReadOnly">
|
|
<code>virConnectOpenReadOnly</code>
|
|
</a>.
|
|
For example:
|
|
</p>
|
|
<pre>
|
|
virConnectPtr conn = virConnectOpenReadOnly (<b>"test:///default"</b>);
|
|
</pre>
|
|
<h2>
|
|
<a id="URI_config">Configuring URI aliases</a>
|
|
</h2>
|
|
|
|
<p>
|
|
To simplify life for administrators, it is possible to setup URI aliases in a
|
|
libvirt client configuration file. The configuration file is <code>/etc/libvirt/libvirt.conf</code>
|
|
for the root user, or <code>$XDG_CONFIG_HOME/libvirt/libvirt.conf</code> for any unprivileged user.
|
|
In this file, the following syntax can be used to setup aliases
|
|
</p>
|
|
|
|
<pre>
|
|
uri_aliases = [
|
|
"hail=qemu+ssh://root@hail.cloud.example.com/system",
|
|
"sleet=qemu+ssh://root@sleet.cloud.example.com/system",
|
|
]
|
|
</pre>
|
|
|
|
<p>
|
|
A URI alias should be a string made up from the characters
|
|
<code>a-Z, 0-9, _, -</code>. Following the <code>=</code>
|
|
can be any libvirt URI string, including arbitrary URI parameters.
|
|
URI aliases will apply to any application opening a libvirt
|
|
connection, unless it has explicitly passed the <code>VIR_CONNECT_NO_ALIASES</code>
|
|
parameter to <code>virConnectOpenAuth</code>. If the passed in
|
|
URI contains characters outside the allowed alias character
|
|
set, no alias lookup will be attempted.
|
|
</p>
|
|
|
|
<h2><a id="URI_default">Default URI choice</a></h2>
|
|
|
|
<p>
|
|
If the URI passed to <code>virConnectOpen*</code> is NULL, then libvirt will use the following
|
|
logic to determine what URI to use.
|
|
</p>
|
|
|
|
<ol>
|
|
<li>The environment variable <code>LIBVIRT_DEFAULT_URI</code></li>
|
|
<li>The client configuration file <code>uri_default</code> parameter</li>
|
|
<li>Probe each hypervisor in turn until one that works is found</li>
|
|
</ol>
|
|
|
|
<h2>
|
|
<a id="URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a>
|
|
</h2>
|
|
<p>
|
|
In virsh use the <code>-c</code> or <code>--connect</code> option:
|
|
</p>
|
|
<pre>
|
|
virsh <b>-c test:///default</b> list
|
|
</pre>
|
|
<p>
|
|
If virsh finds the environment variable
|
|
<code>VIRSH_DEFAULT_CONNECT_URI</code> set, it will try this URI by
|
|
default. Use of this environment variable is, however, deprecated
|
|
now that libvirt supports <code>LIBVIRT_DEFAULT_URI</code> itself.
|
|
</p>
|
|
<p>
|
|
When using the interactive virsh shell, you can also use the
|
|
<code>connect</code> <i>URI</i> command to reconnect to another
|
|
hypervisor.
|
|
</p>
|
|
<p>
|
|
In virt-manager use the <code>-c</code> or <code>--connect=</code><i>URI</i> option:
|
|
</p>
|
|
<pre>
|
|
virt-manager <b>-c test:///default</b>
|
|
</pre>
|
|
<p>
|
|
In virt-install use the <code>--connect=</code><i>URI</i> option:
|
|
</p>
|
|
<pre>
|
|
virt-install <b>--connect=test:///default</b> <i>[other options]</i>
|
|
</pre>
|
|
<h2>
|
|
<a id="URI_xen">xen:///system URI</a>
|
|
</h2>
|
|
<p>
|
|
<i>This section describes a feature which is new in libvirt >
|
|
0.2.3. For libvirt ≤ 0.2.3 use <a href="#URI_legacy_xen"><code>"xen"</code></a>.</i>
|
|
</p>
|
|
<p>
|
|
To access a Xen hypervisor running on the local machine
|
|
use the URI <code>xen:///system</code>.
|
|
</p>
|
|
<h2>
|
|
<a id="URI_qemu">qemu:///... QEMU and KVM URIs</a>
|
|
</h2>
|
|
<p>
|
|
To use QEMU support in libvirt you must be running the
|
|
<code>libvirtd</code> daemon (named <code>libvirt_qemud</code>
|
|
in releases prior to 0.3.0). The purpose of this
|
|
daemon is to manage qemu instances.
|
|
</p>
|
|
<p>
|
|
The <code>libvirtd</code> daemon should be started by the
|
|
init scripts when the machine boots. It should appear as
|
|
a process <code>libvirtd --daemon</code> running as root
|
|
in the background and will handle qemu instances on behalf
|
|
of all users of the machine (among other things). </p>
|
|
<p>
|
|
So to connect to the daemon, one of two different URIs is used:
|
|
</p>
|
|
<ul>
|
|
<li><code>qemu:///system</code> connects to a system mode daemon. </li>
|
|
<li><code>qemu:///session</code> connects to a session mode daemon. </li>
|
|
</ul>
|
|
<p>
|
|
(If you do <code>libvirtd --help</code>, the daemon will print
|
|
out the paths of the Unix domain socket(s) that it listens on in
|
|
the various different modes).
|
|
</p>
|
|
<p>
|
|
KVM URIs are identical. You select between qemu, qemu accelerated and
|
|
KVM guests in the <a href="format.html#KVM1">guest XML as described
|
|
here</a>.
|
|
</p>
|
|
<h2>
|
|
<a id="URI_remote">Remote URIs</a>
|
|
</h2>
|
|
<p>
|
|
Remote URIs are formed by taking ordinary local URIs and adding a
|
|
hostname and/or transport name. As a special case, using a URI
|
|
scheme of 'remote', will tell the remote libvirtd server to probe
|
|
for the optimal hypervisor driver. This is equivalent to passing
|
|
a NULL URI for a local connection. For example:
|
|
</p>
|
|
<table class="top_table">
|
|
<tr>
|
|
<th> Local URI </th>
|
|
<th> Remote URI </th>
|
|
<th> Meaning </th>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>xen:///system</code>
|
|
</td>
|
|
<td>
|
|
<code>xen://oirase/system</code>
|
|
</td>
|
|
<td> Connect to the Xen hypervisor running on host <code>oirase</code>
|
|
using TLS. </td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>NULL</code>
|
|
</td>
|
|
<td>
|
|
<code>remote://oirase/</code>
|
|
</td>
|
|
<td> Connect to the "default" hypervisor running on host <code>oirase</code>
|
|
using TLS. </td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>xen:///system</code>
|
|
</td>
|
|
<td>
|
|
<code>xen+ssh://oirase/system</code>
|
|
</td>
|
|
<td> Connect to the Xen hypervisor running on host <code>oirase</code>
|
|
by going over an <code>ssh</code> connection. </td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<code>test:///default</code>
|
|
</td>
|
|
<td>
|
|
<code>test+tcp://oirase/default</code>
|
|
</td>
|
|
<td> Connect to the test driver on host <code>oirase</code>
|
|
using an unsecured TCP connection. </td>
|
|
</tr>
|
|
</table>
|
|
<p>
|
|
Remote URIs in libvirt offer a rich syntax and many features.
|
|
We refer you to <a href="remote.html#Remote_URI_reference">the libvirt
|
|
remote URI reference</a> and <a href="remote.html">full documentation
|
|
for libvirt remote support</a>.
|
|
</p>
|
|
<h2>
|
|
<a id="URI_test">test:///... Test URIs</a>
|
|
</h2>
|
|
<p>
|
|
The test driver is a dummy hypervisor for test purposes.
|
|
The URIs supported are:
|
|
</p>
|
|
<ul>
|
|
<li><code>test:///default</code> connects to a default set of
|
|
host definitions built into the driver. </li>
|
|
<li><code>test:///path/to/host/definitions</code> connects to
|
|
a set of host definitions held in the named file.
|
|
</li>
|
|
</ul>
|
|
<h2>
|
|
<a id="URI_legacy">Other & legacy URI formats</a>
|
|
</h2>
|
|
<h3>
|
|
<a id="URI_NULL">NULL and empty string URIs</a>
|
|
</h3>
|
|
<p>
|
|
Libvirt allows you to pass a <code>NULL</code> pointer to
|
|
<code>virConnectOpen*</code>. Empty string (<code>""</code>) acts in
|
|
the same way. Traditionally this has meant
|
|
<q>connect to the local Xen hypervisor</q>. However in future this
|
|
may change to mean <q>connect to the best available hypervisor</q>.
|
|
</p>
|
|
<p>
|
|
The theory is that if, for example, Xen is unavailable but the
|
|
machine is running an OpenVZ kernel, then we should not try to
|
|
connect to the Xen hypervisor since that is obviously the wrong
|
|
thing to do.
|
|
</p>
|
|
<p>
|
|
In any case applications linked to libvirt can continue to pass
|
|
<code>NULL</code> as a default choice, but should always allow the
|
|
user to override the URI, either by constructing one or by allowing
|
|
the user to type a URI in directly (if that is appropriate). If your
|
|
application wishes to connect specifically to a Xen hypervisor, then
|
|
for future proofing it should choose a full <a href="#URI_xen"><code>xen:///system</code> URI</a>.
|
|
</p>
|
|
<h3>
|
|
<a id="URI_legacy_xen">Legacy: <code>"xen"</code></a>
|
|
</h3>
|
|
<p>
|
|
Another legacy URI is to specify name as the string
|
|
<code>"xen"</code>. This will continue to refer to the Xen
|
|
hypervisor. However you should prefer a full <a href="#URI_xen"><code>xen:///system</code> URI</a> in all future code.
|
|
</p>
|
|
</body>
|
|
</html>
|