VirtFusion server migration moves a VPS from one hypervisor to another, for example to empty a node before hardware work or to balance load. Planning the IPs, storage and timing keeps downtime short and customers happy.
Before you start
- A destination hypervisor with enough free RAM, disk and a compatible storage type.
- Network access between source and destination hypervisors on the ports VirtFusion requires.
- A current backup of the server.
- Check your VirtFusion version's documentation for which migration types it supports (offline or live) and any storage limits.
Plan the VirtFusion server migration
- Same location, shared IP block: the VPS can usually keep its IPs.
- Different location or block: the IPs change. Tell the customer in advance so they can update DNS with a lower TTL.
- CPU: keep migrations between similar CPUs; moving between Intel and AMD can break live migration.
- Timing: large disks take time to copy; schedule outside peak hours and announce a window.
Run the migration
- In the admin area open the server.
- Choose the migrate action and select the destination hypervisor.
- Confirm and watch the task progress. Disk copy time depends on size and network speed.
- When the task completes, check the server is running on the new hypervisor.
Warning: Do not reboot or power off the source hypervisor until all migrations from it have finished and been checked.
Check afterwards
- The VPS answers ping and SSH on its IPs.
- Services inside the VPS are running (web, database, mail).
- If IPs changed, update rDNS and confirm the customer updated DNS.
- The old disk is removed from the source hypervisor so space is freed.
Troubleshooting
- Migration fails to start: check connectivity and SSH between hypervisors, and storage space on the destination.
- VPS has no network after moving: the IP block may not be routed to the new node, or the bridge name differs.
- Very slow copy: a private network link between hypervisors speeds things up.
Frequently asked questions
Is there downtime?
Offline migration stops the VPS during the copy; live migration, where supported, keeps downtime to seconds.
Can customers request migration?
Usually through a support ticket; it is an admin action.
What if the source node has failed?
Migration needs the source disk; restore from backups onto another node instead.