docs/uri.html.in

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE html>
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4   <body>
   5     <h1 >Connection URIs</h1>
   6
   7     <ul id="toc"></ul>
   8     <p>
   9 Since libvirt supports many different kinds of virtualization
  10 (often referred to as "drivers" or "hypervisors"), we need a
  11 way to be able to specify which driver a connection refers to.
  12 Additionally we may want to refer to a driver on a remote
  13 machine over the network.
  14 </p>
  15     <p>
  16 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
  17 documents libvirt URIs.
  18 </p>
  19     <h2><a id="URI_libvirt">Specifying URIs to libvirt</a></h2>
  20
  21     <p>
  22       The URI is passed as the <code>name</code> parameter to
  23       <a href="html/libvirt-libvirt-host.html#virConnectOpen">
  24         <code>virConnectOpen</code>
  25       </a>
  26       or
  27       <a href="html/libvirt-libvirt-host.html#virConnectOpenReadOnly">
  28         <code>virConnectOpenReadOnly</code>
  29       </a>.
  30       For example:
  31 </p>
  32     <pre>
  33 virConnectPtr conn = virConnectOpenReadOnly (<b>"test:///default"</b>);
  34 </pre>
  35     <h2>
  36       <a id="URI_config">Configuring URI aliases</a>
  37     </h2>
  38
  39     <p>
  40 To simplify life for administrators, it is possible to setup URI aliases in a
  41 libvirt client configuration file. The configuration file is <code>/etc/libvirt/libvirt.conf</code>
  42 for the root user, or <code>$XDG_CONFIG_HOME/libvirt/libvirt.conf</code> for any unprivileged user.
  43 In this file, the following syntax can be used to setup aliases
  44     </p>
  45
  46 <pre>
  47 uri_aliases = [
  48   "hail=qemu+ssh://root@hail.cloud.example.com/system",
  49   "sleet=qemu+ssh://root@sleet.cloud.example.com/system",
  50 ]
  51 </pre>
  52
  53 <p>
  54   A URI alias should be a string made up from the characters
  55   <code>a-Z, 0-9, _, -</code>. Following the <code>=</code>
  56   can be any libvirt URI string, including arbitrary URI parameters.
  57   URI aliases will apply to any application opening a libvirt
  58   connection, unless it has explicitly passed the <code>VIR_CONNECT_NO_ALIASES</code>
  59   parameter to <code>virConnectOpenAuth</code>. If the passed in
  60   URI contains characters outside the allowed alias character
  61   set, no alias lookup will be attempted.
  62 </p>
  63
  64     <h2><a id="URI_default">Default URI choice</a></h2>
  65
  66     <p>
  67 If the URI passed to <code>virConnectOpen*</code> is NULL, then libvirt will use the following
  68 logic to determine what URI to use.
  69 </p>
  70
  71     <ol>
  72       <li>The environment variable <code>LIBVIRT_DEFAULT_URI</code></li>
  73       <li>The client configuration file <code>uri_default</code> parameter</li>
  74       <li>Probe each hypervisor in turn until one that works is found</li>
  75     </ol>
  76
  77     <h2>
  78       <a id="URI_virsh">Specifying URIs to virsh, virt-manager and virt-install</a>
  79     </h2>
  80     <p>
  81 In virsh use the <code>-c</code> or <code>--connect</code> option:
  82 </p>
  83     <pre>
  84 virsh <b>-c test:///default</b> list
  85 </pre>
  86     <p>
  87 If virsh finds the environment variable
  88 <code>VIRSH_DEFAULT_CONNECT_URI</code> set, it will try this URI by
  89 default. Use of this environment variable is, however, deprecated
  90 now that libvirt supports <code>LIBVIRT_DEFAULT_URI</code> itself.
  91 </p>
  92     <p>
  93 When using the interactive virsh shell, you can also use the
  94 <code>connect</code> <i>URI</i> command to reconnect to another
  95 hypervisor.
  96 </p>
  97     <p>
  98 In virt-manager use the <code>-c</code> or <code>--connect=</code><i>URI</i> option:
  99 </p>
 100     <pre>
 101 virt-manager <b>-c test:///default</b>
 102 </pre>
 103     <p>
 104 In virt-install use the <code>--connect=</code><i>URI</i> option:
 105 </p>
 106     <pre>
 107 virt-install <b>--connect=test:///default</b> <i>[other options]</i>
 108 </pre>
 109     <h2>
 110       <a id="URI_xen">xen:///system URI</a>
 111     </h2>
 112     <p>
 113       <i>This section describes a feature which is new in libvirt &gt;
 114 0.2.3.  For libvirt &#x2264; 0.2.3 use <a href="#URI_legacy_xen"><code>"xen"</code></a>.</i>
 115     </p>
 116     <p>
 117 To access a Xen hypervisor running on the local machine
 118 use the URI <code>xen:///system</code>.
 119 </p>
 120     <h2>
 121       <a id="URI_qemu">qemu:///... QEMU and KVM URIs</a>
 122     </h2>
 123     <p>
 124 To use QEMU support in libvirt you must be running the
 125 <code>libvirtd</code> daemon (named <code>libvirt_qemud</code>
 126 in releases prior to 0.3.0).  The purpose of this
 127 daemon is to manage qemu instances.
 128 </p>
 129     <p>
 130 The <code>libvirtd</code> daemon should be started by the
 131 init scripts when the machine boots. It should appear as
 132 a process <code>libvirtd --daemon</code> running as root
 133 in the background and will handle qemu instances on behalf
 134 of all users of the machine (among other things). </p>
 135     <p>
 136 So to connect to the daemon, one of two different URIs is used:
 137 </p>
 138     <ul>
 139       <li><code>qemu:///system</code> connects to a system mode daemon. </li>
 140       <li><code>qemu:///session</code> connects to a session mode daemon. </li>
 141     </ul>
 142     <p>
 143 (If you do <code>libvirtd --help</code>, the daemon will print
 144 out the paths of the Unix domain socket(s) that it listens on in
 145 the various different modes).
 146 </p>
 147     <p>
 148 KVM URIs are identical.  You select between qemu, qemu accelerated and
 149 KVM guests in the <a href="format.html#KVM1">guest XML as described
 150 here</a>.
 151 </p>
 152     <h2>
 153       <a id="URI_remote">Remote URIs</a>
 154     </h2>
 155     <p>
 156 Remote URIs are formed by taking ordinary local URIs and adding a
 157 hostname and/or transport name. As a special case, using a URI
 158 scheme of 'remote', will tell the remote libvirtd server to probe
 159 for the optimal hypervisor driver. This is equivalent to passing
 160 a NULL URI for a local connection. For example:
 161 </p>
 162     <table class="top_table">
 163       <tr>
 164         <th> Local URI </th>
 165         <th> Remote URI </th>
 166         <th> Meaning </th>
 167       </tr>
 168       <tr>
 169         <td>
 170           <code>xen:///system</code>
 171         </td>
 172         <td>
 173           <code>xen://oirase/system</code>
 174         </td>
 175         <td> Connect to the Xen hypervisor running on host <code>oirase</code>
 176   using TLS. </td>
 177       </tr>
 178       <tr>
 179         <td>
 180           <code>NULL</code>
 181         </td>
 182         <td>
 183           <code>remote://oirase/</code>
 184         </td>
 185         <td> Connect to the "default" hypervisor running on host <code>oirase</code>
 186   using TLS. </td>
 187       </tr>
 188       <tr>
 189         <td>
 190           <code>xen:///system</code>
 191         </td>
 192         <td>
 193           <code>xen+ssh://oirase/system</code>
 194         </td>
 195         <td> Connect to the Xen hypervisor running on host <code>oirase</code>
 196   by going over an <code>ssh</code> connection. </td>
 197       </tr>
 198       <tr>
 199         <td>
 200           <code>test:///default</code>
 201         </td>
 202         <td>
 203           <code>test+tcp://oirase/default</code>
 204         </td>
 205         <td> Connect to the test driver on host <code>oirase</code>
 206   using an unsecured TCP connection. </td>
 207       </tr>
 208     </table>
 209     <p>
 210 Remote URIs in libvirt offer a rich syntax and many features.
 211 We refer you to <a href="remote.html#Remote_URI_reference">the libvirt
 212 remote URI reference</a> and <a href="remote.html">full documentation
 213 for libvirt remote support</a>.
 214 </p>
 215     <h2>
 216       <a id="URI_test">test:///... Test URIs</a>
 217     </h2>
 218     <p>
 219 The test driver is a dummy hypervisor for test purposes.
 220 The URIs supported are:
 221 </p>
 222     <ul>
 223       <li><code>test:///default</code> connects to a default set of
 224 host definitions built into the driver. </li>
 225       <li><code>test:///path/to/host/definitions</code> connects to
 226 a set of host definitions held in the named file.
 227 </li>
 228     </ul>
 229     <h2>
 230       <a id="URI_legacy">Other &amp; legacy URI formats</a>
 231     </h2>
 232     <h3>
 233       <a id="URI_NULL">NULL and empty string URIs</a>
 234     </h3>
 235     <p>
 236 Libvirt allows you to pass a <code>NULL</code> pointer to
 237 <code>virConnectOpen*</code>.  Empty string (<code>""</code>) acts in
 238 the same way.  Traditionally this has meant
 239 <q>connect to the local Xen hypervisor</q>.  However in future this
 240 may change to mean <q>connect to the best available hypervisor</q>.
 241 </p>
 242     <p>
 243 The theory is that if, for example, Xen is unavailable but the
 244 machine is running an OpenVZ kernel, then we should not try to
 245 connect to the Xen hypervisor since that is obviously the wrong
 246 thing to do.
 247 </p>
 248     <p>
 249 In any case applications linked to libvirt can continue to pass
 250 <code>NULL</code> as a default choice, but should always allow the
 251 user to override the URI, either by constructing one or by allowing
 252 the user to type a URI in directly (if that is appropriate).  If your
 253 application wishes to connect specifically to a Xen hypervisor, then
 254 for future proofing it should choose a full <a href="#URI_xen"><code>xen:///system</code> URI</a>.
 255 </p>
 256     <h3>
 257       <a id="URI_legacy_xen">Legacy: <code>"xen"</code></a>
 258     </h3>
 259     <p>
 260 Another legacy URI is to specify name as the string
 261 <code>"xen"</code>.  This will continue to refer to the Xen
 262 hypervisor.  However you should prefer a full <a href="#URI_xen"><code>xen:///system</code> URI</a> in all future code.
 263 </p>
 264   </body>
 265 </html>