On 01/25/2017 04:16 AM, Martin Kletzander wrote:
We were setting it based on whether it was supported and that lead to setting it to NULL, which our JSON code caught. However it ended up producing the following results:
$ virsh blkdeviotune fedora vda --total-bytes-sec-max 2000 error: Unable to change block I/O throttle error: internal error: argument key 'group' must not have null value
Signed-off-by: Martin Kletzander <mkletzan@redhat.com> --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 516a851d3d55..f45972e3c823 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -17506,7 +17506,7 @@ qemuDomainSetBlockIoTune(virDomainPtr dom, qemuDomainObjEnterMonitor(driver, vm); ret = qemuMonitorSetBlockIoThrottle(priv->mon, device, &info, supportMaxOptions, - supportGroupNameOption, + set_fields & QEMU_BLOCK_IOTUNE_SET_GROUP_NAME, supportMaxLengthOptions); if (qemuDomainObjExitMonitor(driver, vm) < 0) ret = -1;
I believe this should be a change to qemuMonitorJSONSetBlockIoThrottle to use 'S' instead of 's' in the virJSONValueObjectAdd call. Been too long to remember why I went with 's' - although I wonder if it had to do with "unsetting" the value... I do believe I should have gone with my first instincts on this and should have made the design around allowing the user to define a group number to use and then convert that into a group name string with a static prefix and the number <sigh>. ACK with that change. John