External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-07-11 12:25:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: uri: Remove old 'NULL URI' section

Browse Source 
We now have an paragraph about default URI choice if the passed pointer
is NULL. Add the two related bits from the 'NULL and empty string URIs'
from the legacy section to the current one and remove the old stuff.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
Peter Krempa 2022-04-19 17:02:35 +02:00
parent ab301453bc
commit a18324f7e8
1 changed files with 4 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/uri.rst
View File

@ -51,13 +51,15 @@ outside the allowed alias character set, no alias lookup will be attempted.
Default URI choice
------------------
If the URI passed to ``virConnectOpen*`` is NULL, then libvirt will use the
following logic to determine what URI to use.
If the URI passed to ``virConnectOpen*`` is NULL or empty string, then libvirt
will use the following logic to determine what URI to use.
#. The environment variable ``LIBVIRT_DEFAULT_URI``
#. The client configuration file ``uri_default`` parameter
#. Probe each hypervisor in turn until one that works is found
Historically an empty URI was equivalent to ``xen:///system``.
Specifying URIs to virsh, virt-manager and virt-install
-------------------------------------------------------
@ -420,25 +422,6 @@ The test driver is a dummy hypervisor for test purposes. The URIs supported are:
Other & legacy URI formats
--------------------------
NULL and empty string URIs
~~~~~~~~~~~~~~~~~~~~~~~~~~
Libvirt allows you to pass a ``NULL`` pointer to ``virConnectOpen*``. Empty
string (``""``) acts in the same way. Traditionally this has meant “connect to
the local Xen hypervisor”. However in future this may change to mean “connect to
the best available hypervisor”.
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.
In any case applications linked to libvirt can continue to pass ``NULL`` 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
`xen:///system URI`_.
Legacy: ``"xen"``
~~~~~~~~~~~~~~~~~