From nobody Fri Apr 19 19:19:38 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 1539876547915907.1754585600149; Thu, 18 Oct 2018 08:29:07 -0700 (PDT) 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 4BA76307D868; Thu, 18 Oct 2018 15:29:05 +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 25F8567E64; Thu, 18 Oct 2018 15:29:04 +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 6D2364BB79; Thu, 18 Oct 2018 15:29:01 +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 w9IFSxqd020566 for ; Thu, 18 Oct 2018 11:28:59 -0400 Received: by smtp.corp.redhat.com (Postfix) id C3A9367E64; Thu, 18 Oct 2018 15:28:59 +0000 (UTC) Received: from unknown54ee7586bd10.attlocal.net.com (ovpn-116-156.phx2.redhat.com [10.3.116.156]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7B86C781E7 for ; Thu, 18 Oct 2018 15:28:56 +0000 (UTC) From: John Ferlan To: libvir-list@redhat.com Date: Thu, 18 Oct 2018 11:28:53 -0400 Message-Id: <20181018152853.5357-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] qemu: Restore lost shutdown reason 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.48]); Thu, 18 Oct 2018 15:29:06 +0000 (UTC) X-ZohoMail: RDMRC_0 RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" When qemuProcessReconnectHelper was introduced (commit d38897a5d) reconnection failure used VIR_DOMAIN_SHUTOFF_FAILED; however, that was changed in commit bda2f17d to either VIR_DOMAIN_SHUTOFF_CRASHED or VIR_DOMAIN_SHUTOFF_UNKNOWN. When QEMU_CAPS_NO_SHUTDOWN checking was removed in commit fe35b1ad6 the conditional state was just left at VIR_DOMAIN_SHUTOFF_CRASHED. Restore the logic adjustment using the same conditions as command line building and alter the comment to describe the reasoning. Signed-off-by: John Ferlan --- This was "discovered" while reviewing Nikolay's patch related to adding "DAEMON" as the shutdown reason: https://www.redhat.com/archives/libvir-list/2018-October/msg00493.html While working through the iterations of that - figured I'd at least post this. src/qemu/qemu_process.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 3955eda17c..4a39111d51 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -7985,11 +7985,16 @@ qemuProcessReconnect(void *opaque) if (virDomainObjIsActive(obj)) { /* We can't get the monitor back, so must kill the VM * to remove danger of it ending up running twice if - * user tries to start it again later - * If we couldn't get the monitor since QEMU supports - * no-shutdown, we can safely say that the domain - * crashed ... */ - state =3D VIR_DOMAIN_SHUTOFF_CRASHED; + * user tries to start it again later. + * + * If we cannot get to the monitor when the QEMU command + * line used -no-shutdown, then we can safely say that the + * domain crashed; otherwise we don't really know. */ + if (priv->monJSON && priv->allowReboot =3D=3D VIR_TRISTATE_BOOL_YE= S) + state =3D VIR_DOMAIN_SHUTOFF_CRASHED; + else + state =3D VIR_DOMAIN_SHUTOFF_UNKNOWN; + /* If BeginJob failed, we jumped here without a job, let's hope an= other * thread didn't have a chance to start playing with the domain yet * (it's all we can do anyway). --=20 2.17.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list