Archived

This repository has been archived on 2026-08-17. You can view files and clone it. You cannot open issues or pull requests or push a commit.

Files

T

beatzaplenty a854412117 Initial planning docs and hardening scripts for HA rebuild

Covers node 1 hardware/network layout, LVM-thin -> ZFS migration path,
Ceph as the future HA storage upgrade, and baseline SSH/firewall
hardening.

2026-07-20 11:45:54 +10:00

2.5 KiB

Raw Blame History

Overview & Roadmap

Background

Current hardware requires disabling KVM hardware virtualization for VMs to start at all (falls back to software emulation — slow). This is a host/BIOS-level issue, not a Proxmox limitation, and shouldn't be needed on new hardware. Before reusing that workaround on the new box:

Confirm VT-x (Intel) / AMD-V (AMD) is enabled in BIOS/UEFI.
Confirm IOMMU is enabled if passthrough is planned.
Update BIOS/microcode first.
Rule out running Proxmox nested inside another hypervisor.

End goal

3-node Proxmox VE cluster with HA-managed VMs. Two ways to get VM disks available on more than one node (see 02-storage-zfs-ceph.md):

Ceph — true distributed shared storage, sync replication, needs 3+ nodes and a fast dedicated network. Zero/near-zero RPO on failover.
ZFS + storage replication — local ZFS pool per node, Proxmox replicates VM disks between nodes on a schedule (as often as every minute). Lighter weight, async — failover loses whatever changed since last replication.

Starting point: ZFS + replication (lighter, works from node 1 onward). Ceph is the upgrade path once 3 nodes exist and/or zero-RPO failover matters enough to justify the overhead.

Cluster fundamentals (apply from node 1 onward)

3 nodes minimum for real quorum. If starting with 2, add a QDevice (small VM or Raspberry Pi) as tie-breaker.
Dedicated network for corosync (cluster/quorum traffic) — never shared with VM or storage traffic. Needs low, consistent latency (well under 5ms); jitter matters more than bandwidth.
All nodes on the same PVE version, NTP-synced, SSH reachable between nodes.
Set VM CPU type to a portable type (e.g. x86-64-v2-AES or kvm64) rather than host if nodes will ever have different CPUs — needed for clean live migration.

Rollout sequence

Build node 1 per 01-hardware-node1.md — fresh PVE install on ZFS boot mirror, local ZFS "tier 2" pool for VM disks, Ceph-earmarked disks left idle or as a temporary ZFS pool.
Migrate VMs off old hardware via vzdump → copy backups → qmrestore onto the new ZFS storage (converts disks to ZVOLs).
Apply hardening (04-security-hardening.md) and networking (03-networking.md) before exposing the node beyond the LAN.
Add nodes 2 and 3 identically (same disk/network layout).
Join cluster, stand up dedicated corosync network, configure replication and HA groups.
Optionally migrate the Ceph-earmarked disks from temporary ZFS to real Ceph OSDs once 3 nodes are up.

2.5 KiB Raw Blame History