virsh blkdeviotune expects values in raw bytes, which is kinda inconvenient considering it's likely dealing with values at least over 1M. Hopefully not too difficult given that we've already got virScaleInteger(). There are probably other commands that could us a similar treatment.
Basically all that needs to be done is convert the uses of vshCommandOptULongLong in virsh-domain.c:cmdBlkdeviotune to use vshCommandOptScaledInt This shows the current IO tuning values for a running VM with target dev=vda in the XML: $ sudo virsh blkdeviotune f23 vda total_bytes_sec: 0 read_bytes_sec : 0 write_bytes_sec: 0 total_iops_sec : 0 read_iops_sec : 0 write_iops_sec : 0 total_bytes_sec_max: 0 read_bytes_sec_max: 0 write_bytes_sec_max: 0 total_iops_sec_max: 0 read_iops_sec_max: 0 write_iops_sec_max: 0 size_iops_sec : 0 You can set a value like: $ sudo virsh blkdeviotune f23 vda --read-iops-sec 1024 Then see the changed result with: $ sudo virsh blkdeviotune f23 vda | grep read_iops_sec read_iops_sec : 1024 read_iops_sec_max: 102 After the changes, you'll want to ensure all the opts can take values like --read-iops-sec 1M
I've just pushed fix upstream: commit 161713436e00a8532be3d936eec095120b8c6a1a Author: Nishith Shah <nishithshah.2211> AuthorDate: Wed May 4 14:25:10 2016 +0000 Commit: Michal Privoznik <mprivozn> CommitDate: Mon May 9 07:48:08 2016 +0200 virsh: blkdeviotune: accept human readable values for bytes https://bugzilla.redhat.com/show_bug.cgi?id=885380 Use vshCommandOptScaledInt instead of vshCommandOptULongLong so that values with suffixes can be passed when bytes are being passed along. Values for the iops parameters still need to be given in the absolute form as they are not bytes but numbers. Signed-off-by: Nishith Shah <nishithshah.2211> v1.3.4-169-g1617134