External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 13:45:38 +00:00
Code Issues Packages Projects Releases Wiki 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`` ``server``
Present only for a pull mode backup. Contains the same attributes as the 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), 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 necessary to set up an NBD server that exposes the content of each disk at
the time the backup is started. the time the backup is started.
@ -61,7 +61,7 @@ were supplied). The following child elements and attributes are supported:
``name`` ``name``
A mandatory attribute which must match the ``<target dev='name'/>`` of 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. for the domain at the time of the checkpoint.
``backup`` ``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 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 make sense outside of the backup. The same applies for the block device
which must be formatted appropriately. Similarly to the domain 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`` and ``target`` can contain ``seclabel`` and/or ``encryption``
subelements to configure the corresponding properties. 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`` ``name``
A mandatory attribute which must match either the A mandatory attribute which must match either the
``<target dev='name'/>`` or an unambiguous ``<source file='name'/>`` of ``<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. for the domain at the time of the checkpoint.
``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, (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 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 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>`__ interfaces <#elementsNICS>`__, and `USB and PCI devices <#elementsHostDev>`__
sections below) were introduced and they are the preferred way providing full sections below) were introduced and they are the preferred way providing full
control over booting order. The ``boot`` element and per-device boot elements control over booting order. The ``boot`` element and per-device boot elements
@ -1186,12 +1186,13 @@ Block I/O Tuning
``device`` ``device``
The domain may have multiple ``device`` elements that further tune the 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 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 disks (See `Hard drives, floppy disks, CDROMs`_) can share a single host
they are backed by files within the same host file system, which is why this block device, if they are backed by files within the same host file system,
tuning parameter is at the global domain level rather than associated with which is why this tuning parameter is at the global domain level rather than
each guest disk device (contrast this to the `<iotune> <#elementsDisks>`__ associated with each guest disk device (contrast this to the <iotune>
element which can apply to an individual ``<disk>``). Each ``device`` element element of a disk definition (See `Hard drives, floppy disks, CDROMs`_)
has two mandatory sub-elements, ``path`` describing the absolute path of the 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 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, range [100, 1000]. After kernel 2.6.39, the value could be in the range [10,
1000]. :since:`Since 0.9.8` 1000]. :since:`Since 0.9.8`
@ -2331,7 +2332,6 @@ following characters: ``[a-zA-Z0-9_-]``. :since:`Since 3.9.0`
... ...
</devices> </devices>
:anchor:`<a id="elementsDisks"/>`
Hard drives, floppy disks, CDROMs Hard drives, floppy disks, CDROMs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -4118,7 +4118,7 @@ or:
"unfiltered", where the default is "filtered". The optional ``rawio`` ( "unfiltered", where the default is "filtered". The optional ``rawio`` (
:since:`since 1.2.9` ) attribute indicates whether the lun needs the 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 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. already has the rawio capability, then this setting not required.
``scsi_host`` ``scsi_host``
:since:`since 2.5.0` For SCSI devices, user is responsible to make sure :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 :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 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 same ``name`` attribute and optionally using the ``auth`` element to
provide the authentication credentials to the iSCSI server. 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 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 `storage volume <formatstorage.html#storage-volume-xml>`__ in order to provide
the passphrase to encrypt the volume or in domain XML 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: 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 ``<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 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 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 (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: 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``. using ``virsh secret-set-value``.
The ceph secret can then be used by UUID or by the usage name via the ``<auth>`` 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: 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 ``<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 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 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 (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 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 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``. using ``virsh secret-set-value``.
The iSCSI secret can then be used by UUID or by the usage name via the 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: 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. This sub-element describes the snapshot properties of a specific disk.
The attribute ``name`` is mandatory, and must match either the ``<target The attribute ``name`` is mandatory, and must match either the ``<target
dev='name'/>`` (recommended) or an unambiguous ``<source file='name'/>`` 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 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`` is optional, and the possible values are the same as the
``snapshot`` attribute for `disk devices ``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 ``external``). Some hypervisors like ESX require that if specified, the
snapshot mode must not override any snapshot mode attached to the snapshot mode must not override any snapshot mode attached to the
corresponding domain disk, while others like qemu allow this field to 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 overwrite the default ``file`` type. The ``type`` attribute along with
the format of the ``source`` sub-element is identical to the ``source`` the format of the ``source`` sub-element is identical to the ``source``
element used in domain disk definitions. See the `disk devices 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 information. Libvirt currently supports the ``type`` element in the qemu
driver and supported values are ``file``, ``block`` and ``network`` driver and supported values are ``file``, ``block`` and ``network``
:since:`(since 1.2.2)`. :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. 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 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 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 images can be attached to QEMU guests. Information about attaching a
Sheepdog image to a guest can be found at the `format 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 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 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 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 Valid Gluster pool format types
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~