From: Samuel Rufinatscha <s.rufinatscha@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [PATCH qemu-server v2 0/1] fix #7590: apply timeout to QEMU start fork
Date: Mon, 3 Aug 2026 19:21:51 +0200 [thread overview]
Message-ID: <20260803172152.331208-1-s.rufinatscha@proxmox.com> (raw)
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(-)
--
2.47.3
next reply other threads:[~2026-08-03 17:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 17:21 Samuel Rufinatscha [this message]
2026-08-03 17:21 ` [PATCH qemu-server v2 1/1] fix #7590: qemu-server: apply timeout to QEMU start fork Samuel Rufinatscha
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=20260803172152.331208-1-s.rufinatscha@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