Bug 1907720

Summary:	Dynamic management of throughput across qcow2-based virtual disks
Product:	Red Hat Enterprise Linux 9	Reporter:	Piyush Shivam <piyush.shivam>
Component:	libvirt	Assignee:	Peter Krempa <pkrempa>
libvirt sub component:	Storage	QA Contact:	Han Han <hhan>
Status:	CLOSED WONTFIX	Docs Contact:
Severity:	medium
Priority:	medium	CC:	coli, jinzhao, jsuchane, juzhang, kwolf, lmen, pkrempa, vgoyal, virt-maint, xuzhang, yalzhang, zhencliu, zixchen
Version:	9.0	Keywords:	FutureFeature, Triaged
Target Milestone:	rc
Target Release:	9.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-03-15 14:42:50 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Piyush Shivam 2020-12-15 03:53:32 UTC

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:

Comment 1 John Ferlan 2020-12-23 11:48:49 UTC

Assigned to Ademar for initial triage per bz process and age of bug created or assigned to virt-maint without triage.

Comment 3 qing.wang 2020-12-24 09:25:57 UTC

It sounds like throttle-group feature

Comment 6 Peter Krempa 2021-02-02 15:48:53 UTC

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.

Comment 9 Stefan Hajnoczi 2021-03-17 10:51:05 UTC

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.

Comment 10 John Ferlan 2021-09-08 21:55:10 UTC

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 11 Peter Krempa 2022-03-21 09:16:24 UTC

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.