[PATCH 20/67] docs: formatdomain: Remove 'elementsDisks' anchor
Peter Krempa
pkrempa at redhat.com
Tue May 31 15:05:55 UTC 2022
Two paragraphs containing local links were reformulated and rewrapped.
Signed-off-by: Peter Krempa <pkrempa at redhat.com>
---
docs/formatbackup.rst | 6 +++---
docs/formatcheckpoint.rst | 2 +-
docs/formatdomain.rst | 21 +++++++++++----------
docs/formatsecret.rst | 10 +++++-----
docs/formatsnapshot.rst | 6 +++---
docs/storage.rst | 6 +++---
6 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/docs/formatbackup.rst b/docs/formatbackup.rst
index c378ad9d9a..02847fd5d4 100644
--- a/docs/formatbackup.rst
+++ b/docs/formatbackup.rst
@@ -37,7 +37,7 @@ were supplied). The following child elements and attributes are supported:
``server``
Present only for a pull mode backup. Contains the same attributes as the
- ```protocol`` element of a disk <formatdomain.html#elementsDisks>`__ attached
+ ```protocol`` element of a disk <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ attached
via NBD in the domain (such as transport, socket, name, port, or tls),
necessary to set up an NBD server that exposes the content of each disk at
the time the backup is started.
@@ -61,7 +61,7 @@ were supplied). The following child elements and attributes are supported:
``name``
A mandatory attribute which must match the ``<target dev='name'/>`` of
- one of the `disk devices <formatdomain.html#elementsDisks>`__ specified
+ one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ specified
for the domain at the time of the checkpoint.
``backup``
@@ -122,7 +122,7 @@ were supplied). The following child elements and attributes are supported:
file is not deleted after the backup but the contents of the file don't
make sense outside of the backup. The same applies for the block device
which must be formatted appropriately. Similarly to the domain
- ```disk`` <formatdomain.html#elementsDisks>`__ definition ``scratch``
+ ```disk`` <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ definition ``scratch``
and ``target`` can contain ``seclabel`` and/or ``encryption``
subelements to configure the corresponding properties.
diff --git a/docs/formatcheckpoint.rst b/docs/formatcheckpoint.rst
index ff3f1e8c00..496de4e1ff 100644
--- a/docs/formatcheckpoint.rst
+++ b/docs/formatcheckpoint.rst
@@ -69,7 +69,7 @@ The top-level ``domaincheckpoint`` element may contain the following elements:
``name``
A mandatory attribute which must match either the
``<target dev='name'/>`` or an unambiguous ``<source file='name'/>`` of
- one of the `disk devices <formatdomain.html#elementsDisks>`__ specified
+ one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ specified
for the domain at the time of the checkpoint.
``checkpoint``
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index 4f85366c9d..d1134c523f 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -239,7 +239,7 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
(the sorted list is vda, vdb, hda, hdc). Similar domain with hdc, vda, vdb,
and hda disks will boot from hda (sorted disks are: hda, hdc, vda, vdb). It
can be tricky to configure in the desired way, which is why per-device boot
- elements (see `disks <#elementsDisks>`__, `network
+ elements (see `Hard drives, floppy disks, CDROMs`_, `network
interfaces <#elementsNICS>`__, and `USB and PCI devices <#elementsHostDev>`__
sections below) were introduced and they are the preferred way providing full
control over booting order. The ``boot`` element and per-device boot elements
@@ -1186,12 +1186,13 @@ Block I/O Tuning
``device``
The domain may have multiple ``device`` elements that further tune the
weights for each host block device in use by the domain. Note that multiple
- `guest disks <#elementsDisks>`__ can share a single host block device, if
- they are backed by files within the same host file system, which is why this
- tuning parameter is at the global domain level rather than associated with
- each guest disk device (contrast this to the `<iotune> <#elementsDisks>`__
- element which can apply to an individual ``<disk>``). Each ``device`` element
- has two mandatory sub-elements, ``path`` describing the absolute path of the
+ disks (See `Hard drives, floppy disks, CDROMs`_) can share a single host
+ block device, if they are backed by files within the same host file system,
+ which is why this tuning parameter is at the global domain level rather than
+ associated with each guest disk device (contrast this to the <iotune>
+ element of a disk definition (See `Hard drives, floppy disks, CDROMs`_)
+ which can applies to an individual disk). Each ``device`` element has
+ two mandatory sub-elements, ``path`` describing the absolute path of the
device, and ``weight`` giving the relative weight of that device, in the
range [100, 1000]. After kernel 2.6.39, the value could be in the range [10,
1000]. :since:`Since 0.9.8`
@@ -2331,7 +2332,6 @@ following characters: ``[a-zA-Z0-9_-]``. :since:`Since 3.9.0`
...
</devices>
-:anchor:`<a id="elementsDisks"/>`
Hard drives, floppy disks, CDROMs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -4118,7 +4118,7 @@ or:
"unfiltered", where the default is "filtered". The optional ``rawio`` (
:since:`since 1.2.9` ) attribute indicates whether the lun needs the rawio
capability. Valid settings are "yes" or "no". See the rawio description
- within the `disk <#elementsDisks>`__ section. If a disk lun in the domain
+ within the `Hard drives, floppy disks, CDROMs`_ section. If a disk lun in the domain
already has the rawio capability, then this setting not required.
``scsi_host``
:since:`since 2.5.0` For SCSI devices, user is responsible to make sure
@@ -4197,7 +4197,8 @@ or:
:since:`Since 1.2.8` , the ``source`` element of a SCSI device may contain
the ``protocol`` attribute. When the attribute is set to "iscsi", the host
- device XML follows the network `disk <#elementsDisks>`__ device using the
+ device XML follows the network disk device
+ (See `Hard drives, floppy disks, CDROMs`_) using the
same ``name`` attribute and optionally using the ``auth`` element to
provide the authentication credentials to the iSCSI server.
diff --git a/docs/formatsecret.rst b/docs/formatsecret.rst
index 03c2836843..0327430078 100644
--- a/docs/formatsecret.rst
+++ b/docs/formatsecret.rst
@@ -65,7 +65,7 @@ using ``virsh secret-set-value``.
The volume type secret can be supplied either in volume XML during creation of a
`storage volume <formatstorage.html#storage-volume-xml>`__ in order to provide
the passphrase to encrypt the volume or in domain XML
-`disk device <formatdomain.html#elementsDisks>`__ in order to provide the
+`disk device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ in order to provide the
passphrase to decrypt the volume, :since:`since 2.1.0` . An example follows:
::
@@ -101,7 +101,7 @@ This secret is associated with a Ceph RBD (rados block device). The
``<usage type='ceph'>`` element must contain a single ``name`` element that
specifies a usage name for the secret. The Ceph secret can then be used by UUID
or by this usage name via the ``<auth>`` element of a `disk
-device <formatdomain.html#elementsDisks>`__ or a `storage pool
+device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ or a `storage pool
(rbd) <formatstorage.html>`__. :since:`Since 0.9.7` . The following is an
example of the steps to be taken. First create a ceph-secret.xml file:
@@ -132,7 +132,7 @@ See `Setting secret values in virsh`_ on how to set the value of the secret
using ``virsh secret-set-value``.
The ceph secret can then be used by UUID or by the usage name via the ``<auth>``
-element in a domain's `<disk> <formatdomain.html#elementsDisks>`__ element as
+element in a domain's `<disk> <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ element as
follows:
::
@@ -157,7 +157,7 @@ This secret is associated with an iSCSI target for CHAP authentication. The
``<usage type='iscsi'>`` element must contain a single ``target`` element that
specifies a usage name for the secret. The iSCSI secret can then be used by UUID
or by this usage name via the ``<auth>`` element of a `disk
-device <formatdomain.html#elementsDisks>`__ or a `storage pool
+device <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ or a `storage pool
(iscsi) <formatstorage.html>`__. :since:`Since 1.0.4` . The following is an
example of the XML that may be used to generate a secret for iSCSI CHAP
authentication. Assume the following sample entry in an iSCSI authentication
@@ -207,7 +207,7 @@ See `Setting secret values in virsh`_ on how to set the value of the secret
using ``virsh secret-set-value``.
The iSCSI secret can then be used by UUID or by the usage name via the
-``<auth>`` element in a domain's `<disk> <formatdomain.html#elementsDisks>`__
+``<auth>`` element in a domain's `<disk> <formatdomain.html#hard-drives-floppy-disks-cdroms>`__
element as follows:
::
diff --git a/docs/formatsnapshot.rst b/docs/formatsnapshot.rst
index dd742a3063..07aa03c0a7 100644
--- a/docs/formatsnapshot.rst
+++ b/docs/formatsnapshot.rst
@@ -115,11 +115,11 @@ The top-level ``domainsnapshot`` element may contain the following elements:
This sub-element describes the snapshot properties of a specific disk.
The attribute ``name`` is mandatory, and must match either the ``<target
dev='name'/>`` (recommended) or an unambiguous ``<source file='name'/>``
- of one of the `disk devices <formatdomain.html#elementsDisks>`__
+ of one of the `disk devices <formatdomain.html#hard-drives-floppy-disks-cdroms>`__
specified for the domain at the time of the snapshot. The attribute
``snapshot`` is optional, and the possible values are the same as the
``snapshot`` attribute for `disk devices
- <formatdomain.html#elementsDisks>`__ (``no``, ``internal``, or
+ <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ (``no``, ``internal``, or
``external``). Some hypervisors like ESX require that if specified, the
snapshot mode must not override any snapshot mode attached to the
corresponding domain disk, while others like qemu allow this field to
@@ -140,7 +140,7 @@ The top-level ``domainsnapshot`` element may contain the following elements:
overwrite the default ``file`` type. The ``type`` attribute along with
the format of the ``source`` sub-element is identical to the ``source``
element used in domain disk definitions. See the `disk devices
- <formatdomain.html#elementsDisks>`__ section documentation for further
+ <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ section documentation for further
information. Libvirt currently supports the ``type`` element in the qemu
driver and supported values are ``file``, ``block`` and ``network``
:since:`(since 1.2.2)`.
diff --git a/docs/storage.rst b/docs/storage.rst
index b860648628..9d5b193e31 100644
--- a/docs/storage.rst
+++ b/docs/storage.rst
@@ -557,7 +557,7 @@ Example RBD disk attachment
RBD images can be attached to QEMU guests when QEMU is built with RBD support.
Information about attaching a RBD image to a guest can be found at `format
-domain <formatdomain.html#elementsDisks>`__ page.
+domain <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ page.
Valid RBD pool format types
~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -618,7 +618,7 @@ Example Sheepdog disk attachment
Sheepdog images can be attached to QEMU guests. Information about attaching a
Sheepdog image to a guest can be found at the `format
-domain <formatdomain.html#elementsDisks>`__ page.
+domain <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ page.
Valid Sheepdog pool format types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -698,7 +698,7 @@ Example Gluster disk attachment
Files within a gluster volume can be attached to QEMU guests. Information about
attaching a Gluster image to a guest can be found at the `format
-domain <formatdomain.html#elementsDisks>`__ page.
+domain <formatdomain.html#hard-drives-floppy-disks-cdroms>`__ page.
Valid Gluster pool format types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.35.3
More information about the libvir-list
mailing list