Re: [PATCH RFC v2 07/12] schema: Add new domain elements to support multiple throttle filters
On Tue, May 14, 2024 at 14:49:58 +0200, Peter Krempa wrote:
On Thu, Apr 11, 2024 at 19:01:55 -0700, wucf(a)linux.ibm.com wrote:
[...]
> diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
> index e2f66b982c..ee9ee8b10c 100644
> --- a/docs/formatdomain.rst
> +++ b/docs/formatdomain.rst
[....]
> @@ -3185,6 +3222,17 @@ paravirtualized driver is specified via
the ``disk`` element.
> :since:`since after 0.4.4`; "sata" attribute value :since:`since
0.9.7`;
> "removable" attribute value :since:`since 1.1.3`;
> "rotation_rate" attribute value :since:`since 7.3.0`
> +``throttlefilters``
> + The optional ``throttlefilters`` element provides the ability to provide
additional
> + per-device throttle chain :since:`Since 10.3.0`
> + For example, if we have four different disks and we want to limit I/O for each
one
> + and we also want to limit combined I/O of all four disks, we can leverage
> + ``throttlefilters`` to achieve this goal by setting two ``throttlefilter`` for
> + each disk: disk's own filter and combined filter. ``throttlefilters`` and
``iotune``
> + should be used exclusively.
Please also document how the group chaining is applied in terms of
Oops forgot to finish my thought.
Please also document how the group chaining is applied in terms of the
impact on the actual throttle groups.
I'm also wondering if it's okay to apply throttling just at disk level.
Libvirt now allows configuring also backing images specifically and the
qemu throttling infra can be applied at any point in the backing chain,
thus I wonder if it makes sense to do that here.
How do you expect this to be used? what are your design goals? I'm
trying to prevent situation when the throttling will be deemed
insufficient if e.g. somebody would want to apply different throttling
on a backing image.
I'm also thinking about the integration with the <iotune> way to
configure this. These patches sidestep the issue by disallowing the
combination, but I'd really like to also configure the old throttling
via the 'throttle' blockdev layer.
One additional thing that I didn't yet check:
note that libvirt supports also qemu-4.2, thus all of what you've added
needs to be either supported by all qemu versions, or we'll need a
capability and lock-out any versions which don't support everything you
need. I'm specifically asking about this, as I remember that there were
some things which didn't work right at the time I was converting libvirt
to use '-blockdev' and that's why it's sill using the old command to set
throttling.