From nobody Sun Feb 8 22:00:11 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1728395183838462.1575216466438; Tue, 8 Oct 2024 06:46:23 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id BD08F15DE; Tue, 8 Oct 2024 09:46:22 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 438B714F0; Tue, 8 Oct 2024 09:44:25 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 8D8401430; Tue, 8 Oct 2024 09:44:19 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 4F89615D9 for ; Tue, 8 Oct 2024 09:44:10 -0400 (EDT) Received: from mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-499-QyVI0rR9MR2ojZVjpREODA-1; Tue, 08 Oct 2024 09:44:08 -0400 Received: from mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id C93B8195608F for ; Tue, 8 Oct 2024 13:44:07 +0000 (UTC) Received: from speedmetal.redhat.com (unknown [10.45.242.12]) by mx-prod-int-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 082A819560AA for ; Tue, 8 Oct 2024 13:44:06 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1728395050; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sD5K6Dqw3KrMqlMSKg7fvNuNBURwbpuRui/f7l/YMgU=; b=Z9Uc4O6jxiq8K2o7t7rAflHJFsSHRtADbxfCDWRBmcnStdmrpV12vWZWEA7onsE3i4qhs5 /lhaJr1bf56NMrTpC/s7fcXIcmNxsSS8W+lrPiS4isd8l4bL/bKzSvMzmg4++2i40x9TaI lUIpJQaCqQIZ+YsxRP1WvmlMTpisZ9U= X-MC-Unique: QyVI0rR9MR2ojZVjpREODA-1 From: Peter Krempa To: devel@lists.libvirt.org Subject: [PATCH 4/6] docs: Use relative links within the web page Date: Tue, 8 Oct 2024 15:43:57 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.40 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: WPJP5KO3EPEHDVCP6K5DNHNB34FIPPTF X-Message-ID-Hash: WPJP5KO3EPEHDVCP6K5DNHNB34FIPPTF X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1728395185389116600 Content-Type: text/plain; charset="utf-8" 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 --- docs/api_extension.rst | 4 +--- docs/issue-handling.rst | 2 +- docs/kbase/backing_chains.rst | 4 ++-- docs/kbase/debuglogs.rst | 4 ++-- docs/kbase/internals/incremental-backup.rst | 6 +++--- docs/kbase/launch_security_sev.rst | 2 +- docs/kbase/live_full_disk_backup.rst | 2 +- docs/kbase/merging_disk_image_chains.rst | 6 ++---- docs/kbase/rpm-deployment.rst | 2 +- docs/kbase/s390_protected_virt.rst | 2 +- docs/kbase/systemtap.rst | 2 +- docs/securityprocess.rst | 2 +- docs/testtck.rst | 2 +- docs/windows.rst | 5 ++--- 14 files changed, 20 insertions(+), 25 deletions(-) diff --git a/docs/api_extension.rst b/docs/api_extension.rst index a42c82daca..b9f701dd11 100644 --- a/docs/api_extension.rst +++ b/docs/api_extension.rst @@ -23,9 +23,7 @@ Adding a new API to libvirt is not difficult, but there a= re 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: - -https://libvirt.org/downloads.html +out and build the code can be found at the `downloads `__ = page. Once you have a working development environment, the steps to create a new API are: diff --git a/docs/issue-handling.rst b/docs/issue-handling.rst index cfde53f876..b4269e01b7 100644 --- a/docs/issue-handling.rst +++ b/docs/issue-handling.rst @@ -178,5 +178,5 @@ community. .. _Untriaged issues: https://gitlab.com/libvirt/libvirt/-/issues/?sort=3D= created_date&state=3Dopened¬%5Blabel_name%5D%5B%5D=3Dstate%3A%3Aunconfir= med¬%5Blabel_name%5D%5B%5D=3Dstate%3A%3Aneedinfo¬%5Blabel_name%5D%5B%= 5D=3Dstate%3A%3Aconfirmed&first_page_size=3D100 .. _Unconfirmed bugs: https://gitlab.com/libvirt/libvirt/-/issues/?sort=3D= created_date&state=3Dopened&label_name%5B%5D=3Dkind%3A%3Abug&label_name%5B%= 5D=3Dstate%3A%3Aunconfirmed&first_page_size=3D100 .. _Unconfirmed features: https://gitlab.com/libvirt/libvirt/-/issues/?sor= t=3Dcreated_date&state=3Dopened&label_name%5B%5D=3Dkind%3A%3Aenhancement&la= bel_name%5B%5D=3Dstate%3A%3Aunconfirmed&first_page_size=3D100 -.. _debug logs: https://libvirt.org/kbase/debuglogs.html +.. _debug logs: kbase/debuglogs.html .. _code of conduct: governance.html#code-of-conduct diff --git a/docs/kbase/backing_chains.rst b/docs/kbase/backing_chains.rst index 38a9a2337b..1c5e231195 100644 --- a/docs/kbase/backing_chains.rst +++ b/docs/kbase/backing_chains.rst @@ -97,8 +97,8 @@ specification can be used: This makes libvirt follow the settings as configured in the XML. Note that= this -is supported only when the https://libvirt.org/formatdomaincaps.html#backi= ngstoreinput -capability is present. +is supported only when the `backingStoreInput +<../formatdomaincaps.html#backingstoreinput>`_ capability is present. An empty ```` element signals the end of the chain. Using t= his will prevent libvirt or qemu from probing the backing chain. diff --git a/docs/kbase/debuglogs.rst b/docs/kbase/debuglogs.rst index dff2cfd144..f8c05b6922 100644 --- a/docs/kbase/debuglogs.rst +++ b/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 `__ influences which dae= mon -the client will communicate with. +The `connection URI <../uri.html>`__ influences which daemon the client wi= ll +communicate with. System daemon mode ~~~~~~~~~~~~~~~~~~ diff --git a/docs/kbase/internals/incremental-backup.rst b/docs/kbase/inter= nals/incremental-backup.rst index 29e90092e8..af464e8178 100644 --- a/docs/kbase/internals/incremental-backup.rst +++ b/docs/kbase/internals/incremental-backup.rst @@ -16,9 +16,9 @@ this document will try to summarize them. Glossary =3D=3D=3D=3D=3D=3D=3D=3D -See the knowledge base article on -`domain state capture `= _ for -a deeper explanation of some of the concepts. +See the knowledge base article on `domain state capture +<../domainstatecapture.html>`_ for a deeper explanation of some of the +concepts. Checkpoint diff --git a/docs/kbase/launch_security_sev.rst b/docs/kbase/launch_securit= y_sev.rst index 6a3740d297..cfde2c49dc 100644 --- a/docs/kbase/launch_security_sev.rst +++ b/docs/kbase/launch_security_sev.rst @@ -154,7 +154,7 @@ VM Configuration =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SEV is enabled in the XML by specifying the -` `= __ +` <../formatdomain.html#launch-security>`__ element. However, specifying ``launchSecurity`` isn't enough to boot an SEV VM. Further configuration requirements are discussed below. diff --git a/docs/kbase/live_full_disk_backup.rst b/docs/kbase/live_full_di= sk_backup.rst index f20169e314..f9dcd2a1bd 100644 --- a/docs/kbase/live_full_disk_backup.rst +++ b/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 `_, +`backing chains `_, `QCOW2 overlays `_, and a special operation called "active block-commit", which allows diff --git a/docs/kbase/merging_disk_image_chains.rst b/docs/kbase/merging_= disk_image_chains.rst index 9bff8da1af..40b565f74b 100644 --- a/docs/kbase/merging_disk_image_chains.rst +++ b/docs/kbase/merging_disk_image_chains.rst @@ -7,8 +7,7 @@ Merging disk image image chains Context =3D=3D=3D=3D=3D=3D=3D -Sometimes a `disk image chain -`_ can get long and +Sometimes a `disk image chain `_ 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. Her= e's how to go about it. The same principles used in the `live full disk backup -`_ document are -used here too. +`_ document are used here too. Reducing the disk image chain length =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/docs/kbase/rpm-deployment.rst b/docs/kbase/rpm-deployment.rst index 26fe1be8e6..ae2ed42eb6 100644 --- a/docs/kbase/rpm-deployment.rst +++ b/docs/kbase/rpm-deployment.rst @@ -370,7 +370,7 @@ RPM packages * libvirt-docs - A local copy of the `libvirt website `_ website con= tent + A local copy of the libvirt website website content that matches the deployed version of libvirt. * libvirt-libs diff --git a/docs/kbase/s390_protected_virt.rst b/docs/kbase/s390_protected= _virt.rst index a8c627931b..faacd6fc7a 100644 --- a/docs/kbase/s390_protected_virt.rst +++ b/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 -` `= __ +` <../formatdomain.html#launch-security>`__ element with type ``s390-pv`` should be used on protected virtualization g= uests. Without ``launchSecurity`` you must enable all virtio devices to use shared buffers by configuring them with platform_iommu enabled. diff --git a/docs/kbase/systemtap.rst b/docs/kbase/systemtap.rst index 8a3acabdf7..5d4717b7aa 100644 --- a/docs/kbase/systemtap.rst +++ b/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 `__): +`libvirt compiling <../compiling.html>`__): :: diff --git a/docs/securityprocess.rst b/docs/securityprocess.rst index 1f5176ec75..075679df74 100644 --- a/docs/securityprocess.rst +++ b/docs/securityprocess.rst @@ -35,7 +35,7 @@ format in the `libvirt-security-notice GIT repository `__ and `published online `__ in text, HTML and XML formats. Security notices are published on the `libvirt-announce mailing -list `__ when any embargo = is +list `__ when any embargo is lifted, or as soon as triaged if already public knowledge. Security team diff --git a/docs/testtck.rst b/docs/testtck.rst index 568899dcdd..621dadf0db 100644 --- a/docs/testtck.rst +++ b/docs/testtck.rst @@ -101,7 +101,7 @@ script containing functions describing GitLab job defin= itions 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 `__). Make sure that the +`virtiofs `__). Make sure that the user which is going to execute the following has passwordless "sudo" permi= ssions (lcitool's default "test" user does). Then it's just a matter of running diff --git a/docs/windows.rst b/docs/windows.rst index ee3caef41a..37fd8e02d9 100644 --- a/docs/windows.rst +++ b/docs/windows.rst @@ -54,9 +54,8 @@ Connecting to VMware ESX/vSphere -------------------------------- Details on the capabilities, certificates, and connection string syntax us= ed for -connecting to VMware ESX and vSphere can be found online here: - -https://libvirt.org/drvesx.html +connecting to VMware ESX and vSphere can be found on the +`ESX driver `_ page. TLS Certificates ---------------- --=20 2.46.0