From nobody Mon Apr 29 03:15:13 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1548779062001730.318652228761; Tue, 29 Jan 2019 08:24:22 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7C17A81DE9; Tue, 29 Jan 2019 16:24:17 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E7ABC16E25; Tue, 29 Jan 2019 16:24:16 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id EBA843F602; Tue, 29 Jan 2019 16:24:15 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x0TGOFuw013818 for ; Tue, 29 Jan 2019 11:24:15 -0500 Received: by smtp.corp.redhat.com (Postfix) id 9DB4A2C6C0; Tue, 29 Jan 2019 16:24:15 +0000 (UTC) Received: from angien.brq.redhat.com (unknown [10.43.2.229]) by smtp.corp.redhat.com (Postfix) with ESMTP id ED7024C494; Tue, 29 Jan 2019 16:24:12 +0000 (UTC) From: Peter Krempa To: libvir-list@redhat.com Date: Tue, 29 Jan 2019 17:24:09 +0100 Message-Id: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Cc: Peter Krempa Subject: [libvirt] [PATCH] qemu: blockjob: Don't report block job progress at 100% if job isn't ready X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 29 Jan 2019 16:24:19 +0000 (UTC) Content-Type: text/plain; charset="utf-8" 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 --- 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(qemuMonitorBlockJobInfoP= tr rawInfo, } } + /* If qemu reports that it's not ready yet don't make the job go to + * cur =3D=3D end as some apps wrote code polling this instead of wait= ing for + * the ready event */ + if (rawInfo->ready =3D=3D 0 && + info->cur =3D=3D info->end && + info->cur > 0) + info->cur -=3D 1; + info->type =3D rawInfo->type; if (info->type =3D=3D VIR_DOMAIN_BLOCK_JOB_TYPE_COMMIT && disk->mirrorJob =3D=3D VIR_DOMAIN_BLOCK_JOB_TYPE_ACTIVE_COMMIT) --=20 2.20.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list