Feature suggestion: Kill

[bellocarico]

As a well known issue occasionally VMs do not shutdown or even Stop. The solution I'm reading on this forum is to log on the console and kill the kvm process linked to the VM. Really not practical especially when experimenting.

So... Can we have a Kill command in the VM power menu? e.g. Reboot/Pause/Hibernate/Stop/Kill/Reset

id=107
kill -9 $(ps x | grep "[k]vm -id $id" | awk '{print $1}')

Thanks

 

[alexskysilk]

If it happens enough that you need a premade feature, you have problems bigger than a missing feature...

 

[bbgeek17]

to add to @alexskysilk , the "stop" already does a kill after a timeout. While the GUI does not allow you to specify it, the CLI/API does:

 --timeout <integer> (0 - N)
           Wait maximal timeout seconds.

And if you were killing a process, I would use one tool "pkill" vs 4 (kill, grep, ps, awk)

 pkill --signal 9 -f 'kvm -id 301'

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[bellocarico]

It's not that I disagree but I don't feel I have "bigger issues" to be fair. It is common practice for what I do to install test ISO, windows, linux, else. One wrong parameter like Machine type, BIOS type, OS Type, ACPI, etc etc etc and you'll find your VM unstoppable. Of course... I suppose I didn't mention this is a test machine and it's not about Killing the production VMs at all.

Now on the Stop that runs a kill after a timeout.... may be but if that's the case it doesn't work. After what it looks like a stop timeout this is all I get in the logs:

trying to acquire lock...
TASK ERROR: can't lock file '/var/lock/qemu-server/lock-107.conf' - got timeout

Still the VM remains in power on state. So I'm only left with an unpractical command line action to move forward.

Are there any other users here that see a value of a Kill via GUI?

 

[VictorSTS]

Stop does, in fact, kill the qemu process. There are few situations were such kill might not work, i.e. when the storage where the VM is breaks/becomes innaccesible.

Your issue is that you try to shutdown the VM first. As the VM keeps running, you issue a stop. That stop task must wait for the previous shutdown task to finish (trying to acquire lock...). The default timeout for the shutdown task is 10 minutes. For the stop task to succeed you need to either wait for the timeout or stop the shutdown task.

The shutdown timeout can be configured in VM options, Start/Shutdown order, Shutdown timeout (seconds).

For a shutdown task to succeed you either need that:
- The OS responds to ACPI requests.
- Have the QEMU guest agent configured in the VM, installed and running in the guest OS.

When installing an OS or running some live CD neither ACPI nor QEMU GA is available and shutdown request will fail. Use a stop directly instead of shutdown.

Btw, you don't even need kill is you want to use CLI to forcibly stop a VM:

qm stop <vmid> --skiplock

Would a "kill -9 --come-on-do-what-I-say-mate" be useful in the GUI? Maybe. But I'm sure that understanding what's happening under the hood will help you manage Proxmox efficiently.

 

[bellocarico]

For a shutdown task to succeed you either need that:
- The OS responds to ACPI requests.
- Have the QEMU guest agent configured in the VM, installed and running in the guest OS.

Thanks I really appreciate the answer. So shouldn't the Shutdown be greyed out until ACPI or QEMU become relevant?

 

[fabian]

Thanks I really appreciate the answer. So shouldn't the Shutdown be greyed out until ACPI or QEMU become relevant?

the way to find out whether the guest reacts to ACPI events is to do it and see if it has an effect the guest is free to ignore it..

 

[bellocarico]

the way to find out whether the guest reacts to ACPI events is to do it and see if it has an effect the guest is free to ignore it..

And how do I know if I should attempt a Shutdown or Stop not to have the VM stuck?

 

[fabian]

either you set up your VMs properly in the first place, or you have to do a shutdown and wait and follow up with a stop (or run qm shutdown XXX --timeout YYY --forceStop 1). if you don't care about properly shutting down, then you can of course always just do a stop (a shutdown is basically pressing the power button to trigger a shutdown, a stop is pulling the power cable, which can lead to inconsistent state on disk, etc.pp.)

 

[VictorSTS]

As a rule of thumb, consider that a VM without QEMU Guest Agent configured and running probably won't reply to shutdown requests.

Detailed examples:
- Any OS setup phase will not shutdown, you'll need to stop.
- Windows desktop VMs should reply to shutdown requests either by ACPI or QEMU GA.
- Windows server VMs will not shutdown if any user is logged in the machine unless you use QEMU GA
- Most Linux flavors will shutdown properly by default.
- FreeBSD (like pfsense) probably will not shutdown.

On all OS you can change their default behavior regarding ACPI, but I really recomend to use QEMU GA if possible. Also, there's always the option to shutdown the guest OS from the console/ssh/rdp/whatever.

 

[Neobin]

For reference:
https://bugzilla.proxmox.com/show_bug.cgi?id=4474