Recovery placement & networking

When you fail over, Asternodis needs to know where recovered guests should run and how they should be networked at the recovery site.

Recovery node

Pick the node in the recovery cluster where failover and DR-test VMs are placed. If you don’t set one, Asternodis uses the first SSH-configured remote’s host by default. Set a pair-wide default in Settings or when configuring the pair, and override it per guest on the Replication page when a particular workload needs to land on a specific recovery node. The setting applies across the pair from either site.

Failback to a chosen node (returning a failed-over guest to a healthy sibling at the home site instead of its original node) is a separate choice made at failback time. Where it is open depends on where the guest’s disks are, and the failback screen says, per guest, whether it is and why not. Guests on storage only their home node can read (a non-shared ZFS pool, node-local LVM-thin, or a local directory) get a full copy onto fresh disks on the node you pick, and a VM loses its retained recovery points to it. VMs whose disks are all on storage both nodes see (Ceph/RBD, NFS and the like) are moved without copying anything. A container can use it only on ZFS. It is unavailable for a guest managed by Proxmox HA, in a cluster that has lost quorum or has a single node, with disks spread across several storages, or on thick LVM or iSCSI; those guests return to their original home node, or come home via Abort failover.

Where replicas are stored

Independently of where guests run on failover, you choose where each guest’s recovery replica physically lives at the recovery site: any directory/NFS/CIFS share or a native ZFS, LVM-thin, or Ceph/RBD volume, per guest or per pair. See Where the replica lives and the Shadows page.

Network mapping

Production and recovery sites rarely share the same bridges or subnets. Network mapping (on a pair) tells Asternodis which recovery-side bridge each production network maps to, so guests come up attached to the right network.

Keeping IPs: the DR edge gateway

For workloads that must keep their addresses, Asternodis can run a DR edge gateway: the recovery node routes an isolated bridge that mirrors a production subnet, so recovered VMs boot with their original IPs and the gateway handles NAT and port-forwarding. This also underpins isolated DR testing, where test VMs run on a fenced network that can’t reach production.

Re-IP profiles

Alternatively, apply a re-IP profile to rewrite guest addresses on failover (new IP, gateway, DNS), useful when the recovery site uses a different address space and you don’t need to preserve IPs.

You configure these per pair on the Site Pairs and Replication pages. Next: protect your guests.