From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id B1DBD1FF142 for ; Mon, 02 Mar 2026 15:09:10 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C53A235357; Mon, 2 Mar 2026 15:10:11 +0100 (CET) Message-ID: <8e184210-3442-4040-9423-48184aeb95be@proxmox.com> Date: Mon, 2 Mar 2026 15:09:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot To: =?UTF-8?Q?Michael_K=C3=B6ppl?= , pve-devel@lists.proxmox.com References: <20260302134929.136399-1-m.koeppl@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20260302134929.136399-1-m.koeppl@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1772460555121 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.223 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.012 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 1.188 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.93 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 5DDJNXTDIAXCIQ32YLQ3CLAF2CXRESRJ X-Message-ID-Hash: 5DDJNXTDIAXCIQ32YLQ3CLAF2CXRESRJ X-MailFrom: f.ebner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 > --- > 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}) : {};