From nobody Mon Feb 9 00:54:03 2026 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 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1512474324238634.0798060047518; Tue, 5 Dec 2017 03:45:24 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 42DD1C058EC1; Tue, 5 Dec 2017 11:45:23 +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 1ED1E18876; Tue, 5 Dec 2017 11:45:23 +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 DEFED3D386; Tue, 5 Dec 2017 11:45:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id vB5BisfF025653 for ; Tue, 5 Dec 2017 06:44:54 -0500 Received: by smtp.corp.redhat.com (Postfix) id 5C20D60605; Tue, 5 Dec 2017 11:44:54 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-117-84.phx2.redhat.com [10.3.117.84]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2397F18854 for ; Tue, 5 Dec 2017 11:44:54 +0000 (UTC) From: John Ferlan To: libvir-list@redhat.com Date: Tue, 5 Dec 2017 06:44:43 -0500 Message-Id: <20171205114443.27555-11-jferlan@redhat.com> In-Reply-To: <20171205114443.27555-1-jferlan@redhat.com> References: <20171205114443.27555-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [REBASE PATCH v2 10/10] qemu: Allow showing the dump progress for memory only dump 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: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 05 Dec 2017 11:45:23 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" https://bugzilla.redhat.com/show_bug.cgi?id=3D916061 If the QEMU version running is new enough (based on the DUMP_COMPLETED event), then we can add a 'detach' boolean to the dump-guest-memory command in order to tell QEMU to run in a thread. This ensures that we don't lock out other commands while the potentially long running dump memory is completed. This allows the usage of a qemuDumpWaitForCompletion which will wait for the event while the qemuDomainGetJobInfoDumpStats can be used via qemuDomainGetJobInfo in order to query QEMU in order to determine how far along the job is. Signed-off-by: John Ferlan --- src/qemu/qemu_driver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++--= -- 1 file changed, 44 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d921a5e78..c35963ae9 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3751,6 +3751,34 @@ qemuDomainManagedSaveRemove(virDomainPtr dom, unsign= ed int flags) } =20 =20 +/** + * qemuDumpWaitForCompletion: + * @vm: domain object + * + * If the query dump capability exists, then it's possible to start a + * guest memory dump operation using a thread via a 'detach' qualifier + * to the dump guest memory command. This allows the async check if the + * dump is done. + * + * Returns 0 on success, -1 on failure + */ +static int +qemuDumpWaitForCompletion(virDomainObjPtr vm) +{ + qemuDomainObjPrivatePtr priv =3D vm->privateData; + + if (!priv->job.dumpCompletion) + return 0; + + VIR_DEBUG("Waiting for dump completion"); + while (!priv->job.dumpCompleted && !priv->job.abortJob) { + if (virDomainObjWait(vm) < 0) + return -1; + } + return 0; +} + + static int qemuDumpToFd(virQEMUDriverPtr driver, virDomainObjPtr vm, @@ -3759,6 +3787,7 @@ qemuDumpToFd(virQEMUDriverPtr driver, const char *dumpformat) { qemuDomainObjPrivatePtr priv =3D vm->privateData; + bool detach =3D false; int ret =3D -1; =20 if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DUMP_GUEST_MEMORY)) { @@ -3767,10 +3796,13 @@ qemuDumpToFd(virQEMUDriverPtr driver, return -1; } =20 + detach =3D virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DUMP_COMPLETED); + if (qemuSecuritySetImageFDLabel(driver->securityManager, vm->def, fd) = < 0) return -1; =20 - VIR_FREE(priv->job.current); + if (!detach) + VIR_FREE(priv->job.current); priv->job.dump_memory_only =3D true; =20 if (qemuDomainObjEnterMonitorAsync(driver, vm, asyncJob) < 0) @@ -3785,15 +3817,23 @@ qemuDumpToFd(virQEMUDriverPtr driver, "for this QEMU binary"), dumpformat); ret =3D -1; + ignore_value(qemuDomainObjExitMonitor(driver, vm)); goto cleanup; } } =20 - ret =3D qemuMonitorDumpToFd(priv->mon, fd, dumpformat, false); + ret =3D qemuMonitorDumpToFd(priv->mon, fd, dumpformat, detach); =20 - cleanup: - ignore_value(qemuDomainObjExitMonitor(driver, vm)); + if (detach && ret =3D=3D 0) + priv->job.dumpCompletion =3D true; + + if ((qemuDomainObjExitMonitor(driver, vm) < 0) || ret < 0) + goto cleanup; + + if (detach) + ret =3D qemuDumpWaitForCompletion(vm); =20 + cleanup: return ret; } =20 --=20 2.13.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list