mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-22 05:35:25 +00:00
docs: Other fixes to :since: tags
Make sure that they're entirely contained within a single line and that punctuation is used in a way that doesn't make the resulting HTML look weird. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
parent
fd1dac6cd4
commit
96777db719
@ -443,8 +443,8 @@ e1000 NIC
|
||||
|
||||
As of `FreeBSD changeset
|
||||
r302504 <https://svnweb.freebsd.org/changeset/base/302504>`__ bhyve supports
|
||||
Intel e1000 network adapter emulation. It's supported in libvirt :since:`since
|
||||
3.1.0` and could be used as follows:
|
||||
Intel e1000 network adapter emulation. It's supported in libvirt
|
||||
:since:`since 3.1.0` and could be used as follows:
|
||||
|
||||
::
|
||||
|
||||
|
@ -56,8 +56,9 @@ URIs have this general form (``[...]`` marks an optional part).
|
||||
|
||||
type://[username@]hostname[:port]/[[folder/...]datacenter/[folder/...][cluster/]server][?extraparameters]
|
||||
|
||||
The ``type://`` is either ``esx://`` or ``gsx://`` or ``vpx://`` :since:`since
|
||||
0.8.3` . The driver selects the default port depending on the ``type://``. For
|
||||
The ``type://`` is either ``esx://`` or ``gsx://`` or ``vpx://``
|
||||
:since:`since 0.8.3`.
|
||||
The driver selects the default port depending on the ``type://``. For
|
||||
``esx://`` and ``vpx://`` the default HTTPS port is 443, for ``gsx://`` it is
|
||||
8333. If the port parameter is given, it overrides the default port.
|
||||
|
||||
@ -272,8 +273,8 @@ will complain if this restrictions are violated.
|
||||
- Memory size has to be a multiple of 4096
|
||||
- Number of virtual CPU has to be 1 or a multiple of 2. :since:`Since 4.10.0`
|
||||
any number of vCPUs is supported.
|
||||
- Valid MAC address prefixes are ``00:0c:29`` and ``00:50:56``. :since:`Since
|
||||
0.7.6` arbitrary `MAC addresses`_ are supported.
|
||||
- Valid MAC address prefixes are ``00:0c:29`` and ``00:50:56``.
|
||||
:since:`Since 0.7.6` arbitrary `MAC addresses`_ are supported.
|
||||
|
||||
Datastore references
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -148,11 +148,11 @@ The ``<guest/>`` element will typically wrap up the following elements:
|
||||
If present, 32-bit guests can use PAE address space extensions,
|
||||
:since:`since 0.4.1`
|
||||
``nonpae``
|
||||
If present, 32-bit guests can be run without requiring PAE, :since:`since
|
||||
0.4.1`
|
||||
If present, 32-bit guests can be run without requiring PAE,
|
||||
:since:`since 0.4.1`
|
||||
``ia64_be``
|
||||
If present, IA64 guests can be run in big-endian mode, :since:`since
|
||||
0.4.1`
|
||||
If present, IA64 guests can be run in big-endian mode,
|
||||
:since:`since 0.4.1`
|
||||
``acpi``
|
||||
If this element is present, the ``default`` attribute describes whether
|
||||
the hypervisor exposes ACPI to the guest by default, and the ``toggle``
|
||||
|
@ -201,8 +201,8 @@ harddisk, cdrom, network) determining where to obtain/find the boot image.
|
||||
``docs/interop/firmware.json`` in QEMU repository. Regular users do not need
|
||||
to bother. :since:`Since 5.2.0 (QEMU and KVM only)`
|
||||
For VMware guests, this is set to ``efi`` when the guest uses UEFI, and it is
|
||||
not set when using BIOS. :since:`Since 5.3.0 (VMware ESX and
|
||||
Workstation/Player)`
|
||||
not set when using BIOS.
|
||||
:since:`Since 5.3.0 (VMware ESX and Workstation/Player)`
|
||||
``type``
|
||||
The content of the ``type`` element specifies the type of operating system to
|
||||
be booted in the virtual machine. ``hvm`` indicates that the OS is one
|
||||
@ -409,8 +409,8 @@ and full virtualized guests.
|
||||
console (eg serial port), or the installation media source / kickstart file
|
||||
``dtb``
|
||||
The contents of this element specify the fully-qualified path to the
|
||||
(optional) device tree binary (dtb) image in the host OS. :since:`Since
|
||||
1.0.4`
|
||||
(optional) device tree binary (dtb) image in the host OS.
|
||||
:since:`Since 1.0.4`
|
||||
|
||||
Container boot
|
||||
~~~~~~~~~~~~~~
|
||||
@ -602,7 +602,7 @@ layout of sub-elements, with supported values of:
|
||||
validation and ``date`` format checking, all values are passed as strings
|
||||
to the hypervisor driver.
|
||||
``chassis``
|
||||
:since:`Since 4.1.0,` this is block 3 of SMBIOS, with entry names drawn
|
||||
:since:`Since 4.1.0`, this is block 3 of SMBIOS, with entry names drawn
|
||||
from:
|
||||
|
||||
``manufacturer``
|
||||
@ -689,8 +689,8 @@ CPU Allocation
|
||||
:since:`Since 0.4.4`
|
||||
``current``
|
||||
The optional attribute ``current`` can be used to specify whether fewer
|
||||
than the maximum number of virtual CPUs should be enabled. :since:`Since
|
||||
0.8.5`
|
||||
than the maximum number of virtual CPUs should be enabled.
|
||||
:since:`Since 0.8.5`
|
||||
``placement``
|
||||
The optional attribute ``placement`` can be used to indicate the CPU
|
||||
placement mode for domain process. The value can be either "static" or
|
||||
@ -887,8 +887,8 @@ CPU Tuning
|
||||
The optional ``period`` element specifies the enforcement interval (unit:
|
||||
microseconds). Within ``period``, each vCPU of the domain will not be allowed
|
||||
to consume more than ``quota`` worth of runtime. The value should be in range
|
||||
[1000, 1000000]. A period with value 0 means no value. :since:`Only QEMU
|
||||
driver support since 0.9.4, LXC since 0.9.10`
|
||||
[1000, 1000000]. A period with value 0 means no value.
|
||||
:since:`Only QEMU driver support since 0.9.4, LXC since 0.9.10`
|
||||
``quota``
|
||||
The optional ``quota`` element specifies the maximum allowed bandwidth (unit:
|
||||
microseconds). A domain with ``quota`` as any negative value indicates that
|
||||
@ -901,8 +901,8 @@ CPU Tuning
|
||||
The optional ``global_period`` element specifies the enforcement CFS
|
||||
scheduler interval (unit: microseconds) for the whole domain in contrast with
|
||||
``period`` which enforces the interval per vCPU. The value should be in range
|
||||
1000, 1000000]. A ``global_period`` with value 0 means no value. :since:`Only
|
||||
QEMU driver support since 1.3.3`
|
||||
1000, 1000000]. A ``global_period`` with value 0 means no value.
|
||||
:since:`Only QEMU driver support since 1.3.3`
|
||||
``global_quota``
|
||||
The optional ``global_quota`` element specifies the maximum allowed bandwidth
|
||||
(unit: microseconds) within a period for the whole domain. A domain with
|
||||
@ -915,8 +915,8 @@ CPU Tuning
|
||||
(unit: microseconds). Within ``emulator_period``, emulator threads (those
|
||||
excluding vCPUs) of the domain will not be allowed to consume more than
|
||||
``emulator_quota`` worth of runtime. The value should be in range [1000,
|
||||
1000000]. A period with value 0 means no value. :since:`Only QEMU driver
|
||||
support since 0.10.0`
|
||||
1000000]. A period with value 0 means no value.
|
||||
:since:`Only QEMU driver support since 0.10.0`
|
||||
``emulator_quota``
|
||||
The optional ``emulator_quota`` element specifies the maximum allowed
|
||||
bandwidth (unit: microseconds) for domain's emulator threads (those excluding
|
||||
@ -930,8 +930,8 @@ CPU Tuning
|
||||
(unit: microseconds) for IOThreads. Within ``iothread_period``, each IOThread
|
||||
of the domain will not be allowed to consume more than ``iothread_quota``
|
||||
worth of runtime. The value should be in range [1000, 1000000]. An
|
||||
iothread_period with value 0 means no value. :since:`Only QEMU driver support
|
||||
since 2.1.0`
|
||||
iothread_period with value 0 means no value.
|
||||
:since:`Only QEMU driver support since 2.1.0`
|
||||
``iothread_quota``
|
||||
The optional ``iothread_quota`` element specifies the maximum allowed
|
||||
bandwidth (unit: microseconds) for IOThreads. A domain with
|
||||
@ -939,8 +939,8 @@ CPU Tuning
|
||||
have infinite bandwidth, which means that it is not bandwidth controlled. The
|
||||
value should be in range [1000, 17592186044415] or less than 0. An
|
||||
``iothread_quota`` with value 0 means no value. You can use this feature to
|
||||
ensure that all IOThreads run at the same speed. :since:`Only QEMU driver
|
||||
support since 2.1.0`
|
||||
ensure that all IOThreads run at the same speed.
|
||||
:since:`Only QEMU driver support since 2.1.0`
|
||||
``vcpusched``, ``iothreadsched`` and ``emulatorsched``
|
||||
The optional ``vcpusched``, ``iothreadsched`` and ``emulatorsched`` elements
|
||||
specify the scheduler type (values ``batch``, ``idle``, ``fifo``, ``rr``) for
|
||||
@ -1064,7 +1064,7 @@ Memory Allocation
|
||||
for adding memory to the guest. The bounds are hypervisor specific. Note that
|
||||
due to alignment of the memory chunks added via memory hotplug the full size
|
||||
allocation specified by this element may be impossible to achieve.
|
||||
:since:`Since 1.2.14 supported by the QEMU driver.`
|
||||
:since:`Since 1.2.14 supported by the QEMU driver`.
|
||||
``currentMemory``
|
||||
The actual allocation of memory for the guest. This value can be less than
|
||||
the maximum allocation, to allow for ballooning up the guests memory on the
|
||||
@ -1679,8 +1679,8 @@ In case no restrictions need to be put on CPU model and its features, a simpler
|
||||
address bits for ``passthrough`` mode, i.e. in case the host CPU reports
|
||||
more bits than that, ``limit`` is used. :since:`Since 9.3.0`
|
||||
|
||||
Guest NUMA topology can be specified using the ``numa`` element. :since:`Since
|
||||
0.9.8`
|
||||
Guest NUMA topology can be specified using the ``numa`` element.
|
||||
:since:`Since 0.9.8`
|
||||
|
||||
::
|
||||
|
||||
@ -2037,8 +2037,9 @@ are:
|
||||
ACPI is useful for power management, for example, with KVM or HVF guests it
|
||||
is required for graceful shutdown to work.
|
||||
``apic``
|
||||
APIC allows the use of programmable IRQ management. :since:`Since 0.10.2
|
||||
(QEMU only)` there is an optional attribute ``eoi`` with values ``on`` and
|
||||
APIC allows the use of programmable IRQ management.
|
||||
:since:`Since 0.10.2 (QEMU only)` there is an optional
|
||||
attribute ``eoi`` with values ``on`` and
|
||||
``off`` which toggles the availability of EOI (End of Interrupt) for the
|
||||
guest.
|
||||
``hap``
|
||||
@ -2201,8 +2202,8 @@ are:
|
||||
``htm``
|
||||
Configure HTM (Hardware Transactional Memory) availability for pSeries guests.
|
||||
Possible values for the ``state`` attribute are ``on`` and ``off``. If the
|
||||
attribute is not defined, the hypervisor default will be used. :since:`Since
|
||||
4.6.0` (QEMU/KVM only)
|
||||
attribute is not defined, the hypervisor default will be used.
|
||||
:since:`Since 4.6.0` (QEMU/KVM only)
|
||||
``nested-hv``
|
||||
Configure nested HV availability for pSeries guests. This needs to be enabled
|
||||
from the host (L0) in order to be effective; having HV support in the (L1)
|
||||
@ -2215,8 +2216,8 @@ are:
|
||||
Some guests might require ignoring unknown Model Specific Registers (MSRs)
|
||||
reads and writes. It's possible to switch this by setting ``unknown``
|
||||
attribute of ``msrs`` to ``ignore``. If the attribute is not defined, or set
|
||||
to ``fault``, unknown reads and writes will not be ignored. :since:`Since
|
||||
5.1.0` (bhyve only)
|
||||
to ``fault``, unknown reads and writes will not be ignored.
|
||||
:since:`Since 5.1.0` (bhyve only)
|
||||
``ccf-assist``
|
||||
Configure ccf-assist (Count Cache Flush Assist) availability for pSeries
|
||||
guests. Possible values for the ``state`` attribute are ``on`` and ``off``.
|
||||
@ -2240,8 +2241,8 @@ are:
|
||||
``workaround`` (count cache flush), ``fixed-ibs`` (fixed by serializing
|
||||
indirect branches), ``fixed-ccd`` (fixed by disabling the cache count) and
|
||||
``fixed-na`` (fixed in hardware - no longer applicable). If the
|
||||
attribute is not defined, the hypervisor default will be used. :since:`Since
|
||||
6.3.0` (QEMU/KVM only)
|
||||
attribute is not defined, the hypervisor default will be used.
|
||||
:since:`Since 6.3.0` (QEMU/KVM only)
|
||||
``tcg``
|
||||
Various features to change the behavior of the TCG accelerator.
|
||||
|
||||
@ -2290,7 +2291,7 @@ Windows, however, expects it to be in so called 'localtime'.
|
||||
is hypervisor specific.
|
||||
``localtime``
|
||||
The guest clock will be synchronized to the host's configured timezone
|
||||
when booted, if any. :since:`Since 0.9.11,` the ``adjustment`` attribute
|
||||
when booted, if any. :since:`Since 0.9.11`, the ``adjustment`` attribute
|
||||
behaves the same as in 'utc' mode.
|
||||
``timezone``
|
||||
The guest clock will be synchronized to the requested timezone using the
|
||||
@ -2311,8 +2312,8 @@ Windows, however, expects it to be in so called 'localtime'.
|
||||
epoch timestamp.
|
||||
:since:`Since 8.4.0`.
|
||||
|
||||
A ``clock`` may have zero or more ``timer`` sub-elements. :since:`Since
|
||||
0.8.0`
|
||||
A ``clock`` may have zero or more ``timer`` sub-elements.
|
||||
:since:`Since 0.8.0`
|
||||
|
||||
``timer``
|
||||
Each timer element requires a ``name`` attribute, and has other optional
|
||||
@ -2956,12 +2957,12 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
``snapshot``
|
||||
The ``name`` attribute of ``snapshot`` element can optionally specify an
|
||||
internal snapshot name to be used as the source for storage protocols.
|
||||
Supported for 'rbd' :since:`since 1.2.11 (QEMU only).`
|
||||
Supported for 'rbd' :since:`since 1.2.11 (QEMU only)`.
|
||||
``config``
|
||||
The ``file`` attribute for the ``config`` element provides a fully
|
||||
qualified path to a configuration file to be provided as a parameter to
|
||||
the client of a networked storage protocol. Supported for 'rbd'
|
||||
:since:`since 1.2.11 (QEMU only).`
|
||||
:since:`since 1.2.11 (QEMU only)`.
|
||||
``auth``
|
||||
:since:`Since 3.9.0`, the ``auth`` element is supported for a
|
||||
disk ``type`` "network" that is using a ``source`` element with the
|
||||
@ -3095,7 +3096,7 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
|
||||
``backingStore``
|
||||
This element describes the backing store used by the disk specified by
|
||||
sibling ``source`` element. :since:`Since 1.2.4.` If the hypervisor driver
|
||||
sibling ``source`` element. :since:`Since 1.2.4`. If the hypervisor driver
|
||||
does not support the
|
||||
`backingStoreInput <formatdomaincaps.html#backingstoreinput>`__ (
|
||||
:since:`Since 5.10.0` ) domain feature the ``backingStore`` is ignored on
|
||||
@ -3190,8 +3191,8 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
this to the ``blkiotune`` element (See `Block I/O Tuning`_), which applies
|
||||
globally to the domain). Currently, the only tuning available is Block I/O
|
||||
throttling for qemu. This element has optional sub-elements; any sub-element
|
||||
not specified or given with a value of 0 implies no limit. :since:`Since
|
||||
0.9.8`
|
||||
not specified or given with a value of 0 implies no limit.
|
||||
:since:`Since 0.9.8`
|
||||
|
||||
``total_bytes_sec``
|
||||
The optional ``total_bytes_sec`` element is the total throughput limit in
|
||||
@ -3321,8 +3322,9 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
reduce the number of interrupts and exits for the guest. The default is
|
||||
determined by QEMU; usually if the feature is supported, default is on. In
|
||||
case there is a situation where this behavior is suboptimal, this
|
||||
attribute provides a way to force the feature off. :since:`Since 0.9.5
|
||||
(QEMU and KVM only)` **In general you should leave this option alone,
|
||||
attribute provides a way to force the feature off.
|
||||
:since:`Since 0.9.5 (QEMU and KVM only)`
|
||||
**In general you should leave this option alone,
|
||||
unless you are very certain you know what you are doing.**
|
||||
- The optional ``copy_on_read`` attribute controls whether to copy read
|
||||
backing file into the image file. The value can be either "on" or "off".
|
||||
@ -3332,8 +3334,8 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
- The optional ``discard`` attribute controls whether discard requests (also
|
||||
known as "trim" or "unmap") are ignored or passed to the filesystem. The
|
||||
value can be either "unmap" (allow the discard request to be passed) or
|
||||
"ignore" (ignore the discard request). :since:`Since 1.0.6 (QEMU and KVM
|
||||
only)`
|
||||
"ignore" (ignore the discard request).
|
||||
:since:`Since 1.0.6 (QEMU and KVM only)`
|
||||
- The optional ``detect_zeroes`` attribute controls whether to detect zero
|
||||
write requests. The value can be "off", "on" or "unmap". First two values
|
||||
turn the detection off and on, respectively. The third value ("unmap")
|
||||
@ -3347,8 +3349,9 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
`IOThreads Allocation`_). Multiple disks may be
|
||||
assigned to the same IOThread and are numbered from 1 to the domain
|
||||
iothreads value. Available for a disk device ``target`` configured to use
|
||||
"virtio" ``bus`` and "pci" or "ccw" ``address`` types. :since:`Since 1.2.8
|
||||
(QEMU 2.1)` *Note:* ``iothread`` is mutually exclusive with ``iothreads``.
|
||||
"virtio" ``bus`` and "pci" or "ccw" ``address`` types.
|
||||
:since:`Since 1.2.8 (QEMU 2.1)`
|
||||
*Note:* ``iothread`` is mutually exclusive with ``iothreads``.
|
||||
- The optional ``iothreads`` sub-element allows specifying multiple IOThreads
|
||||
via the ``iothread`` sub-element with attribute ``id`` the disk will use
|
||||
for I/O operations. Optionally the ``iothread`` element can have multiple
|
||||
@ -3390,8 +3393,8 @@ paravirtualized driver is specified via the ``disk`` element.
|
||||
image. When enabled, a discard request from within the guest will mark the
|
||||
qcow2 cluster as zero, but will keep the reference/offset of that cluster.
|
||||
But it will still pass the discard further to the lower layer.
|
||||
This will resolve fragmentation within the qcow2 image. :since:`Since 9.5.0
|
||||
(QEMU 8.1)`
|
||||
This will resolve fragmentation within the qcow2 image.
|
||||
:since:`Since 9.5.0 (QEMU 8.1)`
|
||||
|
||||
In the majority of cases the default configuration used by the hypervisor
|
||||
is sufficient so modifying this setting should not be necessary. For
|
||||
@ -3596,8 +3599,9 @@ A directory on the host that can be accessed directly from the guest.
|
||||
possible values are:
|
||||
|
||||
``mount``
|
||||
A host directory to mount in the guest. Used by LXC, OpenVZ :since:`(since
|
||||
0.6.2)` and QEMU/KVM :since:`(since 0.8.5)` . This is the default ``type``
|
||||
A host directory to mount in the guest. Used by LXC, OpenVZ
|
||||
:since:`(since 0.6.2)` and QEMU/KVM :since:`(since 0.8.5)`.
|
||||
This is the default ``type``
|
||||
if one is not specified. This mode also has an optional sub-element
|
||||
``driver``, with an attribute ``type='path'`` or ``type='handle'``
|
||||
:since:`(since 0.9.7)`. The driver block has an optional attribute
|
||||
@ -3652,8 +3656,9 @@ A directory on the host that can be accessed directly from the guest.
|
||||
|
||||
The filesystem element has optional attributes ``fmode`` and ``dmode``.
|
||||
These two attributes control the creation mode for files and directories
|
||||
when used with the ``mapped`` value for ``accessmode`` (:since:`since 6.10.0,
|
||||
requires QEMU 2.10` ). If not specified, QEMU creates files with mode
|
||||
when used with the ``mapped`` value for ``accessmode``
|
||||
(:since:`since 6.10.0, requires QEMU 2.10` ).
|
||||
If not specified, QEMU creates files with mode
|
||||
``600`` and directories with mode ``700``. The setuid, setgid, and sticky
|
||||
bit are unsupported.
|
||||
|
||||
@ -3772,8 +3777,9 @@ control where on the bus the device will be placed:
|
||||
0xff, inclusive), ``slot`` (a hex value between 0x0 and 0x1f, inclusive), and
|
||||
``function`` (a value between 0 and 7, inclusive). Also available is the
|
||||
``multifunction`` attribute, which controls turning on the multifunction bit
|
||||
for a particular slot/function in the PCI control register ( :since:`since
|
||||
0.9.7, requires QEMU 0.13` ). ``multifunction`` defaults to 'off', but should
|
||||
for a particular slot/function in the PCI control register
|
||||
( :since:`since 0.9.7, requires QEMU 0.13` ).
|
||||
``multifunction`` defaults to 'off', but should
|
||||
be set to 'on' for function 0 of a slot that will have multiple functions
|
||||
used. ( :since:`Since 4.10.0` ), PCI address extensions depending on the
|
||||
architecture are supported. For example, PCI addresses for S390 guests will
|
||||
@ -3799,7 +3805,7 @@ control where on the bus the device will be placed:
|
||||
``ccid``
|
||||
A CCID address, for smart-cards, has the following additional attributes:
|
||||
``bus`` (a 2-digit bus number), and ``slot`` attribute (a 2-digit slot within
|
||||
the bus). :since:`Since 0.8.8.`
|
||||
the bus). :since:`Since 0.8.8`.
|
||||
``usb``
|
||||
USB addresses have the following additional attributes: ``bus`` (a hex value
|
||||
between 0 and 0xfff, inclusive), and ``port`` (a dotted notation of up to
|
||||
@ -3810,7 +3816,7 @@ control where on the bus the device will be placed:
|
||||
assigned at a non-zero multiple of 0x00001000, but other addresses are valid
|
||||
and permitted by libvirt. Each address has the following additional
|
||||
attribute: ``reg`` (the hex value address of the starting register).
|
||||
:since:`Since 0.9.9.`
|
||||
:since:`Since 0.9.9`.
|
||||
``ccw``
|
||||
S390 guests with a ``machine`` value of s390-ccw-virtio use the native CCW
|
||||
bus for I/O devices. CCW bus addresses have the following additional
|
||||
@ -3993,8 +3999,8 @@ An optional sub-element ``driver`` can specify the driver specific options:
|
||||
matching the number of vCPUs. :since:`Since 1.0.5 (QEMU and KVM only)`
|
||||
``cmd_per_lun``
|
||||
The optional ``cmd_per_lun`` attribute specifies the maximum number of
|
||||
commands that can be queued on devices controlled by the host. :since:`Since
|
||||
1.2.7 (QEMU and KVM only)`
|
||||
commands that can be queued on devices controlled by the host.
|
||||
:since:`Since 1.2.7 (QEMU and KVM only)`
|
||||
``max_sectors``
|
||||
The optional ``max_sectors`` attribute specifies the maximum amount of data
|
||||
in bytes that will be transferred to or from the device in a single command.
|
||||
@ -4064,7 +4070,7 @@ emulating (e.g. "i82801b11-bridge") rather than simply the class of device
|
||||
("pcie-to-pci-bridge", "pci-bridge"), which is set in the controller element's
|
||||
model **attribute**. In almost all cases, you should not manually add a
|
||||
``<model>`` subelement to a controller, nor should you modify one that is
|
||||
automatically generated by libvirt. :since:`Since 1.2.19 (QEMU only).`
|
||||
automatically generated by libvirt. :since:`Since 1.2.19 (QEMU only)`.
|
||||
|
||||
PCI controllers also have an optional subelement ``<target>`` with the
|
||||
attributes and subelements listed below. These are configurable items that 1)
|
||||
@ -4072,7 +4078,7 @@ are visible to the guest OS so must be preserved for guest ABI compatibility,
|
||||
and 2) are usually left to default values or derived automatically by libvirt.
|
||||
In almost all cases, you should not manually add a ``<target>`` subelement to a
|
||||
controller, nor should you modify the values in the those that are automatically
|
||||
generated by libvirt. :since:`Since 1.2.19 (QEMU only).`
|
||||
generated by libvirt. :since:`Since 1.2.19 (QEMU only)`.
|
||||
|
||||
``chassisNr``
|
||||
PCI controllers that have attribute model="pci-bridge", can also have a
|
||||
@ -4188,8 +4194,8 @@ bridge device that can connect only to one of the 31 slots on the pcie-root bus
|
||||
on its upstream side, and makes a single (PCIe, hotpluggable) port available on
|
||||
the downstream side (at slot='0'). pcie-root-port can be used to provide a
|
||||
single slot to later hotplug a PCIe device (but is not itself hotpluggable - it
|
||||
must be in the configuration when the domain is started). ( :since:`since
|
||||
1.2.19` )
|
||||
must be in the configuration when the domain is started).
|
||||
( :since:`since 1.2.19` )
|
||||
|
||||
pcie-switch-upstream-port is a more flexible (but also more complex) device that
|
||||
can only plug into a pcie-root-port or pcie-switch-downstream-port on the
|
||||
@ -4390,7 +4396,7 @@ or:
|
||||
``scsi_host``
|
||||
:since:`since 2.5.0` For SCSI devices, user is responsible to make sure
|
||||
the device is not used by host. This ``type`` passes all LUNs presented by
|
||||
a single HBA to the guest. :since:`Since 5.2.0,` the ``model`` attribute
|
||||
a single HBA to the guest. :since:`Since 5.2.0`, the ``model`` attribute
|
||||
can be specified further with "virtio-transitional",
|
||||
"virtio-non-transitional", or "virtio". `Virtio transitional devices`_
|
||||
for more details.
|
||||
@ -4512,8 +4518,9 @@ or:
|
||||
memory map. (In PCI documentation, the "rombar" setting controls the presence
|
||||
of the Base Address Register for the ROM). If no rom bar is specified, the
|
||||
qemu default will be used (older versions of qemu used a default of "off",
|
||||
while newer qemus have a default of "on"). :since:`Since 0.9.7 (QEMU and KVM
|
||||
only)` . The optional ``file`` attribute contains an absolute path to a
|
||||
while newer qemus have a default of "on").
|
||||
:since:`Since 0.9.7 (QEMU and KVM only)`.
|
||||
The optional ``file`` attribute contains an absolute path to a
|
||||
binary file to be presented to the guest as the device's ROM BIOS. This can
|
||||
be useful, for example, to provide a PXE boot ROM for a virtual function of
|
||||
an sr-iov capable ethernet device (which has no boot ROMs for the VFs).
|
||||
@ -4539,8 +4546,9 @@ or:
|
||||
``driver``
|
||||
PCI hostdev devices can have an optional ``driver`` subelement that
|
||||
specifies which host driver to bind to the device when preparing it
|
||||
for assignment to a guest. :since:`Since 10.0.0 (useful for QEMU and
|
||||
KVM only)`. This is done by setting the ``<driver>`` element's ``model``
|
||||
for assignment to a guest.
|
||||
:since:`Since 10.0.0 (useful for QEMU and KVM only)`.
|
||||
This is done by setting the ``<driver>`` element's ``model``
|
||||
attribute, for example::
|
||||
|
||||
...
|
||||
@ -4561,7 +4569,7 @@ or:
|
||||
found is "problematic" in some way, the generic vfio-pci driver
|
||||
similarly be forced.
|
||||
|
||||
(Note: :since:`Since 1.0.5,` the ``name`` attribute has been
|
||||
(Note: :since:`Since 1.0.5`, the ``name`` attribute has been
|
||||
described to be used to select the type of PCI device assignment
|
||||
("vfio", "kvm", or "xen"), but those values have been mostly
|
||||
useless, since the type of device assignment is actually determined
|
||||
@ -4584,8 +4592,8 @@ Block / character devices
|
||||
|
||||
Block / character devices from the host can be passed through to the guest using
|
||||
the ``hostdev`` element. This is only possible with container based
|
||||
virtualization. Devices are specified by a fully qualified path. :since:`since
|
||||
after 1.0.1 for LXC` :
|
||||
virtualization. Devices are specified by a fully qualified path.
|
||||
:since:`since after 1.0.1 for LXC`:
|
||||
|
||||
::
|
||||
|
||||
@ -4632,8 +4640,8 @@ after 1.0.1 for LXC` :
|
||||
Redirected devices
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
USB device redirection through a character device is supported :since:`since
|
||||
after 0.9.5 (KVM only)` :
|
||||
USB device redirection through a character device is supported
|
||||
:since:`since after 0.9.5 (KVM only)`:
|
||||
|
||||
::
|
||||
|
||||
@ -4812,8 +4820,7 @@ network may be totally isolated (no ``<forward>`` element given), NAT'ing to an
|
||||
explicit network device or to the default route (``<forward mode='nat'>``),
|
||||
routed with no NAT (``<forward mode='route'/>``), or connected directly to one
|
||||
of the host's network interfaces (via macvtap) or bridge devices
|
||||
(``<forward mode='bridge|private|vepa|passthrough'/>`` :since:`Since
|
||||
0.9.4` )
|
||||
(``<forward mode='bridge|private|vepa|passthrough'/>`` :since:`Since 0.9.4`)
|
||||
|
||||
For networks with a forward mode of bridge, private, vepa, and passthrough, it
|
||||
is assumed that the host has any necessary DNS and DHCP services already setup
|
||||
@ -4840,8 +4847,8 @@ automatically during startup and shutdown. :since:`Since 5.1.0`
|
||||
Also, similar to ``direct`` network connections (described below), a connection
|
||||
of type ``network`` may specify a ``virtualport`` element, with configuration
|
||||
data to be forwarded to a vepa (802.1Qbg) or 802.1Qbh compliant switch (
|
||||
:since:`Since 0.8.2` ), or to an Open vSwitch virtual switch ( :since:`Since
|
||||
0.9.11` ).
|
||||
:since:`Since 0.8.2` ), or to an Open vSwitch virtual switch
|
||||
( :since:`Since 0.9.11` ).
|
||||
|
||||
Since the actual type of switch may vary depending on the configuration in the
|
||||
``<network>`` on the host, it is acceptable to omit the virtualport ``type``
|
||||
@ -5094,8 +5101,9 @@ device is useful because it permits a virtual machine managed by an unprivileged
|
||||
libvirtd to have emulated network devices based on tap devices.
|
||||
|
||||
After creating/opening the tap device, an optional shell script (given in the
|
||||
``path`` attribute of the ``<script>`` element) will be run. :since:`Since
|
||||
0.2.1` Also, after detaching/closing the tap device, an optional shell script
|
||||
``path`` attribute of the ``<script>`` element) will be run.
|
||||
:since:`Since 0.2.1`
|
||||
Also, after detaching/closing the tap device, an optional shell script
|
||||
(given in the ``path`` attribute of the ``<downscript>`` element) will be run.
|
||||
:since:`Since 6.4.0` These can be used to do whatever extra host network
|
||||
integration is required.
|
||||
@ -5256,8 +5264,8 @@ assignment (VFIO is a new method of device assignment that is compatible with
|
||||
UEFI Secure Boot), a type='hostdev' interface can have an optional ``driver``
|
||||
sub-element with a ``name`` attribute set to "vfio". To use legacy KVM device
|
||||
assignment you can set ``name`` to "kvm" (the default is "vfio" on systems
|
||||
where the VFIO driver is available, and "kvm" on older systems. :since:`Since
|
||||
1.1.3` (prior to that the default was always "kvm").
|
||||
where the VFIO driver is available, and "kvm" on older systems.
|
||||
:since:`Since 1.1.3` (prior to that the default was always "kvm").
|
||||
|
||||
Note that this "intelligent passthrough" of network devices is very similar to
|
||||
the functionality of a standard <hostdev> device, the difference being that this
|
||||
@ -5302,8 +5310,8 @@ uses a datapath that complies with the virtio specification but has a
|
||||
vendor-specific control path. To use such a device with libvirt, the host
|
||||
device must already be bound to the appropriate device-specific vDPA driver.
|
||||
This creates a vDPA char device (e.g. /dev/vhost-vdpa-0) that can be used to
|
||||
assign the device to a libvirt domain. :since:`Since 6.9.0 (QEMU only,
|
||||
requires QEMU 5.1.0 or newer)`
|
||||
assign the device to a libvirt domain.
|
||||
:since:`Since 6.9.0 (QEMU only, requires QEMU 5.1.0 or newer)`
|
||||
|
||||
::
|
||||
|
||||
@ -5499,8 +5507,8 @@ A UDP unicast architecture provides a virtual network which enables connections
|
||||
between QEMU instances using QEMU's UDP infrastructure. The xml "source" address
|
||||
is the endpoint address to which the UDP socket packets will be sent from the
|
||||
host running QEMU. The xml "local" address is the address of the interface from
|
||||
which the UDP socket packets will originate from the QEMU host. :since:`Since
|
||||
1.2.20`
|
||||
which the UDP socket packets will originate from the QEMU host.
|
||||
:since:`Since 1.2.20`
|
||||
|
||||
::
|
||||
|
||||
@ -5615,16 +5623,16 @@ following attributes are available for the ``virtio`` NIC driver:
|
||||
backend, which requires the vhost module to be provided by the kernel); an
|
||||
attempt to require the vhost driver without kernel support will be rejected.
|
||||
If this attribute is not present, then the domain defaults to 'vhost' if
|
||||
present, but silently falls back to 'qemu' without error. :since:`Since 0.8.8
|
||||
(QEMU and KVM only)`
|
||||
present, but silently falls back to 'qemu' without error.
|
||||
:since:`Since 0.8.8 (QEMU and KVM only)`
|
||||
For interfaces of type='hostdev' (PCI passthrough devices) the ``name``
|
||||
attribute can optionally be set to "vfio" or "kvm". "vfio" tells libvirt to
|
||||
use VFIO device assignment rather than traditional KVM device assignment
|
||||
(VFIO is a new method of device assignment that is compatible with UEFI
|
||||
Secure Boot), and "kvm" tells libvirt to use the legacy device assignment
|
||||
performed directly by the kvm kernel module (the default is currently "kvm",
|
||||
but is subject to change). :since:`Since 1.0.5 (QEMU and KVM only, requires
|
||||
kernel 3.6 or newer)`
|
||||
but is subject to change).
|
||||
:since:`Since 1.0.5 (QEMU and KVM only, requires kernel 3.6 or newer)`
|
||||
For interfaces of type='vhostuser', the ``name`` attribute is ignored. The
|
||||
backend driver used is always vhost-user.
|
||||
``txmode``
|
||||
@ -5671,15 +5679,15 @@ following attributes are available for the ``virtio`` NIC driver:
|
||||
processing queues requires the interface having the
|
||||
``<model type='virtio'/>`` element. Each queue will potentially be handled by
|
||||
a different processor, resulting in much higher throughput.
|
||||
:since:`virtio-net since 1.0.6 (QEMU and KVM only)` :since:`vhost-user since
|
||||
1.2.17 (QEMU and KVM only)`
|
||||
:since:`virtio-net since 1.0.6 (QEMU and KVM only)`
|
||||
:since:`vhost-user since 1.2.17 (QEMU and KVM only)`
|
||||
``rx_queue_size``
|
||||
The optional ``rx_queue_size`` attribute controls the size of virtio ring for
|
||||
each queue as described above. The default value is hypervisor dependent and
|
||||
may change across its releases. Moreover, some hypervisors may pose some
|
||||
restrictions on actual value. For instance, latest QEMU (as of 2016-09-01)
|
||||
requires value to be a power of two from [256, 1024] range. :since:`Since
|
||||
2.3.0 (QEMU and KVM only)`
|
||||
requires value to be a power of two from [256, 1024] range.
|
||||
:since:`Since 2.3.0 (QEMU and KVM only)`
|
||||
**In general you should leave this option alone, unless you are very certain
|
||||
you know what you are doing.**
|
||||
``tx_queue_size``
|
||||
@ -5939,7 +5947,7 @@ toplevel ``<vlan>`` element to differentiate trunking of a single tag from
|
||||
normal tagging.
|
||||
|
||||
For network connections using Open vSwitch it is also possible to configure
|
||||
'native-tagged' and 'native-untagged' VLAN modes :since:`Since 1.1.0.` This is
|
||||
'native-tagged' and 'native-untagged' VLAN modes :since:`Since 1.1.0`. This is
|
||||
done with the optional ``nativeMode`` attribute on the ``<tag>`` subelement:
|
||||
``nativeMode`` may be set to 'tagged' or 'untagged'. The ``id`` attribute of the
|
||||
``<tag>`` subelement containing ``nativeMode`` sets which VLAN is considered to
|
||||
@ -5961,7 +5969,7 @@ Isolating guests' network traffic from each other
|
||||
</devices>
|
||||
...
|
||||
|
||||
:since:`Since 6.1.0.` The ``port`` element property ``isolated``, when set to
|
||||
:since:`Since 6.1.0`. The ``port`` element property ``isolated``, when set to
|
||||
``yes`` (default setting is ``no``) is used to isolate this interface's network
|
||||
traffic from that of other guest interfaces connected to the same network that
|
||||
also have ``<port isolated='yes'/>``. This setting is only supported for
|
||||
@ -6078,8 +6086,8 @@ the IP address. The optional ``prefix`` is the number of 1 bits in the netmask,
|
||||
and will be automatically set if not specified - for IPv4 the default prefix is
|
||||
determined according to the network "class" (A, B, or C - see RFC870), and for
|
||||
IPv6 the default prefix is 64. The optional ``peer`` attribute holds the IP
|
||||
address of the other end of a point-to-point network device :since:`(since
|
||||
2.1.0)` .
|
||||
address of the other end of a point-to-point network device
|
||||
:since:`(since 2.1.0)`.
|
||||
|
||||
:since:`Since 1.2.12` route elements can also be added to define IP routes to
|
||||
add in the guest. The attributes of this element are described in the
|
||||
@ -6327,8 +6335,8 @@ interaction with the admin.
|
||||
|
||||
For VNC WebSocket functionality, ``websocket`` attribute may be used to
|
||||
specify port to listen on (with -1 meaning auto-allocation and
|
||||
``autoport`` having no effect due to security reasons) :since:`Since
|
||||
1.0.6` .
|
||||
``autoport`` having no effect due to security reasons)
|
||||
:since:`Since 1.0.6`.
|
||||
|
||||
For VNC, the ``powerControl`` attribute can be used to enable VM shutdown,
|
||||
reboot and reset power control features for the VNC client. This is
|
||||
@ -6509,8 +6517,8 @@ interaction with the admin.
|
||||
|
||||
Graphics device uses a ``<listen>`` to set up where the device should listen for
|
||||
clients. It has a mandatory attribute ``type`` which specifies the listen type.
|
||||
Only ``vnc``, ``spice`` and ``rdp`` supports ``<listen>`` element. :since:`Since
|
||||
0.9.4` . Available types are:
|
||||
Only ``vnc``, ``spice`` and ``rdp`` supports ``<listen>`` element.
|
||||
:since:`Since 0.9.4`. Available types are:
|
||||
|
||||
``address``
|
||||
Tells a graphics device to use an address specified in the ``address``
|
||||
@ -6739,8 +6747,8 @@ For character device with type ``unix`` or ``tcp`` the ``source`` has an
|
||||
optional element ``reconnect`` which configures reconnect timeout if the
|
||||
connection is lost. There are two attributes, ``enabled`` where possible values
|
||||
are "yes" and "no" and ``timeout`` which is in seconds. The ``reconnect``
|
||||
attribute is valid only for ``connect`` mode. :since:`Since 3.7.0 (QEMU driver
|
||||
only)` .
|
||||
attribute is valid only for ``connect`` mode.
|
||||
:since:`Since 3.7.0 (QEMU driver only)`.
|
||||
|
||||
Guest interface
|
||||
^^^^^^^^^^^^^^^
|
||||
@ -7033,8 +7041,8 @@ types have different ``target`` attributes.
|
||||
with attribute ``type='virtio'``; an optional attribute ``name`` controls how
|
||||
the guest will have access to the channel, and defaults to
|
||||
``name='com.redhat.spice.0'``. The optional ``address`` element can tie the
|
||||
channel to a particular ``type='virtio-serial'`` controller. :since:`Since
|
||||
0.8.8`
|
||||
channel to a particular ``type='virtio-serial'`` controller.
|
||||
:since:`Since 0.8.8`
|
||||
``qemu-vdagent``
|
||||
Paravirtualized qemu vdagent channel. This channel implements the SPICE
|
||||
vdagent protocol, but is handled internally by qemu and therefore does not
|
||||
@ -7221,7 +7229,7 @@ Or as a TCP server waiting for a client connection.
|
||||
Alternatively you can use ``telnet`` instead of ``raw`` TCP in order to utilize
|
||||
the telnet protocol for the connection.
|
||||
|
||||
:since:`Since 0.8.5,` some hypervisors support use of either ``telnets`` (secure
|
||||
:since:`Since 0.8.5`, some hypervisors support use of either ``telnets`` (secure
|
||||
telnet) or ``tls`` (via secure sockets layer) as the transport protocol for
|
||||
connections.
|
||||
|
||||
@ -7243,7 +7251,7 @@ connections.
|
||||
</devices>
|
||||
...
|
||||
|
||||
:since:`Since 2.4.0,` the optional attribute ``tls`` can be used to control
|
||||
:since:`Since 2.4.0`, the optional attribute ``tls`` can be used to control
|
||||
whether a chardev TCP communication channel would utilize a hypervisor
|
||||
configured TLS X.509 certificate environment in order to encrypt the data
|
||||
channel. For the QEMU hypervisor, usage of a TLS environment can be controlled
|
||||
@ -7869,8 +7877,9 @@ Memory balloon device
|
||||
A virtual memory balloon device is added to all Xen and KVM/QEMU guests. It will
|
||||
be seen as ``memballoon`` element. It will be automatically added when
|
||||
appropriate, so there is no need to explicitly add this element in the guest XML
|
||||
unless a specific PCI slot needs to be assigned. :since:`Since 0.8.3, Xen, QEMU
|
||||
and KVM only` Additionally, :since:`since 0.8.4` , if the memballoon device
|
||||
unless a specific PCI slot needs to be assigned.
|
||||
:since:`Since 0.8.3, Xen, QEMU and KVM only`
|
||||
Additionally, :since:`since 0.8.4`, if the memballoon device
|
||||
needs to be explicitly disabled, ``model='none'`` may be used.
|
||||
|
||||
Example: automatically added device with KVM
|
||||
@ -8002,8 +8011,8 @@ Example: usage of the RNG device:
|
||||
|
||||
``builtin``
|
||||
This backend uses qemu builtin random generator, which uses
|
||||
``getrandom()`` syscall as the source of entropy. ( :since:`Since 6.1.0
|
||||
and QEMU 4.2` )
|
||||
``getrandom()`` syscall as the source of entropy.
|
||||
( :since:`Since 6.1.0 and QEMU 4.2` )
|
||||
|
||||
``driver``
|
||||
The subelement ``driver`` can be used to tune the device:
|
||||
@ -8189,8 +8198,8 @@ Example: usage of panic configuration
|
||||
|
||||
- 'isa' - for ISA pvpanic device
|
||||
- 'pseries' - default and valid only for pSeries guests.
|
||||
- 'hyperv' - for Hyper-V crash CPU feature. :since:`Since 1.3.0, QEMU and
|
||||
KVM only`
|
||||
- 'hyperv' - for Hyper-V crash CPU feature.
|
||||
:since:`Since 1.3.0, QEMU and KVM only`
|
||||
- 's390' - default for S390 guests. :since:`Since 1.3.5`
|
||||
- 'pvpanic' - for PCI pvpanic device :since:`Since 9.1.0, QEMU only`
|
||||
|
||||
@ -8361,8 +8370,9 @@ Example: usage of the memory devices
|
||||
...
|
||||
|
||||
``model``
|
||||
Provide ``dimm`` to add a virtual DIMM module to the guest. :since:`Since
|
||||
1.2.14` Provide ``nvdimm`` model that adds a Non-Volatile DIMM module.
|
||||
Provide ``dimm`` to add a virtual DIMM module to the guest.
|
||||
:since:`Since 1.2.14`
|
||||
Provide ``nvdimm`` model that adds a Non-Volatile DIMM module.
|
||||
:since:`Since 3.2.0` Provide ``virtio-pmem`` model to add a paravirtualized
|
||||
persistent memory device. :since:`Since 7.1.0` Provide ``virtio-mem`` model
|
||||
to add paravirtualized memory device. :since:`Since 7.9.0` Provide
|
||||
@ -8477,8 +8487,8 @@ Example: usage of the memory devices
|
||||
``readonly``
|
||||
The ``readonly`` element is used to mark the vNVDIMM as read-only. Only
|
||||
the real NVDIMM device backend can guarantee the guest write persistence,
|
||||
so other backend types should use the ``readonly`` element. :since:`Since
|
||||
5.0.0`
|
||||
so other backend types should use the ``readonly`` element.
|
||||
:since:`Since 5.0.0`
|
||||
|
||||
``block``
|
||||
For ``virtio-mem`` only.
|
||||
@ -8499,8 +8509,8 @@ Example: usage of the memory devices
|
||||
|
||||
``address``
|
||||
For ``virtio-mem`` and ``virtio-pmem`` only.
|
||||
The physical address in memory, where device is mapped. :since:`Since
|
||||
9.4.0`
|
||||
The physical address in memory, where device is mapped.
|
||||
:since:`Since 9.4.0`
|
||||
|
||||
|
||||
IOMMU devices
|
||||
|
@ -42,8 +42,8 @@ The first elements provide basic metadata about the virtual network.
|
||||
The content of the ``name`` element provides a short name for the virtual
|
||||
network. This name should consist only of alphanumeric characters and is
|
||||
required to be unique within the scope of a single host. It is used to form
|
||||
the filename for storing the persistent configuration file. :since:`Since
|
||||
0.3.0`
|
||||
the filename for storing the persistent configuration file.
|
||||
:since:`Since 0.3.0`
|
||||
``uuid``
|
||||
The content of the ``uuid`` element provides a globally unique identifier for
|
||||
the virtual network. The format must be RFC 4122 compliant, eg
|
||||
@ -170,7 +170,7 @@ to the physical LAN (if at all).
|
||||
|
||||
``forward``
|
||||
Inclusion of the ``forward`` element indicates that the virtual network is to
|
||||
be connected to the physical LAN. :since:`Since 0.3.0.` The ``mode``
|
||||
be connected to the physical LAN. :since:`Since 0.3.0`. The ``mode``
|
||||
attribute determines the method of forwarding. If there is no ``forward``
|
||||
element, the network will be isolated from any other network (unless a guest
|
||||
connected to that network is acting as a router, of course). The following
|
||||
@ -287,8 +287,8 @@ to the physical LAN (if at all).
|
||||
802.1Qbh-capable hardware switch), each physical interface can only be in
|
||||
use by a single guest interface at a time; in modes other than 802.1Qbh,
|
||||
multiple guest interfaces can share each physical interface (libvirt will
|
||||
attempt to balance usage between all available interfaces). :since:`Since
|
||||
0.9.4`
|
||||
attempt to balance usage between all available interfaces).
|
||||
:since:`Since 0.9.4`
|
||||
``vepa``
|
||||
This network uses a macvtap "direct" connection in "vepa" mode to connect
|
||||
each guest to the network (this requires that the physical interfaces used
|
||||
@ -319,8 +319,8 @@ to the physical LAN (if at all).
|
||||
single-port PCI ethernet card driver design - only SR-IOV (Single Root I/O
|
||||
Virtualization) virtual function (VF) devices can be assigned in this
|
||||
manner; to assign a standard single-port PCI or PCIe ethernet card to a
|
||||
guest, use the traditional ``<hostdev>`` device definition. :since:` Since
|
||||
0.10.0`
|
||||
guest, use the traditional ``<hostdev>`` device definition.
|
||||
:since:`Since 0.10.0`
|
||||
|
||||
To force use of a particular device-specific VFIO driver when
|
||||
assigning the devices to a guest, a <forward type='hostdev'>
|
||||
@ -536,7 +536,7 @@ toplevel ``<vlan>`` element to differentiate trunking of a single tag from
|
||||
normal tagging.
|
||||
|
||||
For network connections using Open vSwitch it is also possible to configure
|
||||
'native-tagged' and 'native-untagged' VLAN modes :since:`Since 1.1.0.` This is
|
||||
'native-tagged' and 'native-untagged' VLAN modes :since:`Since 1.1.0`. This is
|
||||
done with the optional ``nativeMode`` attribute on the ``<tag>`` subelement:
|
||||
``nativeMode`` may be set to 'tagged' or 'untagged'. The ``id`` attribute of the
|
||||
``<tag>`` subelement containing ``nativeMode`` sets which VLAN is considered to
|
||||
@ -562,7 +562,7 @@ Isolating ports from one another
|
||||
<port isolated='yes'/>
|
||||
</network>
|
||||
|
||||
:since:`Since 6.1.0.` The ``port`` element property ``isolated``, when set to
|
||||
:since:`Since 6.1.0`. The ``port`` element property ``isolated``, when set to
|
||||
``yes`` (default setting is ``no``) is used to isolate the network traffic of
|
||||
each guest on the network from all other guests connected to the network; it
|
||||
does not have an effect on communication between the guests and the host, or
|
||||
@ -731,8 +731,9 @@ of 'route' or 'nat'.
|
||||
The dns element of a network contains configuration information for the
|
||||
virtual network's DNS server :since:`Since 0.9.3`.
|
||||
|
||||
The dns element can have an optional ``enable`` attribute :since:`Since
|
||||
2.2.0` . If ``enable`` is "no", then no DNS server will be setup by libvirt
|
||||
The dns element can have an optional ``enable`` attribute
|
||||
:since:`Since 2.2.0`.
|
||||
If ``enable`` is "no", then no DNS server will be setup by libvirt
|
||||
for this network (and any other configuration in ``<dns>`` will be ignored).
|
||||
If ``enable`` is "yes" or unspecified (including the complete absence of any
|
||||
``<dns>`` element) then a DNS server will be setup by libvirt to listen on
|
||||
@ -848,15 +849,15 @@ of 'route' or 'nat'.
|
||||
which the boot image will be fetched. ``server`` defaults to the same
|
||||
host that runs the DHCP server, as is the case when the ``tftp``
|
||||
element is used. The BOOTP options currently have to be the same for
|
||||
all address ranges and statically assigned addresses. :since:`Since
|
||||
0.7.1`
|
||||
all address ranges and statically assigned addresses.
|
||||
:since:`Since 0.7.1`
|
||||
|
||||
Optionally, ``range`` and ``host`` elements can have ``lease`` child
|
||||
element which specifies the lease time through it's attributes ``expiry``
|
||||
and ``unit`` (which accepts ``seconds``, ``minutes`` and ``hours`` and
|
||||
defaults to ``minutes`` if omitted). The minimal lease time is 2 minutes,
|
||||
except when setting an infinite lease time (``expiry='0'``). :since:`Since
|
||||
6.3.0`
|
||||
except when setting an infinite lease time (``expiry='0'``).
|
||||
:since:`Since 6.3.0`
|
||||
|
||||
Network namespaces
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
@ -90,7 +90,7 @@ The following elements are common to one or more of the plug types listed later
|
||||
connection on the host - currently it is only supported for the virtio device
|
||||
model and for macvtap connections on the host.
|
||||
``port``
|
||||
:since:`Since 6.1.0.` The ``port`` element property ``isolated``, when set to
|
||||
:since:`Since 6.1.0`. The ``port`` element property ``isolated``, when set to
|
||||
``yes`` (default setting is ``no``) is used to isolate this port's network
|
||||
traffic from other ports on the same network that also have
|
||||
``<port isolated='yes'/>``. This setting is only supported for emulated
|
||||
|
@ -367,8 +367,8 @@ S390 architecture. Sub-elements include:
|
||||
``vdpa``
|
||||
^^^^^^^^
|
||||
|
||||
Describes a virtual datapath acceleration (vDPA) network device. :since:`Since
|
||||
6.9.0` . Sub-elements include:
|
||||
Describes a virtual datapath acceleration (vDPA) network device.
|
||||
:since:`Since 6.9.0`. Sub-elements include:
|
||||
|
||||
``chardev``
|
||||
The path to the character device that is used to access the device.
|
||||
|
@ -593,8 +593,8 @@ Note: Rules of this type should go into the ``root`` chain.
|
||||
| protocolid | UINT16 (0x600-0xffff), | Layer 3 protocol ID |
|
||||
| | STRING | |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
|
||||
Valid Strings for ``protocolid`` are: arp, rarp, ipv4, ipv6
|
||||
@ -710,20 +710,20 @@ chain.
|
||||
| arpsrcipaddr | IP_ADDR | Source IP address in |
|
||||
| | | ARP/RARP packet |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
| arpsrcipmask :since:`(Since | IP_MASK | Source IP mask |
|
||||
| 1.2.3)` | | |
|
||||
| arpsrcipmask | IP_MASK | Source IP mask |
|
||||
| :since:`(Since 1.2.3)` | | |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
| arpdstipaddr | IP_ADDR | Destination IP address in |
|
||||
| | | ARP/RARP packet |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
| arpdstipmask :since:`(Since | IP_MASK | Destination IP mask |
|
||||
| 1.2.3)` | | |
|
||||
| arpdstipmask | IP_MASK | Destination IP mask |
|
||||
| :since:`(Since 1.2.3)` | | |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
| gratuitous :since:`(Since | BOOLEAN | boolean indicating whether |
|
||||
| 0.9.2)` | | to check for gratuitous ARP |
|
||||
| gratuitous | BOOLEAN | boolean indicating whether |
|
||||
| :since:`(Since 0.9.2)` | | to check for gratuitous ARP |
|
||||
| | | packet |
|
||||
+-----------------------------+----------------+-----------------------------+
|
||||
|
||||
@ -783,8 +783,8 @@ Note: Rules of this type should either go into the ``root`` or ``ipv4`` chain.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
|
||||
Valid strings for ``protocol`` are: tcp, udp, udplite, esp, ah, icmp, igmp, sctp
|
||||
@ -839,8 +839,8 @@ Note: Rules of this type should either go into the ``root`` or ``ipv6`` chain.
|
||||
| | | ``protocol`` to be set to |
|
||||
| | | ``icmpv6`` |
|
||||
+--------------------------------+-----------+--------------------------------+
|
||||
| typeend :since:`(Since | UINT8 | ICMPv6 type end of range; |
|
||||
| 1.2.12)` | | requires ``protocol`` to be |
|
||||
| typeend | UINT8 | ICMPv6 type end of range; |
|
||||
| :since:`(Since 1.2.12)` | | requires ``protocol`` to be |
|
||||
| | | set to ``icmpv6`` |
|
||||
+--------------------------------+-----------+--------------------------------+
|
||||
| code :since:`(Since 1.2.12)` | UINT8 | ICMPv6 code; requires |
|
||||
@ -906,23 +906,23 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| flags :since:`(Since | STRING | TCP-only: format of |
|
||||
| 0.9.1)` | | mask/flags with mask |
|
||||
| flags | STRING | TCP-only: format of |
|
||||
| :since:`(Sinc 0.9.1)` | | mask/flags with mask |
|
||||
| | | and flags each being a |
|
||||
| | | comma separated list of |
|
||||
| | | SYN,ACK,URG,PSH,FIN,RST |
|
||||
| | | or NONE or ALL |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -981,16 +981,16 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -1045,16 +1045,16 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -1112,23 +1112,23 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| flags :since:`(Since | STRING | TCP-only: format of |
|
||||
| 0.9.1)` | | mask/flags with mask |
|
||||
| flags | STRING | TCP-only: format of |
|
||||
| :since:`(Since 0.9.1)` | | mask/flags with mask |
|
||||
| | | and flags each being a |
|
||||
| | | comma separated list of |
|
||||
| | | SYN,ACK,URG,PSH,FIN,RST |
|
||||
| | | or NONE or ALL |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -1180,16 +1180,16 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -1237,16 +1237,16 @@ be omitted or set to ``root``.
|
||||
| dscp | UINT8 (0x0-0x3f, 0 - | Differentiated Services |
|
||||
| | 63) | Code Point |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| comment :since:`(Since | STRING | text with max. 256 |
|
||||
| 0.8.5)` | | characters |
|
||||
| comment | STRING | text with max. 256 |
|
||||
| :since:`(Since 0.8.5)` | | characters |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| state :since:`(Since | STRING | comma separated list of |
|
||||
| 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| state | STRING | comma separated list of |
|
||||
| :since:`(Since 0.8.5)` | | NEW, ESTABLISHED, |
|
||||
| | | RELATED, INVALID |
|
||||
| | | or NONE |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipset :since:`(Since | STRING | The name of an IPSet |
|
||||
| 0.9.13)` | | managed outside of |
|
||||
| ipset | STRING | The name of an IPSet |
|
||||
| :since:`(Since 0.9.13)` | | managed outside of |
|
||||
| | | libvirt |
|
||||
+-------------------------+-------------------------+-------------------------+
|
||||
| ipsetflags | IPSETFLAGS | flags for the IPSet; |
|
||||
@ -1632,8 +1632,8 @@ connection, thus we want to allow it to let packets pass the firewall. The
|
||||
outgoing TCP connection for the ftp data path. Afterwards, the state to compare
|
||||
against is ``ESTABLISHED``, which then applies equally to the incoming and
|
||||
outgoing direction. All this is related to the ftp data traffic originating from
|
||||
TCP port 20 of the VM. This then leads to the following solution :since:`(since
|
||||
0.8.5 (QEMU, KVM))` :
|
||||
TCP port 20 of the VM. This then leads to the following solution
|
||||
:since:`(since 0.8.5 (QEMU, KVM))` :
|
||||
|
||||
::
|
||||
|
||||
|
@ -199,8 +199,8 @@ The top-level ``domainsnapshot`` element may contain the following elements:
|
||||
uuid; reverting to a snapshot like this is risky if the current state of the
|
||||
domain differs from the state that the domain was created in, and requires
|
||||
the use of the ``VIR_DOMAIN_SNAPSHOT_REVERT_FORCE`` flag in
|
||||
``virDomainRevertToSnapshot()``. Newer versions of libvirt ( :since:`since
|
||||
0.9.5` ) store the entire inactive `domain configuration
|
||||
``virDomainRevertToSnapshot()``. Newer versions of libvirt
|
||||
(:since:`since 0.9.5`) store the entire inactive `domain configuration
|
||||
<formatdomain.html>`__ at the time of the snapshot ( :since:`since 0.9.5` ).
|
||||
The domain will have security-sensitive information omitted unless the flag
|
||||
``VIR_DOMAIN_SNAPSHOT_XML_SECURE`` is provided on a read-write connection.
|
||||
|
@ -48,8 +48,8 @@ Storage pool general metadata
|
||||
``allocation``
|
||||
Providing the total storage allocation for the pool. This may be larger than
|
||||
the sum of the allocation of all volumes due to metadata overhead. This value
|
||||
is in bytes. This is not applicable when creating a pool. :since:`Since
|
||||
0.4.1`
|
||||
is in bytes. This is not applicable when creating a pool.
|
||||
:since:`Since 0.4.1`
|
||||
``capacity``
|
||||
Providing the total storage capacity for the pool. Due to underlying device
|
||||
constraints it may not be possible to use the full capacity for storage
|
||||
@ -201,8 +201,8 @@ following child elements:
|
||||
"scsi_host". To keep backwards compatibility, this attribute is optional
|
||||
**only** for the "scsi_host" adapter, but is mandatory for the "fc_host"
|
||||
adapter. :since:`Since 1.0.5` A "fc_host" capable scsi_hostN can be
|
||||
determined by using ``virsh nodedev-list --cap fc_host``. :since:`Since
|
||||
1.2.8`
|
||||
determined by using ``virsh nodedev-list --cap fc_host``.
|
||||
:since:`Since 1.2.8`
|
||||
|
||||
Note: Regardless of whether a "scsi_host" adapter type is defined using a
|
||||
``name`` or a ``parentaddr``, it should refer to a real scsi_host adapter
|
||||
@ -360,8 +360,8 @@ following child elements:
|
||||
:since:`Since 0.8.4`
|
||||
``product``
|
||||
Provides an optional product name of the storage device. This contains a
|
||||
single attribute ``name`` whose value is backend specific. :since:`Since
|
||||
0.8.4`
|
||||
single attribute ``name`` whose value is backend specific.
|
||||
:since:`Since 0.8.4`
|
||||
|
||||
Storage pool target elements
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -504,7 +504,7 @@ option in libvirt, and thus should never be used in production.
|
||||
</pool>
|
||||
...
|
||||
|
||||
:since:`Since 5.1.0.`
|
||||
:since:`Since 5.1.0`.
|
||||
|
||||
``rbd:config_opts``
|
||||
Provides an XML namespace mechanism to optionally utilize specifically named
|
||||
@ -545,13 +545,14 @@ option in libvirt, and thus should never be used in production.
|
||||
</rbd:config_opts>
|
||||
</pool>
|
||||
|
||||
:since:`Since 5.1.0.`
|
||||
:since:`Since 5.1.0`.
|
||||
|
||||
Storage volume XML
|
||||
------------------
|
||||
|
||||
A storage volume will generally be either a file or a device node; :since:`since
|
||||
1.2.0` , an optional output-only attribute ``type`` lists the actual type (file,
|
||||
A storage volume will generally be either a file or a device node;
|
||||
:since:`since 1.2.0`, an optional output-only attribute ``type`` lists
|
||||
the actual type (file,
|
||||
block, dir, network, netdir or ploop), which is also available from
|
||||
``virStorageVolGetInfo()``. The storage volume XML format is available
|
||||
:since:`since 0.4.1`
|
||||
@ -609,12 +610,12 @@ Storage volume general metadata
|
||||
``capacity``
|
||||
Providing the logical capacity for the volume. This value is in bytes by
|
||||
default, but a ``unit`` attribute can be specified with the same semantics as
|
||||
for ``allocation`` This is compulsory when creating a volume. :since:`Since
|
||||
0.4.1`
|
||||
for ``allocation`` This is compulsory when creating a volume.
|
||||
:since:`Since 0.4.1`
|
||||
``physical``
|
||||
This output only element provides the host physical size of the target
|
||||
storage volume. The default output ``unit`` will be in bytes. :since:`Since
|
||||
3.0.0`
|
||||
storage volume. The default output ``unit`` will be in bytes.
|
||||
:since:`Since 3.0.0`
|
||||
``source``
|
||||
Provides information about the underlying storage allocation of the volume.
|
||||
This may not be available for some pool types. :since:`Since 0.4.1`
|
||||
|
@ -46,7 +46,7 @@ it using the specified ``uuid``.
|
||||
``qcow`` format
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
:since:`Since 4.5.0,` encryption formats ``default`` and ``qcow`` may no longer
|
||||
:since:`Since 4.5.0`, encryption formats ``default`` and ``qcow`` may no longer
|
||||
be used to create an encrypted volume. Usage of qcow encrypted volumes in QEMU
|
||||
began phasing out in QEMU 2.3 and by QEMU 2.9 creation of a qcow encrypted
|
||||
volume via qemu-img required usage of secret objects, but that support was not
|
||||
@ -133,7 +133,7 @@ domain volume definition:
|
||||
</encryption>
|
||||
|
||||
Here is an example specifying use of the ``luks`` format for a specific cipher
|
||||
algorithm for volume creation. :since:`Since 6.10.0,` the ``target`` format can
|
||||
algorithm for volume creation. :since:`Since 6.10.0`, the ``target`` format can
|
||||
also support ``qcow2`` type with ``luks`` encryption.
|
||||
|
||||
::
|
||||
|
Loading…
Reference in New Issue
Block a user