all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Friedrich Weber <f.weber@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server] vm start: set minimum timeout of 300s if using PCI passthrough
Date: Mon, 21 Aug 2023 10:33:23 +0200	[thread overview]
Message-ID: <b7f629db-7689-c796-0f10-5175c49c0fd7@proxmox.com> (raw)
In-Reply-To: <20230503133723.165739-1-f.weber@proxmox.com>

Am 03.05.23 um 15:37 schrieb Friedrich Weber:
> The default VM startup timeout is max(30, VM memory in GiB) seconds.
> Multiple reports in the forum [0] [1] and the bug tracker [2] suggest
> this is too short when using PCI passthrough with a large amount of VM
> memory, since QEMU needs to map the whole memory during startup (see
> comment #2 in [2]). As a result, VM startup fails with "got timeout".
> 
> To work around this, ensure that the startup timeout is at least 300s
> in case the VM config contains at least one `hostpci[n]` option.
> 
> [0]: https://forum.proxmox.com/threads/83765/post-552071
> [1]: https://forum.proxmox.com/threads/126398/post-552807
> [2]: https://bugzilla.proxmox.com/show_bug.cgi?id=3502
> 
> Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
> ---

Would it make sense to instead add a constant multiplier to the memory
timeout heuristic in presence of PCI passthrough? The user says 65 GiB
takes about 3 min 30 s, so assuming it's more or less linear, the 5 min
from this patch would not be enough for more than ~130 GiB of memory.

> 
> Notes:
>     An alternative workaround is offered by an unapplied patch series [3]
>     of bug #3502 [2] that makes it possible to set VM-specific timeouts
>     (also in the GUI). Users could use this option to manually set a
>     higher timeout for VMs that use PCI passthrough. However, it is not
>     immediately obvious that a higher timeout is necessary. Since the
>     problem seems to come up somewhat frequently, I think it makes sense
>     to have the heuristic choose a higher timeout by default.
>     
>     [2]: https://bugzilla.proxmox.com/show_bug.cgi?id=3502
>     [3]: https://lists.proxmox.com/pipermail/pve-devel/2023-January/055352.html

Yes, I think having both the better heuristic and the configurable
timeout makes sense. Since Daniel left, do you want to have another look
at the series/pick it up?




  reply	other threads:[~2023-08-21  8:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-03 13:37 Friedrich Weber
2023-08-21  8:33 ` Fiona Ebner [this message]
2023-09-08 11:40   ` Friedrich Weber
2023-09-11  7:03     ` 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=b7f629db-7689-c796-0f10-5175c49c0fd7@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=f.weber@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