Migration of Servers Between Compute Resources¶
In SolusVM 2, you can migrate one or more servers to another compute resource.
Migration is useful if you want to do the following while continuing to offer service to your users:
- Decrease the compute resource’s load (a number of servers deployed on one compute resource).
- Perform maintenance on a compute resource.
- Decommission a compute resource.
SolusVM 2 has the following migration modes:
- Live migration, which is performed for running servers and preserves the server IP address.
- Offline migration, which is performed for stopped servers and, at the moment, always preserves the server IP address. Offline migration that will change the server IP address is currently in development.
Both live and offline migration have their benefits:
- During live migration, a server has a short downtime and can be even available online.
- After live migration, a server is fully functional without any additional actions on your part.
- Offline migration has fewer limitations compared with live migration.
To migrate one or more servers to another compute resource:
- Read known issues and limitations regarding migration. Pay attention to those marked with the icon. SolusVM 2 can’t check for these issues automatically before migration.
- Assign the IP block of the source compute resource to the destination compute resource as well.
- (For offline migration) Stop one or more servers you want to migrate.
- Go to Virtual Servers.
Select one or more servers that have the same state (running or stopped) and then click Migrate.
The servers you want to migrate can be located on the same or different compute resources.
In the drop-down list, select the destination compute resource.
To perform live migration, keep the “Live migration” checkbox selected.
To perform offline migration, clear the checkbox.
To change IP addresses, clear the "Preserve IP" checkbox.
To change server storage type during migration, choose "Convert storage type and image format".
Click Start Migration.
SolusVM 2 will now check if the migration is possible. If the check is successful, migration starts.
After live migration is finished, the migrated server is up and running. After offline migration is finished, you need to start the server.
Migration Time Estimation¶
Migration time varies depending on the following factors:
- The memory and disk size of the migrated server.
- How intensively the server is used.
- Network speed.
It’s impossible to give accurate time estimation.
To know how much time migration will take, perform migration in your environment. Use a test server whose configuration matches that of the actual server you want to migrate. Test both live and offline migration because their time differs.
Migration Tasks and Groups¶
You can migrate one or more servers from the same or different compute resources. When you migrate one server, we call it a migration task. When you launch migration of multiple servers in one go, we call it a migration group.
A migration group always consists of separate migration tasks. For example, if you launch migration of three servers at once, you have one migration group that consists of three migration tasks.
Migrations tasks and groups are processed as follows:
- SolusVM 2 performs all migration tasks inside one group one by one.
- SolusVM 2 can process no more than three migration groups in parallel. If you launch the fourth migration group when the first three are still running, the fourth migration group will fail.
- Each compute resource can process only one migration task at a time.
Known Issues and Limitations¶
SolusVM 2 can’t automatically check for the issues marked with the icon.
For both live and offline migration:
- The destination compute resource must have the same IP block that is assigned to the source compute resource.
- SolusVM 2 can’t migrate a server if it has at least one snapshot. To migrate the server, you need to delete its snapshots.
- Both the source and destination compute resources need TCP ports 8081 and 49152-49215 to be opened and not filtered. SolusVM 2 automatically opens these ports when adding compute resources. The ports are likely to be open unless you changed the default configuration.
- Migration with conversion of storage type and image format requires
nbdkernel module to be compiled and loaded on CentOS 7.
- After migration with conversion of storage type and image format, there are cases when backups created with previous storage type can't be restored to a new virtual server's storage type. The following table describes support state of these cases:
|Storage type of a server in backup||Current storage type of a server|
|ThinLVM||LVM||File-based raw||File-based QCOW2|
|OK||Restore not supported||Restore not supported||Restore not supported|
Restoring a file-based QCOW2 backup into a File-based Raw / LVM / ThinLVM virtual server will generate intermediate data in the Compute Resource’s Temporary Backup Directory. This process requires sufficient free space to accommodate the entire dataset of the virtual server. Temporary Backup Directory can be configured in Compute Resource's settings tab.
For live migration only:
Live migration inherits its limitations from Libvirt/QEMU.
- The source and destination compute resources must have the same OS distributive. For example, SolusVM 2 can’t migrate a server from a compute resource on Ubuntu to a compute resource on CentOS.
- The destination compute resource must have the same or later version of the OS distributive as the source compute resource. For example, SolusVM 2 can’t migrate a server from a compute resource on CentOS 8 to the compute resource on CentOS 7.
- The source and destination compute resources must have CPU from the same vendor and from the same generation or family.
- |image-exclamation-mark| We don’t recommend migration between old and new CPU generations or families of the same vendor. For example, migration between compute resources with Intel® Core™ i7 and Intel® Xeon® processors or between AMD Ryzen™ and AMD EPYC™. Such migration can fail or freeze the migrated server.
- The source and destination compute resources must have the same activated parameters (if any), for example, nested virtualization. If the parameters don’t match, such migration can fail or freeze the migrated server.
- Live migration with conversion storage type and image format is not available for now but can be added in the future releases.
- In-place live migration with conversion storage type and image format is not available for now but can be added in the future releases.