docs: formatdomain: Remove 'elementsDisks' anchor

Two paragraphs containing local links were reformulated and rewrapped.

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

diff --git a/docs/formatbackup.rst b/docs/formatbackup.rst
index c378ad9d9a199dffcabd29256a20280e0ddbcfd6..02847fd5d49c975bd7443cf9d651c1649e2ff520 100644 (file)
--- 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 ff3f1e8c00c3a51c177045fdb1b6a6fbb845636f..496de4e1ff95c5457a9da625bc3822d7720db65c 100644 (file)
--- 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 4f85366c9d0b685743f1aaa138c4919d24ba35bf..d1134c523ffc23d294eccbdeecebae1d086a8de1 100644 (file)
--- 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 03c28368434d35b8ad0e05f955906309662f1223..03274300783aa72eabb7d5b56858abd0e6074662 100644 (file)
--- 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 dd742a30635444920aae9f9edc231f87e209521f..07aa03c0a758e48dd39f30297fc76c9066066e1b 100644 (file)
--- 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 b86064862801b5aa43aefd27cc642a9aae7a9f36..9d5b193e319e1d5f061a5daa67538f36e723bb8c 100644 (file)
--- 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~