To remove a node from a Proxmox cluster, first resolve its workloads, data, replication, Ceph and voting dependencies. Power off the target, run the documented removal command from a remaining member, then verify cluster membership and application acceptance. The command alone does not retire the host.

This article explains the documented flow. It does not claim a tested procedure for an unknown cluster. Use the vendor manual for your installed release before making a production change, especially with Ceph or a QDevice.

Define the node and the remaining cluster

Write down the exact hostname being retired and the nodes that will remain. Use pvecm status and pvecm nodes to establish membership and quorum, and retain that output with the installed release and change record. If it does not match the intended environment, resolve the discrepancy before proceeding.

Before choosing a window, ask whether the surviving hosts have the compute, storage and network capacity required by the remaining workloads. A membership change that succeeds technically can still leave applications without enough capacity.

Resolve prerequisites before removal

Move the node’s virtual machines and containers to appropriate destinations. Confirm application acceptance after each move.
Back up local data that must survive retirement, including material outside ordinary guest backups.
Review every replication job after migration. Migration can reverse a replication relationship, so an earlier check is not enough.
If a QDevice is configured, follow the vendor’s documented QDevice-removal prerequisites before changing membership.
If the node participates in Ceph, complete the Ceph retirement steps and confirm sufficient remaining services, replica capacity and health before removing the cluster member.

Consult the storage replication documentation for replication relationships. For Ceph, use the official Ceph administration guidance. Never treat “VMs moved” as proof that every disk or service has left the host.

Follow the documented membership-removal sequence

Suppose a hypothetical cluster is retiring a node named retired-node. Replace that example with the verified hostname in your approved change plan. The node must be powered off and prevented from rejoining the existing network with its old configuration.

Finish the prerequisite checks, including any Ceph and QDevice work.
Power off the node being removed and ensure it cannot automatically return with the old cluster identity.
Sign in to a remaining member and recheck the intended target and current cluster state.
Use pvecm delnode retired-node for the verified target.
Run pvecm nodes and pvecm status on the remaining cluster. Confirm that the intended member is absent and that the remaining state matches the plan.

# Example only: on a remaining cluster node, after retirement prerequisites:
pvecm delnode retired-node
pvecm nodes
pvecm status

Read the current Remove a Cluster Node procedure for its expected messages. Do not respond to an unexpected failure by casually forcing vote counts or removing cluster configuration files.

Complete cleanup and acceptance

The vendor procedure describes residual node configuration, access keys and HA references that may need attention. Recover anything still required before deleting remnants. Check that alerts, backup jobs, monitoring, documentation and asset records no longer depend on the retired host.

Validate the actual applications as well as membership: can users reach their service, is its storage available, and do backup and recovery arrangements still cover it? Record the checks and unresolved issues rather than declaring completion from a single successful command.

Can I turn the removed node back on?

Do not reconnect an unchanged old node to the cluster network. The documented rejoin path calls for reinstalling Proxmox VE before joining it again. Keeping a machine as a separate standalone system is a different task with shared-storage and identity boundaries of its own.

Build the cluster skills behind the task

Node retirement relies on understanding quorum, storage and workload dependencies. Clustering and Shared Storage is the relevant learning direction; a discovery conversation can help identify the questions your team still needs to resolve.

Explore Proxmox Official Training, check the English registration details or 中文培训报名页面, or bring unresolved requirements to Proxmox Discovery.

Sources and review date

Official references reviewed 19 October 2026. This documentation-based guide does not claim test results from your environment.

Remove a Node from a Proxmox Cluster: Prerequisites and Verification