mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 05:35:25 +00:00
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>
This commit is contained in:
parent
dff53731ec
commit
4331a892d4
@ -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.
|
||||
|
||||
|
@ -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``
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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:
|
||||
|
||||
::
|
||||
|
@ -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)`.
|
||||
|
@ -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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
Loading…
Reference in New Issue
Block a user