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.
