docs: Use relative links within the web page

Replace full/external links which point to content within
'https://libvirt.org/' with relative links so that the web page works
fully locally.

This does not change the links in 'docs/manpages' as we want the
installed man page to work from everywhere (even when the local docs are
not installed) and the generated API docs which take links from the C
source.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>

docs/api_extension.rst

@@ -23,9 +23,7 @@ Adding a new API to libvirt is not difficult, but there are quite a few
 steps. This document assumes that you are familiar with C programming
 and have checked out the libvirt code from the source code repository
 and successfully built the existing tree. Instructions on how to check
-out and build the code can be found at:
+out and build the code can be found at the `downloads <downloads.html>`__ page.
-
-https://libvirt.org/downloads.html
 
 Once you have a working development environment, the steps to create a
 new API are:

docs/issue-handling.rst

@@ -178,5 +178,5 @@ community.
 .. _Untriaged issues: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened&not%5Blabel_name%5D%5B%5D=state%3A%3Aunconfirmed&not%5Blabel_name%5D%5B%5D=state%3A%3Aneedinfo&not%5Blabel_name%5D%5B%5D=state%3A%3Aconfirmed&first_page_size=100
 .. _Unconfirmed bugs: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened&label_name%5B%5D=kind%3A%3Abug&label_name%5B%5D=state%3A%3Aunconfirmed&first_page_size=100
 .. _Unconfirmed features: https://gitlab.com/libvirt/libvirt/-/issues/?sort=created_date&state=opened&label_name%5B%5D=kind%3A%3Aenhancement&label_name%5B%5D=state%3A%3Aunconfirmed&first_page_size=100
-.. _debug logs: https://libvirt.org/kbase/debuglogs.html
+.. _debug logs: kbase/debuglogs.html
 .. _code of conduct: governance.html#code-of-conduct

docs/kbase/backing_chains.rst

@@ -97,8 +97,8 @@ specification can be used:
  </disk>
 
 This makes libvirt follow the settings as configured in the XML. Note that this
-is supported only when the https://libvirt.org/formatdomaincaps.html#backingstoreinput
+is supported only when the `backingStoreInput
-capability is present.
+<../formatdomaincaps.html#backingstoreinput>`_ capability is present.
 
 An empty ``<backingStore/>`` element signals the end of the chain. Using this
 will prevent libvirt or qemu from probing the backing chain.

docs/kbase/debuglogs.rst

@@ -120,8 +120,8 @@ Libvirt daemons run either in the ``system`` mode or on ``session`` (user)
 mode, depending on the configuration of the host and available permission
 levels.
 
-The `connection URI <https://libvirt.org/uri.html>`__ influences which daemon
+The `connection URI <../uri.html>`__ influences which daemon the client will
-the client will communicate with.
+communicate with.
 
 System daemon mode
 ~~~~~~~~~~~~~~~~~~

docs/kbase/internals/incremental-backup.rst

@@ -16,9 +16,9 @@ this document will try to summarize them.
 Glossary
 ========
 
-See the knowledge base article on
+See the knowledge base article on `domain state capture
-`domain state capture <https://libvirt.org/kbase/domainstatecapture.html>`_ for
+<../domainstatecapture.html>`_ for a deeper explanation of some of the
-a deeper explanation of some of the concepts.
+concepts.
 
 Checkpoint
 

docs/kbase/launch_security_sev.rst

@@ -154,7 +154,7 @@ VM Configuration
 ================
 
 SEV is enabled in the XML by specifying the
-`<launchSecurity> <https://libvirt.org/formatdomain.html#launch-security>`__
+`<launchSecurity> <../formatdomain.html#launch-security>`__
 element. However, specifying ``launchSecurity`` isn't enough to boot an
 SEV VM. Further configuration requirements are discussed below.
 

docs/kbase/live_full_disk_backup.rst

@@ -10,7 +10,7 @@ Overview
 Live full disk backups are preferred in many scenarios, *despite* their
 space requirements.  The following outlines an efficient method to do
 that using libvirt's APIs.  This method involves concepts: the notion of
-`backing chains <https://libvirt.org/kbase/backing_chains.html>`_,
+`backing chains <backing_chains.html>`_,
 `QCOW2 overlays
 <https://www.qemu.org/docs/master/interop/live-block-operations.html#disk-image-backing-chain-notation>`_,
 and a special operation called "active block-commit", which allows

docs/kbase/merging_disk_image_chains.rst

@@ -7,8 +7,7 @@ Merging disk image image chains
 Context
 =======
 
-Sometimes a `disk image chain
+Sometimes a `disk image chain <backing_chains.html>`_ can get long and
-<https://libvirt.org/kbase/backing_chains.html>`_ can get long and
 cumbersome.  For the purpose of illustration, consider this smaller disk
 image chain::
 
@@ -20,8 +19,7 @@ accomplish this *without* incurring guest down time.  Here's how to go
 about it.
 
 The same principles used in the `live full disk backup
-<https://libvirt.org/kbase/live_full_disk_backup.html>`_ document are
+<live_full_disk_backup.html>`_ document are used here too.
-used here too.
 
 Reducing the disk image chain length
 ====================================

docs/kbase/rpm-deployment.rst

@@ -370,7 +370,7 @@ RPM packages
 
 * libvirt-docs
 
-  A local copy of the `libvirt website <https://libvirt.org>`_ website content
+  A local copy of the libvirt website website content
   that matches the deployed version of libvirt.
 
 * libvirt-libs

docs/kbase/s390_protected_virt.rst

@@ -128,7 +128,7 @@ As the virtio data structures of secure guests are not accessible
 by the host, it is necessary to use shared memory ('bounce buffers').
 
 Since libvirt 7.6.0 the
-`<launchSecurity> <https://libvirt.org/formatdomain.html#launch-security>`__
+`<launchSecurity> <../formatdomain.html#launch-security>`__
 element with type ``s390-pv`` should be used on protected virtualization guests.
 Without ``launchSecurity`` you must enable all virtio devices to use shared
 buffers by configuring them with platform_iommu enabled.

docs/kbase/systemtap.rst

@@ -27,7 +27,7 @@ For libvirt before **6.7.0**, it can be configured by:
    ../configure --with-dtrace
 
 For libvirt **6.7.0** or later, configure it by the ``meson`` (seeing
-`libvirt compiling <https://libvirt.org/compiling.html>`__):
+`libvirt compiling <../compiling.html>`__):
 
 ::
 

docs/securityprocess.rst

@@ -35,7 +35,7 @@ format in the `libvirt-security-notice GIT
 repository <https://gitlab.com/libvirt/libvirt-security-notice>`__ and
 `published online <https://security.libvirt.org>`__ in text, HTML and XML
 formats. Security notices are published on the `libvirt-announce mailing
-list <https://libvirt.org/contact.html#mailing-lists>`__ when any embargo is
+list <contact.html#mailing-lists>`__ when any embargo is
 lifted, or as soon as triaged if already public knowledge.
 
 Security team

docs/testtck.rst

@@ -101,7 +101,7 @@ script containing functions describing GitLab job definitions it can be
 utilized to run integration test suite as well. In this case, one needs to
 get a copy of their libvirt repository containing the changes to be tested
 inside the VM (either by cloning it manually or sharing the repo e.g. via
-`virtiofs <https://libvirt.org/kbase/virtiofs.html>`__). Make sure that the
+`virtiofs <kbase/virtiofs.html>`__). Make sure that the
 user which is going to execute the following has passwordless "sudo" permissions
 (lcitool's default "test" user does). Then it's just a matter of running
 

docs/windows.rst

@@ -54,9 +54,8 @@ Connecting to VMware ESX/vSphere
 --------------------------------
 
 Details on the capabilities, certificates, and connection string syntax used for
-connecting to VMware ESX and vSphere can be found online here:
+connecting to VMware ESX and vSphere can be found on the
-
+`ESX driver <drvesx.html>`_ page.
-https://libvirt.org/drvesx.html
 
 TLS Certificates
 ----------------