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(a)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