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.
