From: Fiona Ebner <f.ebner@proxmox.com>
To: "Michael Köppl" <m.koeppl@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
Date: Mon, 2 Mar 2026 15:09:38 +0100 [thread overview]
Message-ID: <8e184210-3442-4040-9423-48184aeb95be@proxmox.com> (raw)
In-Reply-To: <20260302134929.136399-1-m.koeppl@proxmox.com>
Am 02.03.26 um 2:49 PM schrieb Michael Köppl:
> The documentation states that startall only starts guests with
> onboot=1 by default, and that this behavior can be overridden using the
> force parameter. However, when startall is invoked via the pvenode CLI
> without the force parameter, the Bulk Start task silently completes with
> just "TASK OK", giving no indication of why certain VMs were not started.
> The added informational message addresses this by clearly communicating
> to users why those VMs were skipped.
>
> Signed-off-by: Michael Köppl <m.koeppl@proxmox.com>
> ---
> I encountered this while using startall and stopall myself and while
> RTFM would indeed have helped, I still felt that an informational
> message would improve the user's experience, especially since stopall
> will stop all VMs without force=1, whereas startall requires the force
> param. I only added the informational messages and did not change any
> behavior because the behavior makes sense to me after thinking about
> it some more.
>
> PVE/API2/Nodes.pm | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
> index 5bd6fe492..3faa1e800 100644
> --- a/PVE/API2/Nodes.pm
> +++ b/PVE/API2/Nodes.pm
> @@ -1969,7 +1969,12 @@ sub get_start_stop_list {
> my $resList = {};
> foreach my $vmid (keys %$vmlist) {
> my $conf = $vmlist->{$vmid}->{conf};
> - next if $autostart && !$conf->{onboot};
> +
> + if ($autostart && !$conf->{onboot}) {
> + print
> + "skipping $vmid because 'onboot' is not set in guest config, use 'force' parameter to override\n";
> + next;
> + }
I think printing it for every single guest without onboot is too much,
because there could be thousands of such guests. One message at the
beginning of the API call should be enough.
And I feel like the invocation from pve-guests.service should not have
such a message end up in syslog to avoid confusion. It uses
/usr/bin/pvesh --nooutput create /nodes/localhost/startall
so maybe this is already the case. Could you check?
Maybe for PVE 10 it could be flipped around with an explicit 'boot' flag
to indicate that the invocation is the one for boot-up?
>
> my $startup =
> $conf->{startup} ? PVE::JSONSchema::pve_parse_startup_order($conf->{startup}) : {};
next prev parent reply other threads:[~2026-03-02 14:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 13:49 Michael Köppl
2026-03-02 14:09 ` Fiona Ebner [this message]
2026-03-02 15:02 ` Michael Köppl
2026-03-02 15:10 ` Fiona Ebner
2026-03-02 15:16 ` Michael Köppl
2026-03-02 15:20 ` 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=8e184210-3442-4040-9423-48184aeb95be@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=m.koeppl@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.