Adding escape hatch for stopping VMs

[Ashley Schuett]

I would like to introduce an escape hatch for stopping a VM. This is particularly important for window vms which have a `terminationGracePeriodSeconds` set to 3600 seconds to accommodate updates on shutdown. This new command would allow the user to skip over the defined grace period and instead of waiting for the shutdown would immediately run `KillVirtualMachine` which runs `virsh destroy --graceful` on the vim. 

Some options discussed for this command: 

• virtctl  destroy <vm>

• aligns with `virsh destr0y` which is what the command essentially does

• virtctl kill <vm>

• virtctl stop <vm> --force --graceperiod 0  

• aligns with `virtctl restart --force --graceperiod 0`

• Adding this flag would have the addition “feature” add of allowing the user to easily update the terminationGracePeriodSeconds for the vmi on stop to whatever they desire 

The workflow would be the same as the `virtctl stop` workflow with the addition of updating the VMIs spec `terminationGracePeriodSeconds` to 0. This would then skip the “graceful” shutdown part (https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/vm.go#L1973) and instead kill the VMI.

[Dan Kenigsberg]

On Thu, May 20, 2021 at 11:09 AM Ashley Schuett <asch...@redhat.com> wrote:

I would like to introduce an escape hatch for stopping a VM. This is particularly important for window vms which have a `terminationGracePeriodSeconds` set to 3600 seconds to accommodate updates on shutdown. This new command would allow the user to skip over the defined grace period and instead of waiting for the shutdown would immediately run `KillVirtualMachine` which runs `virsh destroy --graceful` on the vim. 

Some options discussed for this command: 

• virtctl  destroy <vm>

• aligns with `virsh destr0y` which is what the command essentially does

• virtctl kill <vm>

• virtctl stop <vm> --force --graceperiod 0  

• aligns with `virtctl restart --force --graceperiod 0`

• Adding this flag would have the addition “feature” add of allowing the user to easily update the terminationGracePeriodSeconds for the vmi on stop to whatever they desire 

I would lean towards the third option, as it clutters virtctl verbs less. virtctl users already know what "stop" means, they just want to have this one less graceful. I would however validate that we avoid the "--force" flag here. "force" is typically a vague term. It is seldom clear to users what it is that they are forcing and how "strong" is their force. For example, a user may (wrongly) assume that "force" means "try really hard to connect to the virt-launcher pod or kill it in case we have not established a connection with it".

The workflow would be the same as the `virtctl stop` workflow with the addition of updating the VMIs spec `terminationGracePeriodSeconds` to 0. This would then skip the “graceful” shutdown part (https://github.com/kubevirt/kubevirt/blob/master/pkg/virt-handler/vm.go#L1973) and instead kill the VMI.

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAEg990RkSeAafNei28WRDH%3D539JnVSKw7ZqXeEP7TYa5a6WdBQ%40mail.gmail.com.

[Kevin Wiesmueller]

I'd also favor the third option.
But only --grace-period should be enough right? Setting that to 0 would kill the VM anyways?
Not that familiar with the workflow behind the scenes.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAHOEP5510trxxFgm1%3DD9i%3DHEpjL0vqOqkct2_zrW_j%3DRPNKDxA%40mail.gmail.com.

[Ashley]

> But only --grace-period should be enough right? Setting that to 0 would kill the VM anyways?

yes it would. I purpose using both for consistency with the `restart` command. the `--force` flag actually does nothing but you are not allowed to set `graceperiod=0` without the `--force`. Also after looking into the graceperiod flag for restart we only allow setting it to 0, so that could also be the case for the stop command.