On Thu, Jun 06, 2024 at 07:58:04 -0000, Chun Feng Wu wrote:
Thanks Peter for above comments!
My original design goal is exact the same as what QEMU doc says at
https://github.com/qemu/qemu/blob/master/docs/throttle.txt:
"In this example the individual drives have IOPS limits of 2000, 2500
and 3000 respectively but the total combined I/O can never exceed 4000
IOPS."
I haven't thought about such case: "somebody would want to apply different
throttling on a backing image", do we have such case design for other feature?
Currently, we support configuring some specifics such as the qcow2
metadata cache, which can be configured per-image and not just per disk:
https://www.libvirt.org/formatdomain.html#hard-drives-floppy-disks-cdroms
look for 'metadata_cache'. While the patchet doesn't necessarily need to
implement it for backing images at this point you need to do it so that
future change will be available.
About configuring old throttling via the 'throttle' blockdev
layer, it seems possible, however, this new design and implementation has dependency on
QEMU6, the reason about this is that starting from QEMU6, "-object"(case to
launching vm along with throttlegroup) supports json format value: e.g. -object
'{"qom-type":"throttle-group","id":"limits0","limits":{"iops-total":200}}'),
while for qemu4.2, non-stable API works: e.g. -object
throttle-group,id=limits0,x-iops-total=200, current implementation follows json way: it
calls "qemuBuildObjectCommandlineFromJSON" to create throttle-group object,
within "qemuBuildObjectCommandlineFromJSON", I see check about
QEMU_CAPS_OBJECT_JSON: virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_JSON)
Okay, but I don't see any code in this series which would limit it to
the appropriate qemu versions. In cases when this is not supported by
all qemu releases libvirt supports (currently qemu-4.2 and later) you'll
have to add a capability and interlock the new feature based on it.
in addition, for "object-add"(case to hot attach disk with throttles), it seems
QMP json format is different between QEMU 6 and QEMU 4.2 ("props" required)
Okay another case when you must stay compatible and/or reject new
configs with old qemu.
Note that adding support for experimental features (x-NAME) is not
acceptable.