Use the current Virtualizor HA requirements for the specific deployment. The documented native KVM design requires at least four nodes including the master, supported host systems, shared guest storage and shared configuration arrangements. Proxmox integration has a separate procedure. Engage an experienced cluster administrator before modifying an existing production fleet.

1. Design the failure domains first. Reserve enough surviving CPU and RAM for displaced guests and ensure shared storage does not become an unprotected single point of failure. Include power, network and management access in the plan.
2. Verify the guest address pool can function on every candidate host. A guest restart elsewhere is ineffective if its IP cannot be routed there.
3. Prepare the vendor-required shared storage and configuration paths. Preserve existing files before any mount operation; mounting over a populated directory can hide essential configuration without deleting it.
4. Create the HA-enabled server group before adding the intended nodes, following the installed-version sequence. Watch the installation tasks and inspect cluster membership rather than assuming successful panel entry means a healthy cluster.
5. Review quorum, fencing and failure-detection behavior with the cluster design. Do not disable fencing or quorum checks to make a warning disappear. Those protections help prevent competing hosts from writing the same disks.
6. Create a disposable HA guest and validate normal operation. In an isolated, approved test window, simulate the documented failure scenario and measure detection, restart and application recovery.
7. Use the HA monitoring interface and relevant cluster status tools to confirm one authoritative running instance. Restore normal membership, verify capacity and document the procedure before moving production workloads into the group.

No. HA can restart a guest after an infrastructure failure, but it does not undo accidental deletion, ransomware or database corruption. Applications with stricter availability requirements may also need their own replication and failover design.

Test both a host outage and the recovery of that host without creating duplicate guests. Check application consistency after restart, alert delivery and the operator actions needed when automatic recovery cannot complete. Retain independent backups and periodically verify a restore outside the HA cluster.

If a resource remains stopped, investigate quorum, fencing, shared-storage availability and destination capacity. Starting it manually on another node without ownership checks can corrupt shared disks. Preserve cluster logs and escalate ambiguous split ownership rather than bypassing safety checks. Keep customer-facing recovery expectations aligned with measured tests.

• Moving a Virtualizor VPS between hosts
• Adding storage to a Virtualizor host
• Configuring a Virtualizor IP pool
• Scheduling a Virtualizor VPS backup

• Virtualizor: High Availability
• Virtualizor: Install Proxmox
• clusterlabs.org: Pacemaker