Red Hat Bugzilla – Bug 1262041
QEMU Throttling of Persistent Volumes backed by RBD
Last modified: 2016-04-07 17:08:09 EDT
Need to test that a max IOPS rule can be applied against a VM connected to a RBD volume managed by Cinder.
"Part 3 for blueprint quota-instance-resource, by setting exposed params
"disk_read_bytes_sec, disk_read_iops_sec, disk_write_bytes_sec,
disk_write_iops_sec, disk_total_bytes_sec, disk_total_iops_sec"
through nova flavor-set, user can implement instance disk IO control
nova flavor-set m1.medium set disk_write_bytes_sec=10240000,
then the max disk write IO is 10MB/s for VM user."
The verification failed with the following packages:
My steps were:
1. added the property from comment 8
# nova flavor-key m1.tiny set disk_write_bytes_sec=10240000
2. tried to launch an instance
3. tried to launch an instance with a flavor with similar values as the tiny flavor, without the additional property and the instance launch was successful
Yogev please provide logs and more information on what the error was in (2). Also can you confirm that while the steps are listed as being manually executed this is also being added to automation?
Created attachment 1122709 [details]
Logs from the controllers
Adding the log from the controllers and the details of the instance.
(In reply to Stephen Gordon from comment #8)
> nova flavor-set m1.medium set disk_write_bytes_sec=10240000,
> then the max disk write IO is 10MB/s for VM user."
Thanks Yogev, one other thing. I notice you used this command to set the throttling level:
$ nova flavor-set m1.medium set disk_write_bytes_sec=10240000
Can you try again with this:
$ nova flavor-set m1.medium set quota:disk_write_bytes_sec=10240000
The request appears to be failing out of the ComputeCapabilitiesFilter, I am wondering if this is because the lack of the quota: namespacing results in it being picked up by the wrong filter.
Checked it with the modification - it works well.
The disk configuration of the instance is:
<disk type="network" device="disk">
<driver type="raw" cache="none"/>
<source protocol="rbd" name="vms/3084fd6a-64b1-4560-ba0b46792d21418d_disk">
<host name="10.35.182.137" port="6789"/>
<host name="10.35.182.138" port="6789"/>
<host name="10.35.182.139" port="6789"/>
<secret type="ceph" uuid="84099bea-c9db-11e5-a169-52540097887b"/>
<target bus="virtio" dev="vda"/>
changing to verify.
Thanks Yogev, just following up on one other earlier question - does this mean we now also have automation coverage of this feature?
No, we don't have an automated test for this feature at the moment. It will be automated in the near future.
We do have a test plan for it ready
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.