Proxmox Starter Cluster Lab with Quorum, Templates, Backups, and Placement Decisions

Expected Outcome

A three-node lab cluster maintains quorum, deploys a guest from a proven template, produces a recoverable backup, and survives a controlled single-node outage without pretending that manual placement notes are an automated policy engine.

Assumptions

• Three disposable Proxmox VE nodes on supported versions with unique hostnames/static management addresses

• Reliable low-latency cluster network and synchronized time

• No existing cluster membership or production guests on nodes being joined

• Storage plan documenting which storage is local versus shared

• A maintenance-safe environment where one node can be stopped for quorum testing

Bill of Materials

• Two or more physical servers

• Proxmox VE installed on each server

• Network cables

• Shared storage (NFS, iSCSI, etc.) for backups

• Optional: External backup drive or cloud storage service

Build Steps

1. Record the cluster topology and storage model

   Document node names/IPs, cluster network, expected votes/quorum, storage IDs, and which workloads can move between nodes. Do this before joining nodes because cluster membership is not a reversible casual toggle.

2. Create and join the three-node cluster using supported Proxmox controls

   Create the cluster on the first node, join the other nodes one at a time, and verify corosync membership/quorum after each join. Stop if time, name resolution, or cluster network health is inconsistent.

3. Create one actual guest template

   Build a small supported Linux guest, install guest agent/cloud-init as appropriate, clean machine-specific identity, convert it to a template, then clone it to a new guest and prove the clone boots with a new identity/network configuration.

4. Define placement as documented constraints

   For the starter lab, document placement rules such as storage availability, CPU/RAM headroom, hardware passthrough, and failure-domain intent. Do not present ad hoc qm commands as an automated placement-policy mechanism.

5. Create and restore a backup

   Back up the cloned test guest to a defined backup target, restore it to a different guest ID and isolated network, then validate data/service state. Record the restore duration and cleanup target.

6. Run a controlled quorum/failure test

   Stop one node and verify the remaining two retain quorum and management capability. Confirm expected workload behavior based on where the test guest resides; do not imply high availability unless HA is separately configured and tested.

Validation

• All three nodes appear as members and quorum is healthy

• A guest cloned from the template boots with correct unique identity

• Placement constraints are documented and match actual storage/hardware availability

• A backup restores to a new isolated guest and passes application/data validation

• Stopping one node leaves a quorate two-node majority

• The lab makes no unsupported claim that cluster membership alone provides HA

Troubleshooting

• Do not force-join nodes with unresolved hostname/time/network problems

• If quorum is unhealthy, stop before guest/storage changes and inspect corosync communication

• If a clone inherits identity/network state, correct the template preparation rather than patching each clone

• If restore fails, capture the task log and target storage constraints before retrying

Cleanup or Rollback

• Restore the stopped node and verify full membership

• Remove only disposable cloned/restored guests

• If dismantling the cluster, follow supported Proxmox cluster-removal guidance rather than deleting corosync files casually

Next Improvements

• Explore advanced networking configurations in Proxmox

• Set up high availability for critical VMs

• Integrate monitoring tools for better resource management