all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH qemu-server 4/6] fix #6424: increase timeout for QMP 'quit' to 60s to avoid issue with bulk suspend
Date: Wed, 27 May 2026 13:00:48 +0200	[thread overview]
Message-ID: <20260527110106.287916-5-f.ebner@proxmox.com> (raw)
In-Reply-To: <20260527110106.287916-1-f.ebner@proxmox.com>

The 'quit' QMP command itself is fast, since it only records the
shutdown request and notifies the main loop, but getting the response
can take a while. The reason is that qmp_dispatch() yields and must be
woken after executing the command and at that stage, QEMU is already
busy with teardown too.

In practice, users can run into the default timeout of 5 seconds when
doing bulk suspend.

The 'quit' QMP command is only used as part of (potentially)
longer-running operations already:
- VM hibernation
- VM stop
- QSD quit:
  - after enrolling EFI disk certs
  - terminating instance for TPM

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 src/PVE/QMPClient.pm | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/src/PVE/QMPClient.pm b/src/PVE/QMPClient.pm
index 7610121a..a43e661b 100644
--- a/src/PVE/QMPClient.pm
+++ b/src/PVE/QMPClient.pm
@@ -156,6 +156,12 @@ sub cmd {
             || $cmd->{execute} eq 'blockdev-snapshot-internal-sync'
         ) {
             $timeout = 60 * 60; # 1 hour
+        } elsif ($cmd->{execute} eq 'quit') {
+            # The 'quit' QMP command itself is fast, since it only records the shutdown request and
+            # notifies the main loop, but getting the response can take a while. The reason is that
+            # qmp_dispatch() yields and must be woken after executing the command and at that stage,
+            # QEMU is already busy with teardown too.
+            $timeout = 60;
         } else {
             #  NOTE: if you came here as user and want to change this, try using IO-Threads first
             # which move out quite some processing of the main thread, leaving more time for QMP
-- 
2.47.3





  parent reply	other threads:[~2026-05-27 11:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-27 11:00 [PATCH-SERIES qemu/qemu-server 0/6] fix #6424: avoid timeout issue for QMP 'quit' for bulk suspend Fiona Ebner
2026-05-27 11:00 ` [PATCH qemu 1/6] regenerate patches to restore incremental numbering Fiona Ebner
2026-05-27 11:00 ` [PATCH qemu 2/6] async snapshot: allow skipping VM start after successful completion Fiona Ebner
2026-05-27 11:00 ` [PATCH qemu 3/6] update submodule and patches to QEMU 11.0.1 Fiona Ebner
2026-05-27 11:00 ` Fiona Ebner [this message]
2026-05-27 11:00 ` [PATCH qemu-server 5/6] run state: use v5.36 and signatures in module Fiona Ebner
2026-05-27 11:00 ` [PATCH qemu-server 6/6] suspend: skip VM start after successfully saving state Fiona Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260527110106.287916-5-f.ebner@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal