public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
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(-)
> 





      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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal