[PATCH 3/5] conf: Introduce <metadata_cache> subelement of <disk><driver>
Ján Tomko
jtomko at redhat.com
Thu Jan 7 20:54:35 UTC 2021
On a Thursday in 2021, Peter Krempa wrote:
>In certain specific cases it might be beneficial to be able to control
>the metadata caching of storage image format drivers of a hypervisor.
>
>Introduce XML machinery to set the maximum size of the metadata cache
>which will be used by qemu's qcow2 driver.
>
>Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>---
> docs/formatdomain.rst | 43 ++++++++++++++
> docs/schemas/domaincommon.rng | 20 ++++++-
> src/conf/domain_conf.c | 51 ++++++++++++++--
> src/util/virstoragefile.c | 1 +
> src/util/virstoragefile.h | 2 +
> .../qemuxml2argvdata/disk-metadata-cache.xml | 46 +++++++++++++++
> .../disk-metadata-cache.x86_64-latest.xml | 58 +++++++++++++++++++
> tests/qemuxml2xmltest.c | 1 +
> 8 files changed, 216 insertions(+), 6 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/disk-metadata-cache.xml
> create mode 100644 tests/qemuxml2xmloutdata/disk-metadata-cache.x86_64-latest.xml
>
>diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
>index 1189795974..abf85064fa 100644
>--- a/docs/formatdomain.rst
>+++ b/docs/formatdomain.rst
>@@ -2735,6 +2735,11 @@ paravirtualized driver is specified via the ``disk`` element.
> ``format``
> The ``format`` element contains ``type`` attribute which specifies the
> internal format of the backing store, such as ``raw`` or ``qcow2``.
>+
>+ The ``format`` element can contain ``metadata_cache`` subelement, which
>+ has identical semantics to the identically named subelement of ``driver``
>+ of a ``disk``.
>+
> ``source``
> This element has the same structure as the ``source`` element in ``disk``.
> It specifies which file, device, or network location contains the data of
>@@ -2947,6 +2952,44 @@ paravirtualized driver is specified via the ``disk`` element.
> virtio-blk. ( :since:`Since 3.9.0` )
> - For virtio disks, `Virtio-specific options <#elementsVirtio>`__ can also
> be set. ( :since:`Since 3.5.0` )
>+ - The optional ``metadata_cache`` subelement controls aspects related to the
>+ format specific caching of storage image metadata. Note that this setting
>+ applies only on the top level image; the identically named sublelement of
>+ ``backingStore``'s ``format`` element can be used to specify cache
>+ settings for the backing image.
>+
>+ :since:`Since 7.0.0` the maximum size of the metadata cache of ``qcow2``
>+ format driver of the ``qemu`` hypervisor can be controlled via the
>+ ``max_size`` subelement (see example below).
>+
>+ In the majority of cases the default configuration used by the hypervisor
>+ is sufficient so modifying this setting should not be necessary. For
>+ specifics on how the metadata cache of ``qcow2`` in ``qemu`` behaves refer
>+ to the ``qemu``
>+ `qcow2 cache docs <https://git.qemu.org/?p=qemu.git;a=blob;f=docs/qcow2-cache.txt>`__
>+
>+ **Example:**
>+
>+::
>+
>+ <disk type='file' device='disk'>
>+ <driver name='qemu' type='qcow2'>
>+ <metadata_cache>
>+ <max_size unit='bytes'>1234</max_size>
>+ </metadata_cache>
>+ </driver>
>+ <source file='/var/lib/libvirt/images/domain.qcow'/>
>+ <backingStore type='file'>
>+ <format type='qcow2'>
>+ <metadata_cache>
>+ <max_size unit='bytes'>1234</max_size>
>+ </metadata_cache>
I don't like introducing a snake_case element under a camelCase one.
But regardless of that, our XML is a mix of both of those and
skewer-case. See also:
https://www.redhat.com/archives/libvir-list/2021-January/msg00371.html
Jano
>+ </format>
>+ <source file='/var/lib/libvirt/images/snapshot.qcow'/>
>+ <backingStore/>
>+ </backingStore>
>+ <target dev='vdd' bus='virtio'/>
>+ </disk>
>
> ``backenddomain``
> The optional ``backenddomain`` element allows specifying a backend domain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210107/72b3197f/attachment-0001.sig>
More information about the libvir-list
mailing list