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(a)redhat.com>
---
docs/uri.rst | 25 ++++---------------------
1 file changed, 4 insertions(+), 21 deletions(-)
diff --git a/docs/uri.rst b/docs/uri.rst
index 949032e0ff..80c2d780c3 100644
--- a/docs/uri.rst
+++ b/docs/uri.rst
@@ -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"``
~~~~~~~~~~~~~~~~~
--
2.35.1