Removing a node from a Proxmox cluster sounds like it should be a one-liner, and the command itself is. The trouble is the order. Do it in the wrong sequence — shut the node down and walk away, or delete it while it’s still online — and you leave corosync chasing a member that no longer exists, which can mess with quorum and leave a ghost node lingering in the GUI.
This guide does it the safe way: evacuate everything off the node, power it off for good, delete it with pvecm delnode from a node that’s staying, then verify the cluster is healthy and clean up any leftovers. It also covers the one rule people break most — never rejoining a removed node without a clean reinstall. Steps target Proxmox VE 8.x.
If you’re newer to how clustering works underneath this, the Proxmox cluster guide explains corosync and quorum, which are exactly the parts that punish a sloppy removal.
Get the order right
The whole job is four steps in a specific sequence. Skipping or reordering them is what causes problems.
Safe node removal, in order
- Evacuate all VMs and containers off the node (migrate or back up)
- Reassign or remove any HA resources tied to the node
- Power the node off permanently — it must not come back as-is
- Run pvecm delnode
from a node that's staying - Verify quorum and clean up any stale entries
The single most important detail: the node you’re removing has to be powered off for good before you delete it, and it must not come back online with its old identity. Everything else flows from that.
Step 1: Evacuate the node
Nothing should be running on the node when it leaves. Move every VM and container off it first.
With shared storage, migrate guests live so there’s no downtime. From the GUI, select each VM and use Migrate to a target node, or from the command line:
# live-migrate VM 105 off the departing node 'pve03' to 'pve01'
qm migrate 105 pve01 --online
# migrate a container (containers can't live-migrate; this is offline)
pct migrate 110 pve01If the guests live on the node’s local storage, you can’t simply migrate them away without copying the disk — back them up instead, and plan to restore onto a remaining node. Take a backup of anything you can’t migrate before the node goes away for good.
Step 2: Clear HA resources tied to the node
If the node ran HA-managed VMs, deal with HA before the node disappears, or you’ll leave resources pointing at a node that no longer exists.
Migrate the HA-managed guests to other nodes (which updates where HA expects them), or remove them from HA management if they’re being decommissioned:
# see what HA is managing and where
ha-manager status
# remove a resource from HA management if it's going away
ha-manager remove vm:105Once the departing node has no HA resources and no running guests, it’s safe to take offline.
Step 3: Power the node off permanently
Shut the node down — and mean it. This isn’t a reboot. The node should not power back on while still carrying its cluster identity, because the moment it rejoins or its corosync config conflicts, the cluster can break.
# on the node being removed
shutdown -h nowPull it from rotation: if it’s a physical box you’re repurposing, that’s fine; if it’s staying powered for other reasons, disconnect it from the cluster network. The point is that the cluster will never see this node again under its current config.
Step 4: Delete the node from a surviving node
Now, from a node that’s staying in the cluster, remove the powered-off node by name. First confirm the exact name:
# list current members and their status
pvecm nodesThen delete the departed one:
# remove node 'pve03' — run this from a node that's staying
pvecm delnode pve03pvecm delnode removes the node from the corosync configuration and the cluster’s expected membership. It needs the rest of the cluster to be quorate to succeed — which is one more reason to remove nodes when the cluster is healthy, not in the middle of an outage.
Step 5: Verify quorum and clean up
Confirm the cluster is healthy and the vote math still works in your favor.
# check quorum and the new expected vote count
pvecm status
# confirm the removed node is gone from the member list
pvecm nodesYou want Quorate: Yes and the node count reduced by one. Pay attention to the new expected votes — removing a node changes your failure tolerance.
What removal does to your failure tolerance
| 4 nodes → 3 nodes | Majority drops from 3 to 2. You move to an odd count, which is good — still tolerates one failure. |
|---|---|
| 3 nodes → 2 nodes | Majority is 2 of 2. A single further failure now loses quorum and freezes the cluster. Consider a QDevice. |
| 2 nodes → 1 node | No longer a cluster in any meaningful sense. The lone node is quorate with itself; remove it from cluster mode if it's now standalone. |
If removal drops you to two nodes and you want to keep tolerating a failure, add a QDevice for a third tie-breaking vote — the setup is covered in the cluster guide.
Reusing the hardware later
Removed hardware is perfectly fine to put back into service — just treat it as new. The old install still has the previous cluster’s config baked in, so don’t try to rejoin it directly.
The clean path is a fresh Proxmox install on the box, then a normal join:
# on the freshly reinstalled node, join the cluster again
pvecm add 192.168.1.50A clean reinstall guarantees there’s no stale corosync identity to conflict with. If a full reinstall isn’t practical, at minimum the node’s corosync configuration has to be wiped before it can safely rejoin — but reinstalling is the reliable option and the one to default to.
Wrapping up
Removing a node cleanly comes down to sequence: empty it, sort out HA, power it off for good, then pvecm delnode from a node that’s staying — and never let the removed node rejoin with its old config. Check pvecm status afterward so the change to your quorum math doesn’t surprise you later, especially if you’ve dropped to two nodes.
To understand the corosync and quorum behavior that makes the order matter, read creating a Proxmox cluster. If the node was part of an HA setup, Proxmox High Availability explained covers how recovery and resources work. And before you evacuate anything, make sure your Proxmox backups are current. For more walkthroughs, browse the Proxmox guides.
