Migrate a VPS within a Virtualizor cluster only after checking destination storage, CPU compatibility and network reachability. Choose live or offline movement according to the virtualization type and tested platform support. The objective is one authoritative guest on the destination with a verified application state.
IN THIS ARTICLE
Prepare for the change
Back up the guest independently and record its ID, disks, IPs, virtual hardware and current task state. Reserve destination capacity and a maintenance window. Confirm any storage snapshots, attached volumes or special devices are supported by the selected migration path.
01 Move a Virtualizor VPS between hosts
- Compare source and destination host software and CPU capabilities. For KVM live migration, verify the guest CPU model and installed-version requirements. Prefer an agreed offline window when compatibility is uncertain.
- Confirm the guest IP can operate on the destination network. If addresses must change, prepare guest settings, DNS, firewall rules, mail identity and external allowlists together.
- Check storage type and capacity. Select shared-storage migration only when both hosts genuinely access the same supported guest storage; otherwise the disk needs a supported transfer.
- Open the supported migration action for the exact VPS, choose the destination and review prechecks. Keep the source guest and its disks intact until the platform determines the transfer state.
- Monitor the migration task and then test the destination console, networking and application. Update backup associations and inventory after successful acceptance.
Does live migration guarantee no customer-visible interruption?
No. Device compatibility, transfer time, final switchover and application sensitivity matter. Test the actual workload and retain an outage plan even when the platform offers live movement.
Confirm the expected result
Confirm the guest is active on exactly one host, with all intended disks attached and no unintended IP conflict. Test a database-backed request, scheduled service and reboot when the window allows. Check storage latency and backup operation on the new host.
If the change does not work
For a failed transfer, read the migration task and identify whether the original or destination copy is authoritative. Do not manually start both copies or delete temporary disks without understanding the transfer state. A rollback must account for any writes made after the destination started.