Why a Proxmox VE high availability cluster needs more than a second node
If you run virtual machines on single hosts and want guests to restart on another node after a failure, you need a Proxmox VE high availability cluster, and that means at least three nodes for reliable quorum, shared storage that every node can reach, redundant hardware, and watchdog-based fencing so a failed node is reset before its guests start elsewhere. Adding a second node to a cluster does not give you HA. Two nodes cannot form a majority when one fails, so the surviving node cannot safely decide that its peer is gone and take over its guests. The reason is that a cluster and high availability solve different problems. A Proxmox VE cluster replicates configuration across nodes, and its multi-master design lets any node perform management tasks. The Proxmox Cluster File System keeps that configuration in step in real time. None of that moves a running virtual machine. HA is a separate layer that monitors guests and restarts them on healthy nodes, and it only works when the cluster can trust its own membership information. Before you buy hardware, confirm with your own design that a third voting node, or an equivalent quorum device your team can operate, is part of the plan.
Storage is usually the hardest dependency to get right. A guest can only restart on another node if that node can read its disk. That requires shared storage such as Ceph, NFS, iSCSI or another network backend that every HA-eligible node can mount, or a replication design that keeps a recent copy of the disk on the target node. Local storage on LVM, directories or ZFS is fully supported in Proxmox VE, but local-only guests are not failover candidates in the same way. Ask your team to map every guest to its storage path, check that the target nodes have the same network and storage definitions, and decide how much data loss you accept if a guest restarts from an older replica.
Fencing is the step teams most often underestimate. HA must be certain that a failed node has stopped writing to storage before its guests are started somewhere else, or two copies of one disk can corrupt data. The Proxmox VE HA stack relies on watchdog-based fencing so that a node that loses quorum resets itself. Confirm that each node has a working hardware or software watchdog, that the fencing behavior is tested, and that power or out-of-band management is available for any node that cannot be reset by the cluster itself. Redundant network paths for cluster traffic and redundant power supplies matter here because a single network fault can look like a node failure.
Testing is what proves the design works. Plan failover tests that pull power from a node, cut its cluster network, and fail its storage path, and record how long each guest takes to return and whether any data was lost. Define HA groups, the nodes each guest may use, and the order in which guests should restart before the first test. Because these tests can disrupt production, most teams run them in a pilot cluster or a maintenance window first. Ask your implementation partner or internal team to document the test results, the expected recovery behavior and the steps for maintaining quorum during planned node outages.
Which Proxmox VE components make HA work
High availability in Proxmox VE is not one feature but a set of components that must agree. The cluster file system, HA manager, fencing, quorum and guest storage each fail in different ways, so each needs a specific configuration decision before you test a failover.
Cluster file system and multi-master design
Every Proxmox VE node can perform management tasks, and the Proxmox Cluster File System replicates configuration to all nodes in real time. This is what lets a surviving node take over guest definitions after a failure. Check that the cluster is created with the intended node names and network, that corosync traffic has its own reliable network path, and that you know which node you would use for management if the others are unreachable.
HA manager and resource state
The HA manager decides which guests are protected and where they should run. You declare each protected VM or container as an HA resource with a desired state, such as started, and the manager restarts it on another node when its current node is lost. Confirm which guests are registered, their desired state, and any HA groups that restrict or prefer certain nodes, and test that resources move as expected.
Watchdog-based fencing
Before the HA manager recovers guests from a failed node, that node must be reset so it cannot still write to shared storage. Proxmox VE uses watchdog-based fencing for this. Confirm that a hardware or software watchdog is active on every node, that the node reset path works in your hardware and firmware, and that fencing is tested under controlled conditions before you rely on it.
Quorum and node count
The cluster only acts when a majority of nodes agree, so quorum decides whether HA recovery can run at all. Proxmox VE documentation calls for at least three cluster nodes for reliable quorum. Plan for the loss of one node without losing majority, verify the vote count on each node, and avoid designs where a network split can leave two halves each believing they hold authority.
Shared storage for guest disks
A guest can only restart on another node if its disks are reachable from that node. Proxmox VE supports iSCSI, NFS, CIFS, Ceph RBD and CephFS as network storage, and ZFS replication as a local option with periodic copies that accept a recovery point gap. Identify which storage type each protected guest uses, confirm that every node can mount it at the same path or pool name, and record the expected data loss window for replicated disks.
Redundant hardware and network paths
HA protects against a node failure, but a single switch, storage path or power feed can still stop several nodes together. Proxmox VE HA guidance expects redundant hardware. Review which links carry cluster traffic, storage traffic and guest traffic, confirm whether each has a second path, and decide which failures you will test, such as a pulled storage cable or a failed top-of-rack switch.
Which storage and quorum design fits your HA requirements
This table compares shared network storage on iSCSI or NFS, hyper-converged Ceph, and local storage with replication for Proxmox VE HA guests, along with node count and witness choices. Read each row as a question: when the option fits, what it asks your team to run, and where its recovery limits show up.
| Design option | When it fits | Operational cost | Limits to plan for |
|---|---|---|---|
| Shared network storage (iSCSI or NFS) | Guests need to restart on any surviving node with no data copy, and you already run a storage array with redundant controllers and paths | A separate storage network, multipath setup, and array administration on top of the Proxmox cluster; confirm the array vendor's Proxmox support statement | The array becomes a shared dependency, so its failure affects every HA guest at once |
| Ceph RBD on Proxmox nodes (hyper-converged) | You want shared VM storage without a external array and can dedicate disks and a separate network on each node | Ongoing Ceph administration, replication tuning, capacity planning and network separation; more skills needed on the platform team | Needs enough nodes and disks to meet the replica count; a poorly sized cluster degrades under node loss |
| Local storage with storage replication | Recovery point of the last replication interval is acceptable and you want no shared storage hardware | Scheduled replication jobs to other nodes, extra disk capacity on each replica target, and monitoring of job status | Guests can lose data written since the last sync, and HA recovery depends on a recent replica existing on the target node |
| Three or more voting nodes | You need reliable quorum so the cluster can decide which side keeps running after a network split | Three hosts with matching hardware and redundant networking, so the minimum node count drives hardware spend | Two-node clusters need an external witness or a quorum device; confirm the approach against current Proxmox documentation before choosing it |
| Watchdog-based fencing | Any HA guest must be restarted elsewhere only after the failed node is confirmed reset | Validate hardware or software watchdog behavior on every node during build and after firmware changes | Without working fencing, recovery can start a guest on a second node while the first still writes to shared storage |
| Quorum device or witness for even node counts | You must run an even number of nodes or a site-level split is possible | An extra small host or service to deploy, patch and monitor outside the main cluster | The witness must be placed where its failure does not isolate the cluster; confirm placement in the design review |
| Recovery point objective for HA guests | Guests can tolerate losing the last replication window or rely on shared storage with its own snapshots | Define replication intervals and backup schedules together, since HA does not replace backup | HA restarts a guest but does not restore deleted or corrupted data; pair HA with Proxmox Backup Server or another tested backup |
How to build the HA cluster step by step
This sequence takes a set of Proxmox VE hosts from hardware checks to a cluster where guests restart on healthy nodes after a failure. Each step closes with a check you can run before moving on, so problems surface while they are still cheap to fix.
Validate hardware and network before installing
Confirm that every node has matching redundant hardware, that the cluster network is separated from guest and storage traffic where your design allows, and that each node resolves the others by name. Proxmox VE HA needs at least three cluster nodes for reliable quorum, shared storage that every node can reach, and redundant hardware, so check these against your plan. Done means you can ping every node on every cluster network path and the storage target from each host. Confirm the exact network and storage requirements for your Proxmox VE version in the official HA documentation.
Create the cluster on three or more nodes
Install Proxmox VE on each node with the same version, then create the cluster on the first node and join the remaining nodes to it from their web interfaces or the command line. Proxmox VE uses a multi-master design, so every node can perform management tasks, and the Proxmox Cluster File System replicates configuration to all nodes. Done means every node appears in the cluster view with the same configuration state. Keep all nodes on the same repository channel, since the enterprise repository requires a valid subscription key.
Confirm quorum before adding any HA resources
Check cluster status on every node and confirm that the cluster reports quorate with the expected number of votes. Quorum is what allows the cluster to decide that a node has failed and to recover its guests safely, so a cluster that is not quorate must be fixed before anything else. Done means the status output shows quorum on all nodes, and a deliberate test with one node powered off leaves the remaining nodes quorate. Record the expected vote count so later checks have a reference.
Attach shared storage on every node
Add the shared storage that holds VM disks, such as iSCSI, NFS, CIFS, Ceph RBD or CephFS, and make it available to every node in the cluster. HA guests can only restart on another node if that node can see the same disks, so the storage definition must be identical across nodes. Done means each node lists the storage as active and can read the disk image of a test guest. Confirm with your storage vendor how multipath and access controls should be configured for your array.
Configure watchdog fencing on each node
Enable a hardware or software watchdog on every node so that a node that loses quorum or stops responding is reset before its guests are started elsewhere. Proxmox VE relies on watchdog-based fencing to prevent a guest from running on two nodes at once, which would risk data corruption. Done means each node reports an active watchdog device and the HA services are running. Confirm which watchdog device your server hardware provides and whether it needs a driver or BIOS setting.
Define HA groups and HA resources
Create HA groups that list the nodes eligible to run a set of guests, with priorities where some nodes should be preferred, and then add each critical VM or container as an HA resource assigned to a group. Keep groups small and deliberate so capacity exists on the target nodes after a failure. Done means the HA resource list shows each guest with a started or stopped state and an assigned group, and the cluster reports the resources as managed.
Set restart and relocation policy
Decide how the cluster should react to failures by setting the maximum restart and relocation attempts for each resource, and whether a guest should be relocated to another node after a failed start. Match these settings to your recovery goals and to the spare capacity you have, since a guest cannot be recovered onto a node that is too full to run it. Done means each resource shows the policy you chose, and you have written down which nodes will absorb each group's guests.
Run failover tests and confirm guests restart elsewhere
Simulate a node failure by powering off or isolating one node that hosts HA resources, then watch the cluster fence it and start the affected guests on another node in the same group. Repeat the test for each group and for a planned maintenance drain, and record how long each recovery took. Done means every test guest starts on a healthy node, its data is intact, and the cluster returns to a clean state after the failed node rejoins. Run these tests again after any hardware, storage or version change.
Why watchdog fencing decides whether failover is safe
Watchdog fencing is the mechanism that makes Proxmox VE high availability safe to run. The rule is simple: a failed node must be reset before its guests are recovered on another host, so the same virtual disk is never written by two hosts at once. Proxmox VE documents watchdog-based fencing as a core requirement of HA, alongside at least three cluster nodes for reliable quorum, shared storage for guests and redundant hardware. Without fencing, the cluster can restart a guest elsewhere while the original copy is still running, which corrupts data faster than most teams can detect it.
Each node in an HA-enabled cluster arms a watchdog as part of the HA stack. The local resource manager and cluster services must keep feeding that watchdog while the node is healthy and in quorum. If the node stops feeding it, for example because of a kernel hang, a lost cluster link or a crashed management daemon, the watchdog expires and resets the hardware. That reset is the fence. Proxmox VE's HA design relies on the reset completing before the surviving nodes take over the guests, so the timing of the watchdog and the recovery logic is part of the safety argument, not an optimization.
Quorum determines who is allowed to make that decision. A node that loses quorum stops being able to act as a member of the cluster, and the HA stack on that node should not keep running guests as if nothing happened. The surviving partition, which holds quorum, is the only side that may recover services. Design the cluster so that losing a single node or a single network path never removes quorum from the majority. This is why three or more nodes are the baseline: with two nodes, a single failure can leave neither side with a clear majority. Confirm how your chosen topology behaves when the cluster network splits, and test it rather than assuming it.
The dangerous case is not the node that is obviously dead. It is the node that appears down to the rest of the cluster but is still running its guests. A network partition, a saturated link or a stalled corosync process can make a healthy host look failed. If the other nodes recover its guests without a confirmed reset, two hosts may write to the same storage. Watchdog fencing exists to close exactly this gap by forcing a reset of the isolated node before recovery begins. Plan for this scenario explicitly: identify which network paths carry cluster traffic, keep them redundant, and rehearse a partition during a maintenance window.
Before go-live, confirm watchdog hardware and driver support for each server model with the hardware vendor, including whether the platform's watchdog device is exposed to Linux and how it behaves under your firmware settings. Ask the vendor and your Proxmox VE administrator to document the watchdog device in use on each node, then verify it during failover testing by isolating a node and checking that it resets before its guests start elsewhere. A cluster that has never been fenced in a test has not yet proven that failover is safe.
What drives the effort and cost of a Proxmox VE HA build
This table lists the main drivers that change the scope of a Proxmox VE high availability build, with a practical way to keep each one under control. Read each row as a question to answer in your scoping conversation before asking for a quote. The main takeaway is that limiting HA to critical guests and standardizing hardware usually reduce effort more than any single tooling choice.
| Driver | Why it changes effort or cost | How to keep it down |
|---|---|---|
| Node count and hardware redundancy | HA needs at least three cluster nodes for reliable quorum, plus redundant hardware, so every extra node adds hardware, rack, power and configuration work. | Standardize on identical hosts and the minimum node count that meets your availability target. Confirm the count and layout with your own quorum and failure-domain plan. |
| Storage type and network design | Guests must reach shared or replicated storage from every node. Choices among iSCSI, NFS, Ceph RBD or ZFS replication change network cabling, multipathing and testing time. | Pick one storage model for the HA tier and document it. Separate storage and cluster traffic only where your network already supports it, and confirm supported options with Proxmox documentation. |
| Number and criticality of guests | Each HA-managed guest needs placement rules, failover behavior and test cases. Large numbers of guests with mixed criticality multiply verification work. | Limit HA to the guests whose downtime you cannot accept. Keep other workloads on standard nodes or with scheduled backups and restore, and group guests by criticality. |
| Identity and monitoring integrations | Connecting the management plane to LDAP, Active Directory or OpenID Connect realms, plus alerting for fencing and quorum events, adds configuration and access-review effort. | Decide early which realm and two-factor methods administrators use. Reuse existing monitoring and alert channels and define a short list of HA events to alert on. |
| Number of environments | Lab, staging and production each need their own cluster or sizing, and changes must be promoted through them. Each environment repeats build and test steps. | Keep the lab and staging clusters smaller but built from the same automation and configuration. Confirm with your team which environments need full HA behavior. |
| Amount of failover testing | Watchdog fencing, node loss, network partition and storage loss each need a documented test with pass criteria and evidence. Test depth is often the largest variable in the schedule. | Agree a fixed test matrix in the statement of work, with the failure cases that matter most for your critical guests. Retest only after changes to hardware, storage or network. |
| Subscription tier and repository choice | Production clusters are generally run on the enterprise repository with a valid subscription key, while the no-subscription repository is described for testing and non-production use. Support entitlements differ by tier. | Ask for the subscription tier per CPU socket in the quote, and confirm which repository each environment uses. Subscription fees recur each year. |
How HA differs for single-site, two-site and lab deployments
This is the reference model for Proxmox VE HA. Proxmox VE documents at least three cluster nodes as the basis for reliable quorum, so that a single node failure leaves a majority to decide which guests restart. Guests keep their disks on network storage that every node can reach, such as iSCSI, NFS or another shared backend, so a surviving node can start a failed node's VMs without copying data. Watchdog-based fencing resets a node that has lost quorum or cannot be fenced cleanly before its guests are recovered elsewhere.
What changes in this model:
- Quorum: three or more voting nodes, with a majority required before HA actions run.
- Storage: one shared storage target reachable from all nodes, so storage availability itself becomes a single point of failure to design around.
- Fencing: hardware watchdog or the software watchdog in place on every node, with fencing confirmed before recovery.
What not to assume:
- That two nodes plus a quorum device are equivalent to three full voting nodes for this purpose.
- That HA protects guests from a storage array outage. Shared storage must be redundant on its own.
- That fencing works because the cluster was created. Confirm the watchdog triggers a reset during testing.
Confirm with your hardware vendor that watchdog support and power management are validated on your specific server models before go-live.
In a hyper-converged design, the same nodes run VMs and provide storage through Ceph RBD. Storage is no longer a separate array, so losing a node removes both compute and some storage capacity at once. Ceph replication keeps data available across nodes, and the HA stack restarts guests on surviving nodes using the replicated copies. The storage layout, replication settings and network separation are substantial topics of their own, and they are covered in the Ceph storage design topic rather than repeated here.
What changes in this model:
- Quorum: the same three-node minimum applies, and Ceph monitors add their own quorum requirement that must be planned alongside the Proxmox cluster.
- Storage: data is distributed across node disks, so a failure reduces both compute and storage at once, and recovery depends on Ceph rebuilding redundancy.
- Fencing: watchdog-based fencing still applies, and a node must be reset before its guests are restarted elsewhere.
What not to assume:
- That a three-node Ceph pool tolerates the same failures as a shared array. Replication settings decide what survives.
- That HA restarts guests instantly after a node loss. Recovery includes fencing time and guest boot time.
- That the cluster network can be shared with guest traffic without testing the impact on Ceph under load.
Ask for the Ceph design review as a separate deliverable so the storage assumptions are documented before HA behavior is tested.
A lab exists to learn the platform, rehearse procedures and test automation, not to carry business workloads. The no-subscription repository is described by Proxmox as suited to testing and non-production use, so a lab can run without an enterprise subscription. The same HA features can be configured, which makes a lab useful for practicing failover, but the reliability of the lab does not represent production. Cheap or mixed hardware, consumer networking and single storage paths are common, and each one weakens the HA guarantees the lab appears to show.
What changes in this model:
- Quorum: a three-node lab keeps the same logic, but a shared power feed or switch can remove a majority at once.
- Storage: lab storage is often a single NFS server or local disks, so failover tests may not reflect real storage behavior.
- Fencing: watchdog behavior varies on consumer hardware, and some platforms lack a usable hardware watchdog.
What not to assume:
- That a successful lab failover proves production recovery time or data safety.
- That the no-subscription repository is appropriate for production patching. Use the enterprise repository, which requires a valid subscription key, for production.
- That the lab can be promoted to production without rebuilding storage, networking and fencing.
Before relying on lab results, confirm the hardware, storage and watchdog differ from the production design and document each gap.
How to secure the HA cluster and its management plane
A high availability cluster is only as trustworthy as the interface that controls it. The cards below cover the controls that protect the management plane, the cluster and storage networks, and the settings that decide how failed nodes are fenced and guests are recovered. Depth on identity integration and host hardening sits in the linked SSO and hardening topics.
Restrict access to the management interface
The web interface and API on port 8006 control every node in the cluster, so they should not be reachable from user workstations or the internet without restriction. Decide which networks may reach the management addresses, and enforce that with the built-in datacenter firewall or your network controls. Check the result from an address outside the allowed range before go-live.
Choose realms and second factors for administrators
Proxmox VE authenticates users through Linux PAM, the built-in authentication server, LDAP, Active Directory or OpenID Connect realms. Avoid running administrators on the PAM root account for daily work. Require a second factor such as TOTP or WebAuthn for administrative accounts, and confirm that recovery keys are issued and stored securely. Identity integration details are covered in the SSO topic.
Apply least-privilege roles and API tokens
Proxmox VE permissions are assigned by role on paths such as datacenter, pools, nodes and storage. Grant operators only the roles needed for their tasks, and separate HA administration from backup and storage administration. Use scoped API tokens with expiry for automation rather than sharing administrator passwords. Review the permission tree after each staffing change.
Isolate cluster and storage traffic
Corosync membership traffic is latency sensitive, and migration and storage replication can saturate a shared link. Place cluster communication, migration, and storage traffic on separate VLANs or interfaces where hardware allows, and keep them off the user-facing network. Restrict storage protocols such as NFS, iSCSI or Ceph to the storage subnet only. Verify the separation with your network team before loading guests.
Handle storage credentials securely
Network storage definitions in Proxmox VE can hold credentials for CIFS, iSCSI targets or Ceph keys, and backup server connections carry their own secrets. Create dedicated service accounts with the minimum access each storage needs, and record who holds those secrets and how they are rotated. Confirm that the storage configuration is limited to administrators and that rotation does not stop HA recovery.
Review fencing and watchdog settings
HA fencing relies on watchdog-based resets so that a failed node is fenced before its guests are restarted elsewhere. A misconfigured watchdog or an unintended fencing path can cause needless resets or leave guests stranded. Document which watchdog device each node uses, test that fencing occurs as designed, and restrict who can change HA resource and group settings. Confirm the exact behavior for your hardware with the Proxmox VE HA documentation and your server vendor.
How to test that failover works and fails safely
A high availability cluster is only proven when you have failed a node on purpose and watched what happens. Treat the test as a controlled experiment with written expected results, run it before production guests depend on the cluster, and repeat the key cases after any change to hardware, network, storage or HA configuration. The goal is not to show that failover can happen, but to show that it happens in the right order, to the right nodes, and without a split-brain where a guest runs in two places at once. Start by confirming quorum. Check that every node is listed as online in the cluster status, that the cluster has a quorate majority, and that the Proxmox Cluster File System is mounted and writable on each node. Then confirm that the HA manager shows the managed resources and their current state, and that each HA service is in a known state before you disturb anything. Record the output. If quorum is not stable in a clean state, no failover result means anything yet, so stop and fix the network or corosync configuration first. Next, simulate a node power loss rather than a clean shutdown. A clean shutdown lets the node stop its guests and release locks, which hides the behavior you need to test. Cut power or use your out-of-band management card to power off the node hard. Confirm that the watchdog reset happens before any guest is started on another node. Look at the logs on the surviving nodes for the fencing sequence and the timestamp of the reset relative to the recovery. If a guest starts elsewhere before the failed node is confirmed fenced, that is a critical finding and the fencing setup must be corrected before go-live. With the fencing sequence confirmed, check that guests restart on healthy nodes within the HA policy you configured. Verify which guests moved, where they landed, whether they respected HA group preferences and restricted settings, and how long they took to return to running. Write down the duration you measured in your own environment, since no general figure applies to your hardware and storage. Also test a loss of a storage path and a loss of a network link separately. Pull one path of a multipath storage connection and confirm guests keep running, then disconnect a cluster or storage network link and confirm the expected behavior for your design, including whether any node is fenced. Finally, test a single node recovering and rejoining. Power the failed node back on, confirm it rejoins the cluster, that quorum is restored, and that guests are not automatically moved back in a way that surprises operators. Record every result as passed, failed or needs a runbook change, with the evidence attached. Any step that behaved differently from the written expectation becomes a runbook change, and the test should be repeated after that change is made.
What to monitor, back up, upgrade and document after go-live
This table separates the recurring operating tasks for a Proxmox VE HA cluster from the one-time setup work, with the signal to watch, the evidence to keep and the common failure point for each. Read it as a checklist for the operations team: the left column names the area, and each row says what to check, how often the check should happen and what usually goes wrong. The main takeaway is that a cluster that passed failover testing at go-live still needs routine quorum, storage and backup checks, and each upgrade or node swap needs a written procedure.
| Area | What to check or do | Where it usually fails |
|---|---|---|
| Quorum and cluster health | Confirm all nodes are in the quorate state, that the cluster file system is mounted and that corosync links are up on every network path | A node drops out after a network change and nobody notices until a second node is taken down for maintenance |
| HA resource state | Review the HA resource list for guests in error, stopped or fence-pending states and confirm each guest is assigned to the intended HA group | Guests are added to HA manually, then removed from a group during troubleshooting and never restored |
| Storage health | Watch shared or replicated storage pool capacity, backend health (Ceph, NFS, iSCSI or ZFS pool status) and alerts from the storage layer | Storage fills or degrades quietly, so guests can restart on a node that cannot reach their disks |
| Replication jobs | Check that storage replication jobs for guests run on schedule, have recent successful sync times and show no repeated errors | Replication stops after a node or network interruption and is not re-verified before a planned failover |
| Guest backups | Confirm scheduled backups of VMs and containers complete, retention removes old copies as designed and restores are tested on a regular cycle | Backups succeed for months but were never restored, or the backup target fills up |
| Cluster configuration backup | Keep a dated export of cluster configuration, storage definitions, firewall rules and HA settings stored outside the cluster | Only guest data is backed up, so rebuilding the cluster configuration after a total loss takes far longer than planned |
| Rolling node upgrades and repository choice | Put one node in maintenance, migrate or evacuate guests, upgrade, reboot and return it before moving on; confirm which repository (enterprise or no-subscription) each node uses | Nodes are upgraded at the same time, or nodes run different repositories and package versions, which causes version mismatch in the cluster |
| Node replacement and failover runbook | Document the steps to remove a failed node, add a replacement, rejoin it to the cluster and rebalance HA resources, and rehearse the failover test after each change | The runbook exists but was written for the original hardware and nobody has rehearsed it since go-live |
What the reader should receive at handover
A handover for a Proxmox VE high availability cluster should give the operating team everything needed to understand, test and recover the cluster without the people who built it. The core items are an as-built node and network diagram, a storage mapping, the watchdog and fencing configuration, an HA group and resource inventory, test results with evidence, runbooks for node failure and rejoin, an access and role model, and a support and upgrade plan. Each one answers a question the operators will ask during an incident, usually at an hour when the original builders are unavailable.
The as-built diagram should show every node, its cluster network, its management network, the storage network and any corosync links, with the physical port and VLAN for each. During a split or partial failure, operators need to know which links carry cluster traffic and which carry guest traffic. The storage mapping should list each datastore, whether it is LVM, ZFS, NFS, iSCSI, Ceph RBD or CephFS, and which nodes can reach it. HA only restarts a guest on another node if that node can see the guest's disks, so this mapping is the first thing to check when a failover does not happen.
The watchdog and fencing record matters most in a failure. Proxmox VE's HA design relies on watchdog-based fencing so that a failed node is reset before its guests start elsewhere. The handover should state which watchdog device is active on each node, how it was verified, and what the cluster does when quorum is lost. Pair this with the HA group and resource inventory, which lists each HA-managed guest, its preferred nodes, its restart policy and any group constraints. Operators can then confirm that a guest which was never placed under HA is not expected to move, and that a guest which should move has a valid target.
Test results and runbooks turn the design into something the team can repeat. Ask for the evidence of each failover test: the node taken down, the time to fence, the time to restart each guest and any guest that did not recover. The runbooks for node failure and node rejoin should describe the exact steps, the commands, the expected output and the point at which to stop and call for help. Confirm with the builder whether the tests covered a planned maintenance drain as well as an unplanned power loss, since these exercise different code paths.
The access and role model and the support and upgrade plan close the gap between delivery and daily operations. Document which realms, administrators and API tokens can change HA settings, and who holds the second factor for root-level access. Then confirm the Proxmox VE version in use, its Debian base, the subscription tier and repository in use, and the upgrade path your team will follow for rolling node upgrades. Check the support entitlements in writing with the vendor, because the subscription tier determines how many tickets and what response times apply, and an HA cluster without a support path is harder to recover at speed.
Questions teams ask before building Proxmox VE HA
How much does a Proxmox VE HA cluster project cost?
The total has two parts: the services you pay a partner for under a written, fixed-scope agreement, and the infrastructure and subscriptions your organization buys directly. Cost drivers include the number of nodes (at least three), host hardware, the shared or replicated storage design, network separation, watchdog and fencing setup, the number of guests and their recovery priorities, and how much failover testing is in scope. Subscriptions are priced per CPU socket per year: Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, according to the Proxmox VE pricing page. Ask for a quote that separates one-time work from recurring items such as subscriptions, support and retainers.
How long does it take to build a Proxmox VE HA cluster?
The duration depends on how much of the environment is new and how quickly decisions and hardware arrive. No general timeline is published here, so confirm one against your own environment. Factors that move the schedule include hardware lead times, storage and network readiness, the number of workloads to qualify for HA, the number of change windows available, and how many failover scenarios the test plan covers. Ask for a written plan that lists phases, dependencies and the decisions each phase needs from your team, so you can see which items sit on the critical path.
What does our team need to provide for the project?
Your team supplies the environment, the decisions and the people who will run the cluster afterward. Typical inputs include a named technical owner, access to racks, switches, storage arrays and DNS, identity and monitoring systems that the cluster must integrate with, an inventory of guests with their recovery priorities, and approved change windows for cutover and failover tests. You also need administrators with working knowledge of Linux, networking and storage. Ask any proposal to list these inputs in writing so you can assign owners before work starts.
Can our own engineers build Proxmox VE HA without a partner?
Yes. Proxmox VE is open-source software licensed under the GNU Affero General Public License, version 3, and its HA requirements are documented: at least three cluster nodes for reliable quorum, shared storage for guests, redundant hardware, and watchdog-based fencing. The main risk is in the details. Misconfigured fencing, storage paths that are not visible from every node, or untested HA groups can leave guests unable to recover or recovering in unexpected places. A partner is most useful when your team lacks the time, the recent experience or an independent test plan. Your team can still own the design, the build and the operations.
Does production Proxmox VE require a paid subscription?
No. The software can be used without a subscription. The enterprise repository requires a valid subscription key and is the recommended repository for production, while the freely accessible no-subscription repository is suited to testing and non-production use. All subscription tiers include the same software features. They differ in support entitlements and repository access: Community has no support tickets, Basic includes 3 tickets with a 1 business day response, Standard includes 10 tickets with a 4-hour response, and Premium includes unlimited tickets with a 2-hour response. Subscriptions are priced per socket per year. Confirm the tier that matches your change process and support model.
Which Proxmox VE versions are current and supported today?
The newest release in the vendor's announcements is Proxmox VE 9.2, released May 21, 2026, which adds a dynamic load balancer. Earlier releases in the 9 line are Proxmox VE 9.0, released August 5, 2025 on Debian 13, and Proxmox VE 9.1, released November 19, 2025. Support for each Proxmox VE version lasts at least as long as the matching Debian release receives Debian security support, roughly three years. Proxmox VE 8 on Debian 12 reached end of life in August 2026. Confirm the current release and its support window on the vendor site before you choose a version for a new cluster.
Why does Proxmox VE HA need three nodes and watchdog fencing?
Three nodes let the cluster keep quorum, so it can tell a failed node from a node that is merely cut off from the others. Watchdog-based fencing resets a failed node before its guests are restarted on another node, which prevents the same VM from running on two hosts at once. Checks for engineers include confirming that a watchdog device is present and enabled on every node, that fencing has been tested, that shared or replicated storage is reachable from each node, and that HA groups and priorities match your recovery plan. Record the results so operations staff can repeat the checks after changes.
How DeployOpen scopes, builds and hands over Proxmox VE HA
DeployOpen plans and builds Proxmox VE high availability clusters inside your own infrastructure, from host layout and quorum design through fencing, HA groups and failover testing. The work is agreed as a fixed scope in writing before it starts, and the cluster is handed over with documentation your team can operate.
How we scope
- Written scope lists node count, quorum design, shared or replicated storage and the guests placed under HA.
- Scope records which watchdog-based fencing method and HA groups will be configured for each workload.
- Scope names the network, storage and authentication integrations, plus the Proxmox VE version and repository tier to deploy.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before build work begins.
How we build
- Install and join at least three cluster nodes so quorum stays reliable when a single node fails.
- Configure shared storage or replicated storage that every HA guest can reach from any healthy node.
- Enable watchdog-based fencing on each node and confirm a failed node is reset before its guests restart elsewhere.
- Define HA groups and priorities so guests restart on healthy nodes that have the resources they need.
How we hand over
- Run scripted failover tests, including node power loss and network isolation, and record the observed recovery behavior.
- Document the cluster layout, quorum rules, fencing settings, HA group definitions and storage paths for your operators.
- Walk your administrators through routine checks, planned node maintenance and what to do when HA reports a fault.
- Deliver the written configuration and test evidence so your auditors or internal reviewers can trace each control.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover periodic failover retesting after hardware, network or storage changes in the cluster.
- Confirm with your Proxmox subscription provider which support tickets and response times your tier includes, since that is separate from DeployOpen's work.
