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@xxxxxxxxxx> > --- > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
