shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-21 13:34:06 +03:00
Code Releases Activity

docs: formatdomain: Remove 'elementsDisks' anchor

Browse Source 
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>
This commit is contained in:
Peter Krempa 2022-05-13 10:31:33 +02:00
parent dff53731ec
commit 4331a892d4
6 changed files with 26 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/formatbackup.rst
View File

@ -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.

2
docs/formatcheckpoint.rst
View File

@ -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``

21
docs/formatdomain.rst
View File

@ -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.

10
docs/formatsecret.rst
View File

@ -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:
::

6
docs/formatsnapshot.rst
View File

@ -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)`.

6
docs/storage.rst
View File

@ -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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~