On 1/29/19 10:24 AM, Peter Krempa wrote:
Some clients take the advice to poll virDomainGetBlockJobInfo rather
than wait for the ready event. In some cases qemu can get to 100% and
still not reach the synchronised phase.
Since we are dealing with a computer interacting, the error that the job
can't be finalized yet is not handled very well by those specific
implementations.
Our docs now correctly state to use the event.
We already munge the output for the start of the job, so we can do it
even here.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/qemu/qemu_driver.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 26edbf799f..cf500507da 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -17477,6 +17477,14 @@ qemuBlockJobInfoTranslate(qemuMonitorBlockJobInfoPtr rawInfo,
}
}
+ /* If qemu reports that it's not ready yet don't make the job go to
+ * cur == end as some apps wrote code polling this instead of waiting for
+ * the ready event */
+ if (rawInfo->ready == 0 &&
+ info->cur == info->end &&
+ info->cur > 0)
+ info->cur -= 1;
Why -= 1 instead of --?
But the patch looks sane to me.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org