Feature Request: Power Cycle option

[stuartbh]

Proxmoxers,

On the power button option drop down it has options for: Reboot, Pause, Hibernate, Stop, Reset
I suggest adding a "power cycle" option.

Let us presume make a hardware configuration change and just wish to order Proxmox to power cycle the VM, pick up the change and reboot basically. One would think "reset" should do this, but it does not. Thus, I request we add a power cycle option that will hard power off and hard power back on the VM.

Thanks!

Stuart

 

[BobhWasatch]

A stop + start will do that.

 

[Impact]

The Reboot button does that already.

 

[stuartbh]

Impact,

All I can say is that I have the latest version of Proxmox (8.4.1), and it does NOT function as you state.

Try these steps:
1) a VM is booted up and running.
2) a hardware change is made.
3) you click reboot expecting to get a "power off and power on" so that the VM is STOPPED NOT SHUTDOWN (there is a difference), hardware change is picked up and rebooted. <- REBOOT DOES NOT DO THIS.

Whatever you think you know from reading is not what is actually occurring. I dare you to test your theory as I have described with the latest version of Proxmox so you can see your assertions are fully incorrect.

What I am asking for is a power cycle button, a one step process to power off (not shutdown) a VM, pickup hardware changes, power it back on and boot it up.

Stuart

 

[stuartbh]

A stop + start will do that.

Right, and I am asking for a drop menu selection that combines both a start and stop as a "Power cycle" option. Click that option, walk away, and it just does all the start and stop steps forthrightly.

Stuart

 

[janus57]

Hi,

Whatever you think you know from reading is not what is actually occurring. I dare you to test your theory as I have described with the latest version of Proxmox so you can see your assertions are fully incorrect.

Well, you are wrong, tested and it's working as expected (tested on VM with qemu agent enabled).

Best regards,

 

[leesteken]

Well, you are wrong, tested and it's working as expected (tested on VM with qemu agent enabled).

Yes, but Reboot does a (controlled) Shutdown (which is why you want QEMU guest agent) followed by a Start, which is often what people want. However, this thread is about a request for a (instant) Stop followed by a Start. Reset does something similar but does not apply virtual hardware changes (which a Stop followed by a Start does). I don't know why a Reset does not apply hardware changes. I don't know, in my limited imagination, what the use case is to reset the VM but with old settings, since if that was what I wanted then I would not have changed the VM settings.

 

[janus57]

Hi,

Well, if the agent is not configured, it still does a stop+start.
And yes I have tested, and it seems to send the ACPI signal to power off the machine which is way better than, a hard stop+start.

Best regards,

 

[leesteken]

And yes I have tested, and it seems to send the ACPI signal to power off the machine which is way better than, a hard stop+start.

Yes, you are right about that being (way) better. But just suppose some user does not want or need that, as the VM might be booting from a virtual CD-ROM or other read-only media. I do believe this thread is about a use case where someone wants a hard stop. I don't see why Reset should not provide this functionality.

EDIT: Please realize that when no OS has been installed or when the OS inside the VM does not boot properly, ACPI (and QEMU guest agent) does not work and people have to wait for the Shutdown to timeout and fall back to a Stop anyway. I've had this situation with VMs booting from an ISO with the wrong virtual hardware configuration. I don't mind using Stop and then Start but I see how this feature request would make sense and save clicks.

 

[gfngfn256]

Yes, but Reboot does a (controlled) Shutdown (which is why you want QEMU guest agent) followed by a Start. This thread is about a request for a (instant) Stop followed by a Start.

Not exactly - the OP stated:

3) you click reboot expecting to get a "power off and power on" so that the VM is STOPPED NOT SHUTDOWN (there is a difference), hardware change is picked up and rebooted. <- REBOOT DOES NOT DO THIS.

While it is true that Reboot is not a Stop + Start, the OP implies that in his instance the Reboot option does not pickup HW changes. This is not the case. There are some changes that actually won't be "picked up" in a Reboot, such as the qemu agent used see here, but I see no use-case for his request.

But just suppose some user does not want or need that, as the VM might be booting from a virtual CD-ROM or other read-only media. I do believe this thread is about a use case where someone wants a hard stop.

Why can't he still just use Reboot? Not "needing it" is no reason to give him some other choice.

I don't see why Reset should not provide this functionality.

Probably - if someone wants to actually see if he in fact needs those changes made at all.

 

[janus57]

Hi,

I don't see why Reset should not provide this functionality.

In QEMU, it means we reset to the initial state corresponding to the start of QEMU

So the process won't pick changes (from my understanding).
Cf : https://www.qemu.org/docs/master/devel/reset.html

Still reboot respond to the "feature request", event if we have to wait the timeout.

Best regards,

 

[gfngfn256]

Reset is to be compared to pressing the Reset-button on a physical PC, which implies a hard shutdown/startup due to the inability of graceful one. Hence - it is not designed for HW changes. If you want HW changes - do a Reboot.

 

[leesteken]

Not exactly - the OP stated:

While it is true that Reboot is not a Stop + Start, the OP implies that in his instance the Reboot option does not pickup HW changes. This is not the case.

I think you can read that (imprecise) sentence differently where the OP implies only that Reboot does not do a Stop (but a Shutdown instead). Can we please agree that multiple interpretations of that (short natural language) sentence are possible?

There are some changes that actually won't be "picked up" in a Reboot, such as the qemu agent used see here,

interesting, does the new version of QEMU executable really not get used during the start of the new process? I find that unlikely but not impossible. But also not related to this thread if you read the sentence in the way that I interpreted it.

but I see no use-case for his request.

I do and have run into this when choosing the wrong virtual hardware when starting a VM from and ISO to install some OS. Of course a Stop followed by a Start also works fine (but shows an confirmation dialog and requires an additional click).

Why can't he still just use Reboot? Not "needing it" is no reason to give him some other choice.

Some VMs, especially those without an OS installed or which are wrongly configured (so that it does not boot), don't respond to a Shutdown (unless it times out and does a Stop eventually), and therefore respond badly to a Reboot.

Reset is to be compared to pressing the Reset-button on a physical PC, which implies a hard shutdown/startup due to the inability of graceful one. Hence - it is not designed for HW changes.

Sure, maybe Reset should not respond to hardware changes but that's just my suggestion and not the OP's. Then again, I would expect real hardware to respond to a hardware changes between pressing and releasing the reset button but I have not tried as most consumer systems that I own don't allow for hot-plug.
Anyway, I do think this semantic discussion is relevant. OP ask for a button that does Stop followed by a Start, like Reboot does a Shutdown followed by a Start.

I guess it's pointless to argue further about what the OP wants unless @stuartbh replies and confirms which interpretation is what they wanted. I did not expect this to escalate into a semantics discussion so quickly and I'm sorry if I caused it.

 

[stuartbh]

Yes, but Reboot does a (controlled) Shutdown (which is why you want QEMU guest agent) followed by a Start, which is often what people want. However, this thread is about a request for a (instant) Stop followed by a Start. Reset does something similar but does not apply virtual hardware changes (which a Stop followed by a Start does). I don't know why a Reset does not apply hardware changes. I don't know, in my limited imagination, what the use case is to reset the VM but with old settings, since if that was what I wanted then I would not have changed the VM settings.

Exactly.

I boot netbootxyz from a docker container hosted on my TrueNAS server, as such it boots as a read only device like a CD-ROM. It then HTTP boots the OS I select. In my case, the HTTP boot failed and I was in a recovery shell for the Kali Linux ISO I tried to boot, ACPI did not work.

I am not convinced that @janus57 actually had an operating system booted up first and as well he was not using UEFI he was using BIOS. When I booted netbootxy under UEFI and then changed the SCSI controller a reboot nor a reset applied that hardware change.

I do appreciate @janus57 taking the time to test and try to prove it works, if I had missed something I am open minded. However, I was unable to repeat his test and presume he had not booted into an actual environment when doing his test. I had an OS running when I tried it.

It is not just a semantic difference it is a FUNCTIONAL difference to be desirous of a power cycle option.

Presuming there are use cases for reboot and reset to work as they do currently, adding power cycle option would simply add new functionality for such circumstances where it too was reasonably applicable as a use case. I'd also be open to having a configuration option where in a VM avoids or forces a confirmation if a power cycle is requested.


Stuart

 

[gfngfn256]

Can we please agree that multiple interpretations of that (short natural language) sentence are possible?

Agreed. I wrote "implies" for that reason.

interesting, does the new version of QEMU executable really not get used during the start of the new process?

Yes, I tested it personally, even with a GA.

Some VMs, especially those without an OS installed or which are wrongly configured (so that it does not boot), don't respond to a Shutdown (unless it times out and does a Stop eventually), and therefore respond badly to a Reboot.

While I have had the same experience, in these (rare) instances I prefer the on-hand experience of totally stopping the VM & starting again fresh.

Anyway, I do think this semantic discussion is relevant. OP ask for a button that does Stop followed by a Start, like Reboot does a Shutdown followed by a Start.

I totally agree that even semantical conversations are often very useful to the further enhancement of the subject being discussed.

In my opinion, I think labels/buttons should closely match AMAP "what it says on the label". So Reset is just that. I don't think anyone on a PC used the Reset button while changing his HW.

If some users really want a Power Cycle button, let that button be so labeled. (While the user may gain a click or two, I wonder how many "clicks" the programming will take!) As I've said above; I don't need it nor would I use it - BUT I'm not the only user on this planet!

I did not expect this to escalate into a semantics discussion so quickly and I'm sorry if I caused it.

I ALWAYS enjoy any input you have (and also learn from it). Sorry is inappropriate here.

I am not convinced that @janus57 actually had an operating system booted up first and as well he was not using UEFI he was using BIOS. When I booted netbootxy under UEFI and then changed the SCSI controller a reboot nor a reset applied that hardware change.

I had an OS running when I tried it.

I tested (again) with a fully running Debian server VM UEFI (& GA) - all changes are picked up on Reboot:

It is not just a semantic difference it is a FUNCTIONAL difference to be desirous of a power cycle option.

I am in no position to argue with your personally experienced use-case of needing this function. I can only say (as above) that I don't need it.

adding power cycle option would simply add new functionality

And should be so labelled: Power Cycle

I'd also be open to having a configuration option where in a VM avoids or forces a confirmation if a power cycle is requested.

If you mean within the VM - I don't see that happening. In a niche-case of a presumably non-running or non-responsive VM, we can't expect this functionality. If however you mean within PVE concerning the power-cycling of the VM - I believe confirmation is definitely desirable.