* [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
@ 2026-03-02 13:49 Michael Köppl
2026-03-02 14:09 ` Fiona Ebner
0 siblings, 1 reply; 6+ messages in thread
From: Michael Köppl @ 2026-03-02 13:49 UTC (permalink / raw)
To: pve-devel
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;
+ }
my $startup =
$conf->{startup} ? PVE::JSONSchema::pve_parse_startup_order($conf->{startup}) : {};
--
2.47.3
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
2026-03-02 13:49 [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot Michael Köppl
@ 2026-03-02 14:09 ` Fiona Ebner
2026-03-02 15:02 ` Michael Köppl
0 siblings, 1 reply; 6+ messages in thread
From: Fiona Ebner @ 2026-03-02 14:09 UTC (permalink / raw)
To: Michael Köppl, pve-devel
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}) : {};
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
2026-03-02 14:09 ` Fiona Ebner
@ 2026-03-02 15:02 ` Michael Köppl
2026-03-02 15:10 ` Fiona Ebner
0 siblings, 1 reply; 6+ messages in thread
From: Michael Köppl @ 2026-03-02 15:02 UTC (permalink / raw)
To: Fiona Ebner, Michael Köppl, pve-devel
On Mon Mar 2, 2026 at 3:09 PM CET, Fiona Ebner wrote:
> 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.
>
Yeah, I wasn't entirely sure printing it for every guest is a good idea
either. Thanks for the feedback. I guess something like "skipping guests
without 'onboot' set in guest config, use 'force' param to override"
once at the beginning?
> 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?
>
I agree, but --nooutput does not seem to prevent this. I'll have a look
how this can be avoided.
> 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?
I think that would make sense. AFAIK we already try to avoid negation in
names for newer params? It would also make it a lot clearer in the
implementation that these invocations are treated differently.
>
>>
>> my $startup =
>> $conf->{startup} ? PVE::JSONSchema::pve_parse_startup_order($conf->{startup}) : {};
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
2026-03-02 15:02 ` Michael Köppl
@ 2026-03-02 15:10 ` Fiona Ebner
2026-03-02 15:16 ` Michael Köppl
0 siblings, 1 reply; 6+ messages in thread
From: Fiona Ebner @ 2026-03-02 15:10 UTC (permalink / raw)
To: Michael Köppl, pve-devel
Am 02.03.26 um 4:02 PM schrieb Michael Köppl:
> On Mon Mar 2, 2026 at 3:09 PM CET, Fiona Ebner wrote:
>> 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.
>>
>
> Yeah, I wasn't entirely sure printing it for every guest is a good idea
> either. Thanks for the feedback. I guess something like "skipping guests
> without 'onboot' set in guest config, use 'force' param to override"
> once at the beginning?
>
>> 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?
>>
>
> I agree, but --nooutput does not seem to prevent this. I'll have a look
> how this can be avoided.
If it can't easily be avoided, I guess the message is best formulated in
a purely descriptive way, i.e. without "use to override", and rather
just mention that it's because force is not set.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
2026-03-02 15:10 ` Fiona Ebner
@ 2026-03-02 15:16 ` Michael Köppl
2026-03-02 15:20 ` Fiona Ebner
0 siblings, 1 reply; 6+ messages in thread
From: Michael Köppl @ 2026-03-02 15:16 UTC (permalink / raw)
To: Fiona Ebner, Michael Köppl, pve-devel
On Mon Mar 2, 2026 at 4:10 PM CET, Fiona Ebner wrote:
> Am 02.03.26 um 4:02 PM schrieb Michael Köppl:
>> On Mon Mar 2, 2026 at 3:09 PM CET, Fiona Ebner wrote:
>>> 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.
>>>
>>
>> Yeah, I wasn't entirely sure printing it for every guest is a good idea
>> either. Thanks for the feedback. I guess something like "skipping guests
>> without 'onboot' set in guest config, use 'force' param to override"
>> once at the beginning?
>>
>>> 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?
>>>
>>
>> I agree, but --nooutput does not seem to prevent this. I'll have a look
>> how this can be avoided.
>
> If it can't easily be avoided, I guess the message is best formulated in
> a purely descriptive way, i.e. without "use to override", and rather
> just mention that it's because force is not set.
Ack, thanks! I'll send a v2.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot
2026-03-02 15:16 ` Michael Köppl
@ 2026-03-02 15:20 ` Fiona Ebner
0 siblings, 0 replies; 6+ messages in thread
From: Fiona Ebner @ 2026-03-02 15:20 UTC (permalink / raw)
To: Michael Köppl, pve-devel
Am 02.03.26 um 4:16 PM schrieb Michael Köppl:
> On Mon Mar 2, 2026 at 4:10 PM CET, Fiona Ebner wrote:
>> Am 02.03.26 um 4:02 PM schrieb Michael Köppl:
>>> On Mon Mar 2, 2026 at 3:09 PM CET, Fiona Ebner wrote:
>>>> 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.
>>>>
>>>
>>> Yeah, I wasn't entirely sure printing it for every guest is a good idea
>>> either. Thanks for the feedback. I guess something like "skipping guests
>>> without 'onboot' set in guest config, use 'force' param to override"
>>> once at the beginning?
>>>
>>>> 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?
>>>>
>>>
>>> I agree, but --nooutput does not seem to prevent this. I'll have a look
>>> how this can be avoided.
>>
>> If it can't easily be avoided, I guess the message is best formulated in
>> a purely descriptive way, i.e. without "use to override", and rather
>> just mention that it's because force is not set.
>
> Ack, thanks! I'll send a v2.
If you only want it for CLI you can check the rpcenv type. I guess we
can expect API users to read the description before using the endpoint.
In the UI we always use it anyways (from a quick glance).
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-03-02 15:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-02 13:49 [PATCH manager v1 1/1] api: startall: print info message if guest is skipped due to no onboot Michael Köppl
2026-03-02 14:09 ` Fiona Ebner
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
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.