Skip to content

Migration of Servers Between Compute Resources

In SolusVM 2.0, 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.

Migration Modes

SolusVM 2.0 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:

  1. Read known issues and limitations regarding migration. Pay attention to those marked with the icon. SolusVM 2.0 can’t check for these issues automatically before migration.
  2. Assign the IP block of the source compute resource to the destination compute resource as well.
  3. (For offline migration) Stop one or more servers you want to migrate.
  4. Go to Virtual Servers.
  5. Select one or more servers that have the same state (running or stopped) and then click Migrate.

    Note

    The servers you want to migrate can be located on the same or different compute resources.

  6. In the drop-down list, select the destination compute resource.

  7. To perform live migration, keep the “Live migration” checkbox selected. To perform offline migration, clear the checkbox.

  8. Click Start Migration.

SolusVM 2.0 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.0 performs all migration tasks inside one group one by one.
  • SolusVM 2.0 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

Note

SolusVM 2.0 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.0 can’t migrate a server if it has at least one snapshot. To migrate the server, you need to delete its snapshots.
  • The source and destination compute resources must have the same storage type. For example, SolusVM 2.0 can’t migrate a server from a compute resource that has LVM storage to a compute resource that has File Based storage.
  • Both the source and destination compute resources need TCP ports 8081 and 49152-49215 to be opened and not filtered. SolusVM 2.0 automatically opens these ports when adding compute resources. The ports are likely to be open unless you changed the default configuration.

For live migration only:

Note

Live migration inherits its limitations from Libvirt/QEMU.

  • The source and destination compute resources must have the same OS distributive. For example, SolusVM 2.0 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.0 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.
Back to top