Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Currently, we can set the bandwidth and IOPS on a specific virtual disk with iotune parameters. In a cloud setting, a customer attaches multiple virtual disks to a running VM. In this scenario, the total aggregate bandwidth and IOPS that a customer gets across all the vdisks is fixed regardless of IOPS the customer is paying for on each individual disk.
For example, a customer may order 4 vdisks, each with the 10K IOPS, but when the customer attaches them to the VM, the total aggregate IO bandwidth that the customer gets may be fixed at, e.g., 20K IOPS. That means the 20K IOPS needs to get distributed across 4 vdisks that are each labeled with 10K IOPS.
The request is to create a dynamic IOPS provisioning scheme in QEMU such that if the customer is using only 2 out of 4 attached vdisks, then the two vdisks can obtain 10K IOPS each. If the customer then starts using 4 vdisks, then the 20K aggregate IOPS automatically gets distributes across the 4 disks based on the usage of each disk.
Essentially a dynamic provisioning scheme where the total aggregate IOPS allocated to the VM's vdisks gets dynamically distributed across all the attached vdisks based on usage of each vdisk.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
From the description it looks like it will require multiple tiers of throttling, which is currently not possible. In libvirt we allow adding disks into groups via the 'group_name' throttling parameter which then makes the disks share the bandwidth as configured, but that's it. We don't support any form of nested hierarchy which qemu partially provides (missing live tuning of the parameters and live adding of throttling layers to disks).
Adding such a feature will require us to configure the throttling independently of disks and then just add the disk to the appropriate group. Providing such a hierarchy will have quite a few implications and moving parts though both on libvirt side where we need to split out the control from disks and provide APIs for managing them and on qemu side, finishing the throttle-group support and perhaps providing nested groups in case the current implementation doesn't support nesting.
Reassigning to virt-maint. Let's leave the bug open for now. Feedback from libvirt regarding QEMU's throttle-group feature will be needed to decide whether QEMU changes are required.
Peter has described the libvirt changes that would be needed. QEMU already supports the --object throttle-group feature that Qing Wang mentioned for this use case, but the runtime reconfiguration interface is work-in-progress as described by Kevin.
QEMU now supports everything we need for this feature:
throttle-groups can be layered by layering the corresponding 'throttle' block drivers, 'blockdev-reopen' should allow to exchange the specific throttle drivers if needed and the properties of the throttle driver can be modified via 'qom-set' now with a stable interface.
Moving back to libvirt for futher assesment and work.