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``
|
``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.
|
||||||
|
|
||||||
|
@ -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``
|
||||||
|
@ -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.
|
||||||
|
|
||||||
|
@ -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:
|
||||||
|
|
||||||
::
|
::
|
||||||
|
@ -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)`.
|
||||||
|
@ -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
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
Loading…
Reference in New Issue
Block a user