Add VM.power_state_reset

[olivierlambert]

It might be required in some situation (in advanced, with a BIG warning message).

[julien-f]

I'm not sure those advanced actions should be exposed in the UI, IMHO, users should use xe for such dangerous things.

Does XCP-ng Center expose it?

[olivierlambert]

Ideally, our goal would be to avoid going on the CLI as possible. This situation can happen if you lose a slave for example. With a proper warning, it might be useful to get it into the UI.

[nagilum99]

I'm not sure those advanced actions should be exposed in the UI, IMHO, users should use xe for such dangerous things.

Does XCP-ng Center expose it?

Probably not, as I can't find it in XenCenter. I remember that I had to use that a few times, years ago. Some XS bug killed the VM but it was shown as still being in some operation.

As that could lead to very ugly things, it should definately be located where "force" things are (advanced?) and double-ask before trigger XAPI.

...just my 5 cents. ;-)

[mr-glatour]

+1 for an exposed function in the advanced tab

[olivierlambert]

So it exists in XAPI:

 void power_state_reset (session ref, VM ref)
Reset the power-state of the VM to halted in the database only. (Used to recover from slave failures in pooling scenarios by resetting the power-states of VMs running on dead slaves to halted.) This is a potentially dangerous operation; use with care. 

But this must be done with a modal window and typing manually "reset" (or similar) to actually send that command. @julien-f could it be added in the next release since it should be trivial?

[tcatlas]

I'm not sure those advanced actions should be exposed in the UI, IMHO, users should use xe for such dangerous things.

Does XCP-ng Center expose it?

I disagree. If you want to compete with other solutions, as many functions as possible, advanced or not, should be exposed in the UI. That line of thinking is a little condescending as well (the users simply can't be trusted!)

I realize that comment was from a while ago, but I was just faced with this today due to a host failure. Having to dig through the documentation to find the commands and then use the CLI to be able to shut down and remove a VM is unnecessarily complicated for an enterprise product.

[olivierlambert]

I got your point of view but that's kind of easy to say as long as you aren't part of the support team on the other side. It's not condescending but the reality we are facing every day. Also, if you had issues to find a solution, you could always open a ticket and the support would have been here for you 🙂

Now, if we want to expose this, we'll probably do it with a sentence to write manually to confirm the action. We can prioritize this for a next release soon, please create a support ticket so we can track the request from there 👍

edit: we are also working upstream to avoid this behavior as possible, because it's often resulting of a failed migration, but there's a way to deal with this more gracefully.

[olivierlambert]

@julien-f The feature is in XAPI, in VM class (https://xapi-project.github.io/xen-api/classes/vm.html) called power_state_reset.

As long as we provide a modal with a text phrase "Yes I'm sure" (or something similar), that sounds OK to me.

[tcatlas]

I got your point of view but that's kind of easy to say as long as you aren't part of the support team on the other side.

I understand, but if the user thinks they need to do it I'm not sure hiding it in the CLI will stop them. Anyway, it seems we're on the same page here so I won't continue driving my point any further.

As long as we provide a modal with a text phrase "Yes I'm sure" (or something similar), that sounds OK to me.

A common trend I've been seeing for destructive actions is forcing the user to type out the name of whatever it is they are doing the action on and the "do the thing" button is red and says "Yes, I'm Sure" or similar.

- Tangentially related to this topic, I'm unsure of the granularity that comes with the Premium-level's ACLs, but it would be great to lock the advanced features behind a higher permission level. i.e. help desk level can reboot VMs or force stop, but only sysadmin can reset power state given the danger. Ideally we could create our own user roles with selectable permissions for every main function...

[tcatlas]

I've also seen a time delay. So the modal shows an explanation of why it's dangerous, the button is grayed out for 5 seconds, and you have to enter the name of the VM. Really drives the point home... :)

[olivierlambert]

Since we'll limit the changes for XO 5, we'll probably go for a simple text. But a time button for XO 6 might be a good idea. Pinging @clemencebx about the UX idea.