Migrating guests across hosts

Strategy selection

Migrating an app (container) to a different host isn’t a single mechanism: Proxploy picks the right one for your actual infrastructure, checked against live Proxmox state at the time you ask:

• Cluster-native: used when both hosts are already members of the same Proxmox cluster. The fastest and lowest-risk path, since Proxmox itself handles the transfer.
• Shared-storage: used when the hosts aren’t clustered together but share a common datastore. The guest’s disk doesn’t need to move; only its configuration and running state do.
• vzdump + SFTP: the fallback when neither of the above applies: the guest is backed up, the archive is transferred over SFTP to the destination host, and restored there.

Preflight, before you commit

Before a migration runs, preflight tells you which strategy was picked, an estimated transfer size, a time estimate, and any blockers or warnings for that guest-and-host pair, so you find out about a problem before the migration starts, not partway through. It also states the expected downtime plainly rather than implying the migration is seamless.

Once the migration actually runs, Proxploy records the measured downtime it took, not just the estimate, so you can see afterward how close the estimate was, side by side with what really happened.