HA configuration for node migration/restart only

rbremer

New Member
Feb 27, 2026
14
0
1
Adding a VM to HA with the option "started" works fine when a cluster node is restarted. The VM is migrated off to a different node before restart and will eventually fall back if needed.

However, when the VM is shut down from inside the OS, it also triggers HA and restarts the VM. Only shutting it down via the GUI or API allows the VM to stay offline. Is it possible to configure the HA settings in such a way, that the VM is automatically migrated on cluster node restarts or when the entire cluster comes back online but stays in shutdown when the OS has been shut down from inside the VM?
 
Development clients, which are only used on demand. Servers, which were taken offline by the server admin for maintenance reasons. Basically, if the OS shuts down by itself, HA shouldn't restart it. If anything happens within the Proxmox VE environment, the HA service should basically restore the previous state, if that makes any sense.

I would like to decouple the maintenance window of Proxmox from those of the application servers. When we take a Proxmox node offline for patching, I don't want to manually migrate all VMs first to other nodes, so thats why I think HA is needed (or is there any other option?). However, when a server admin shuts down a server it should stay down.

I hope I could make a bit more sense. We recently started a migration project from ESXi and there are some procedural differences I need to understand and find solutions for.
 
No, it still doesn't make sense. Proxmox is somehow supposed to know if this was an "intended" shutdown rather than a VM crash, and do something different in that case. And you want "on demand" machines to have high availability? What the heck does that even mean?

HA is not intended to be just a convenience for when you want to update your servers. It is to keep important VM's running at all times.

What you are asking for is a "read my mind" button.
 
  • Like
Reactions: UdoB
You actually made your point (and my point) quite clear. Apparently, Proxmox HA is for "keeping a VM alive no matter what". Thats quite different from what I am used to and it explains the difference in approach.

When I studied the Proxmox VE documentation I found only one option to support node restarts and moving (live migrate) all VMs to a different node: using HA. Of course, when a Proxmox node crashes, "live" is not an option.
In an ESXi environment, HA only targets node failures at the hypervisor level, so if a VM is shut down it stays that way.

That was the reason for my question, if this is possible to configure in Proxmox VE too. I am not interested in keeping a VM running at all times, my primary focus is to handle failover situations inside the cluster.

So if I understand this correctly, we either use HA to automate the Proxmox VE cluster migrations / restarts (and therefore the state of a VM can only be managed through Proxmox) or not use HA and manage all migrations manually. Regarding your last comment, I assume the state of each VM is not kept in the cluster FS (corosync), so HA doesn't know why the VM was shutdown and therefore wouldn't know if it needs to be restarted or not.
 
You realize that HA request state of started means, you know, that it should be started. If you dont want that, set a different request state.
From the documentation, yes, and now also from experience. Do you think a different mode would make more sense for my use case?
 
yes. For your test vms (and other non critical) just set the HA request state to ignored. you can still live migrate them just fine.
I am not sure that would work for me. The documentation states:
The resource gets removed from the manager status and so the CRM and the LRM do not touch the resource anymore. All {pve} API calls affecting this resource will be executed, directly bypassing the HA stack. CRM commands will be thrown away while there source is in this state. The resource will not get relocated on node failures.
So basically, on node failures a running VM would not be relocated to other nodes.