]> git.ipfire.org Git - thirdparty/libvirt.git/commitdiff
qemu: blockjob: Don't report block job progress at 100% if job isn't ready
authorPeter Krempa <pkrempa@redhat.com>
Tue, 29 Jan 2019 16:17:29 +0000 (17:17 +0100)
committerPeter Krempa <pkrempa@redhat.com>
Thu, 31 Jan 2019 12:03:01 +0000 (13:03 +0100)
Some clients poll virDomainGetBlockJobInfo rather than wait for the
VIR_DOMAIN_BLOCK_JOB_READY event. In some cases qemu can get to 100% and
still not reach the synchronised phase. Initiating a pivot in that case
will fail.

Given that computers are interacting here, 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 do a similar
output adjustment in case when the progress is not available from qemu
as in that case we'd report 0 out of 0, which some apps also incorrectly
considered as 100% complete.

In this case we subtract 1 from the progress if the ready state is not
signalled by qemu if the progress was at 100% otherwise.

Signed-off-by: Peter Krempa <pkrempa@redhat.com>
src/qemu/qemu_driver.c

index 96cb108a0ed7f9662b4fb23f9bf53d89f414a4b7..2485dd93eb063956f331b9fa835a2c3302f67e06 100644 (file)
@@ -17440,6 +17440,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;
+
     info->type = rawInfo->type;
     if (info->type == VIR_DOMAIN_BLOCK_JOB_TYPE_COMMIT &&
         disk->mirrorJob == VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT)