[PATCH 20/67] docs: formatdomain: Remove 'elementsDisks' anchor

Two paragraphs containing local links were reformulated and rewrapped. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com&gt; --- 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