Delete Proxmox Cluster — the full cleanup the old guides skip

Deleting a Proxmox cluster on a single-node homelab is easy if you know where the config files live, but the top search result stops at editing corosync.conf and leaves you with a node that still thinks it’s clustered. Here’s the full cleanup for Proxmox VE 8.

Stop the cluster stack

First, stop the cluster service and corosync. If you don’t, the node will just rewrite the configs you’re about to delete.

systemctl stop pve-cluster
systemctl stop corosync

Nuke the cluster config files

These are the files that make your node think it’s part of a cluster. Delete them all.

rm /etc/pve/corosync.conf
rm -rf /etc/corosync/
rm /etc/pve/cluster.conf
rm /var/lib/pve-cluster/config.db

The config.db is the big one — that’s the pve-cluster database. If you leave it, the node will still have cluster membership info and act weird.

Restart pve-cluster fresh

Now start pve-cluster back up. It’ll regenerate a clean, standalone config.

systemctl start pve-cluster

Give it a few seconds, then check the web UI. You should see a single node with no cluster info. If you still see cluster references, clear your browser cache or check /etc/pve/.members — it sometimes sticks around, but it’s harmless.

Why the old guides are half-baked

The 2020 Stack Overflow answer tells you to edit /etc/pve/corosync.conf and set quorum_votes: 1. That’s fine if you want to keep a single-node cluster running, but it’s not a deletion. The node still has the cluster database, still expects quorum, and still shows cluster status in the UI. That’s a pain in the ass if you just want a clean standalone host.

Deleting the config files is the nuclear option, but it’s the right one for a homelab. No leftover cruft, no weird quorum warnings. Just a plain Proxmox node.

One more thing: check your storage

If you had any cluster-wide storage configured (like a shared LVM or Ceph), those configs live in /etc/pve/storage.cfg. You’ll want to clean that up manually — the cluster deletion doesn’t touch it. Just edit the file and remove any stanzas that reference cluster-only storage, or the UI will keep showing them as unavailable.

Honestly, for a single-node homelab, I’d just blow it all away and start fresh. Less to undo later. If you’re dealing with a two-node setup that won’t boot right after a neighbor reboot, check out VM processes stall when rebooting adjacent node — it’s a different mess but the same kind of annoying.