From: Samuel Rufinatscha <s.rufinatscha@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [PATCH qemu-server v2 0/1] fix #7590: apply timeout to QEMU start fork
Date: Mon, 17 Aug 2026 16:52:08 +0200 [thread overview]
Message-ID: <5abba171-35e8-4607-8c21-331aee839e11@proxmox.com> (raw)
In-Reply-To: <20260803172152.331208-1-s.rufinatscha@proxmox.com>
Hi all,
I also tested timeout cleanup followed by a successful start and stop
with raw and qcow2 TPM state volumes on a temporary directory storage.
The qcow2 setup used the QSD + FUSE path.
The relevant helper processes and the VM scope were removed and the VM
configuration lock was released for both TPM cases.
On 8/3/26 7:21 PM, Samuel Rufinatscha wrote:
> The qmstart task forks a child process that enters the VM scope, starts
> the helper processes and launches QEMU. qmstart then waits for the
> child to report success or failure. While regular starts already apply
> $start_timeout to the QEMU command, the wait for the forked child has
> no timeout. Statefile starts do not use the QEMU command timeout
> either, leaving both waits unbounded.
>
> Timeout handling currently:
>
> Start type QEMU command timeout forked startup timeout
> ------------------------------------------------------------------------------
> regular $start_timeout none
> statefile none none
>
> Timeout handling after this series:
>
> Start type QEMU command timeout fork startup timeout
> ------------------------------------------------------------------------------
> regular $start_timeout 2 * $start_timeout (account for helpers)
> statefile with --timeout N none N
> statefile without --timeout none 24 hours (as fallback)
>
> Regular starts retain the existing QEMU command timeout and is twice
> for the outer timeout to account for VM scope and helper setup.
> Statefile starts continue to have no separate QEMU
> command timeout. If --timeout N is specified, N is used as the deadline
> for the complete forked startup, otherwise a 24 hour fallback is used.
> Values can be changed if needed.
>
> Tested on a PVE 9.2 node:
> - the statefile/FIFO timeout released the configuration lock and left
> no QEMU process or VM scope behind, using the reproducer from [1]
> - the existing regular QEMU timeout still fired before the outer
> safeguard
> - an immediate QEMU startup error performed the same scope cleanup
> - successful startup and shutdown continued to work
>
> Note: the separate D-state waitpid() FIXME in
> run_fork_with_timeout() [2] concerns the timeout handling itself
> potentially blocking indefinitely and is therefore out of scope for
> this series.
>
> [0] https://lore.proxmox.com/pve-devel/20260625114500.159384-1-s.rufinatscha@proxmox.com/
> [1] https://bugzilla.proxmox.com/show_bug.cgi?id=7590
> [2] https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/Tools.pm;h=8e7646dea43e092fc9ec76b493b418a7ca0eaee2;hb=5054082fe492429fc37574985c2ca812af9a3125#l604
>
> Samuel Rufinatscha (1):
> fix #7590: qemu-server: apply timeout to QEMU start fork
>
> src/PVE/QemuServer.pm | 93 +++++++++++++++++++++++++++++++++++--------
> 1 file changed, 77 insertions(+), 16 deletions(-)
>
prev parent reply other threads:[~2026-08-17 14:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 17:21 [PATCH qemu-server v2 0/1] fix #7590: apply timeout to QEMU start fork Samuel Rufinatscha
2026-08-03 17:21 ` [PATCH qemu-server v2 1/1] fix #7590: qemu-server: " Samuel Rufinatscha
2026-08-17 14:52 ` Samuel Rufinatscha [this message]
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=5abba171-35e8-4607-8c21-331aee839e11@proxmox.com \
--to=s.rufinatscha@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox