Suggestions on noVnc commands

[bellocarico]

I have just started with Proxmox and I don't regret a single min having overwritten my old ESXi installation. I just love it.
As a new starter I have some feedbacks I would like to share with the developers.

In this thread particularly I would like to cover the noVNC menu:




Feedbacks:

a) It seems like this menu is a bit confusing as some option are for the VM other for the interface. Even if I know what they mean I need to re-read the options multiple times to remind myself what each button does and I guess I'm not the only one. So as a starter how about adding a context to the button names? e.g. 'Start VM' / 'Shutdown VM' / ..../ 'Reload noVNC' ? I do like short names but if these generate more questions that they answer perhaps some modification is need.

b) I personally miss the command 'Reboot' which would fit perfectly between Start and Shutdown

c) IMO a better name for 'Stop' in this context is 'Power off' which btw is used by vmware as well

d) Reset means too many things... should this option instead be called 'CTRL+ALT+CANC' or "Hard Reset VM" or even better 'Power cycle VM'?

e) Reload is another confusing name as it refers to an action for noVNC and not the VM. Should this be renamed to something like ''Reload noVNC"?

f) As ESX does, I would grey-out the commands dependent on the client (qemu) agent if this is not installed/running on the VM. This applies to both noVNC and the main node interface really. I read of few users complaining Shutdown doesn't work where instead the qemu agent simply wasn't installed.


Bottom line in my mind this would work very well:

Start VM
Restart VM
Shutdown VM
Power off VM
Power cycle VM
Suspend VM
Resume VM
Reload noVNC

Longer names indeed but hopefully this should avoid most of the questions on what each button achieves.

my 2 cents

 

[dcsapak]

a) It seems like this menu is a bit confusing as some option are for the VM other for the interface. Even if I know what they mean I need to re-read the options multiple times to remind myself what each button does and I guess I'm not the only one. So as a starter how about adding a context to the button names? e.g. 'Start VM' / 'Shutdown VM' / ..../ 'Reload noVNC' ? I do like short names but if these generate more questions that they answer perhaps some modification is need.

mhmm the 'relooad novnc' makes sense, the rest imho not. all these actions (except reload) are in the vm context, so there should not be a confusion then

b) I personally miss the command 'Reboot' which would fit perfectly between Start and Shutdown

yes that makes sense, can you open a feature request here: https://bugzilla.proxmox.com

c) IMO a better name for 'Stop' in this context is 'Power off' which btw is used by vmware as well

not really, 'stop' in pve context means a hard kill and we use that terminology (mostly) consistent, here too

d) Reset means too many things... should this option instead be called 'CTRL+ALT+CANC' or "Hard Reset VM" or even better 'Power cycle VM'?

same as with stop, 'reset' has meaning in pve context (power cycle)

f) As ESX does, I would grey-out the commands dependent on the client (qemu) agent if this is not installed/running on the VM. This applies to both noVNC and the main node interface really. I read of few users complaining Shutdown doesn't work where instead the qemu agent simply wasn't installed.

while i agree that disabling the buttons depending on the vm state (so start should be disabled when the vm is already started) i don't agree with coupling it with the guest agent.
all these actions should work independently of the guest agent, and if they don't it's either a badly configured vm (e.g. does not listen to acpi commands) or a bug

 

[bellocarico]

Thanks for the answer.

Reboot request raised.

not really, 'stop' in pve context means a hard kill and we use that terminology (mostly) consistent, here too

Ok, I hear what you're saying but I'm challanging here (in a positive way) the choice of words/names. Please allow me to expand: 'Kill' is a very good term for what this button actually does, much better than Stop.

same as with stop, 'reset' has meaning in pve context (power cycle)

Perhaps in the mind of the developers, but again I'm here to bring up a positive challange to this decision. A configuration can be "reset", a snapshot can be "reset", and so many many other thing. Playing bold someone might even think that Reset is synonymous for Reboot. This in my opinion the most confusing button actually, so I would invite to rethink the option name in the interest of interface clarity. How about calling it 'Kill + Start' or if anyone has a better name for it let's discuss it?

while i agree that disabling the buttons depending on the vm state (so start should be disabled when the vm is already started) i don't agree with coupling it with the guest agent.
all these actions should work independently of the guest agent, and if they don't it's either a badly configured vm (e.g. does not listen to acpi commands) or a bug

May be it's me (again I'm the last arrived here) but my shutdown never worked until I manually installed the qemu-client. Perhaps you're right my VMs didn't have the right acpi conf or something but if I did see that the option was greyed-out it would have helped me finding the solution quicker. Apologies if i keep referring to vmware it's just that I know that system pretty well and indeed also there if the vmware-tools are not installed/running the shutdown guest is simply not selectable. In Proxmox may be we could have something like: if no qemu-client is available AND acpi are not responding then yes grey them out to make it clear they won't perform anything. Currently it's all black on white (grey) and there's no straight feedback on whether the command has actually performed something or not.

Thanks for listening (reading)

 

[dcsapak]

Ok, I hear what you're saying but I'm challanging here (in a positive way) the choice of words/names. Please allow me to expand: 'Kill' is a very good term for what this button actually does, much better than Stop.

Perhaps in the mind of the developers, but again I'm here to bring up a positive challange to this decision. A configuration can be "reset", a snapshot can be "reset", and so many many other thing. Playing bold someone might even think that Reset is synonymous for Reboot. This in my opinion the most confusing button actually, so I would invite to rethink the option name in the interest of interface clarity. How about calling it 'Kill + Start' or if anyone has a better name for it let's discuss it?

my point here actually is that those terms are already well established in the PVE UI, so anybody familiar with PVE (and the documentation) will know what that means. It may be a different naming scheme than what users coming from vmware/xen/etc. are used to, but different products use different term for their features/functions.

changing it, just to conform to what other products do is imho not the right way and might even confuse or hinder users that are already familiar with it (e.g. "where is the reset/stop button?")

May be it's me (again I'm the last arrived here) but my shutdown never worked until I manually installed the qemu-client. Perhaps you're right my VMs didn't have the right acpi conf or something but if I did see that the option was greyed-out it would have helped me finding the solution quicker. Apologies if i keep referring to vmware it's just that I know that system pretty well and indeed also there if the vmware-tools are not installed/running the shutdown guest is simply not selectable. In Proxmox may be we could have something like: if no qemu-client is available AND acpi are not responding then yes grey them out to make it clear they won't perform anything. Currently it's all black on white (grey) and there's no straight feedback on whether the command has actually performed something or not.

the hypervisor has no real way of knowing if the guest reacts to such an acpi event (aside from it eventually shutting off) so thats not possible. also disabling the shutdown button because the guest agent is not configured/installed/etc. is also not feasible, since there are system where that guest agent isn't even available (e.g. freebsd/old windows versions). also having the guest agent installed is no guarantee that the shutdown works, it also depends on how the guest is configured
so as i said, if the shutdown is not working for you without the guest agent, it's either a bug (then please report it on our bugtracker, best with reproducable steps) or it's a vm that is not configured to do the right thing (either with the guest-agent or with acpi signals)

i any case, thanks for the post, we definitely consider all feedback from our users, even if we ultimately disagree or have a different idea/vision