Server Migration

VirtFusion 3.0+ supports two types of server migration, Live and hybrid.

• Hybrid migration uses a system where the server can be offline or online. If the server is online, local storage will be transferred in two stages (once online and again with any changes with the server suspended). It will then be booted on the destination hypervisor once complete.
• Live migration uses Libvirt's (QEMU) inbuilt live migration and can migrate servers with local and shared (Ceph) storage. This type of migration relies on many factors, mainly hardware. See the live migration section for more detailed information.

info

Servers that have NAT interfaces can't currently be migrated by either migration system.

Live Migration

Live migration is currently managed via CLI on the control server with the exception of a live migration status log (Admin > Server > Live Migrations).

caution

For live migration to work correctly:

• The server must be online (running or suspended) or awaiting setup (internal transfer). It's also possible to migrate a server if it's offline, but you must supply the --force-offline parameter.
• The destination hypervisor must have SSH enabled (root) and the correct SSH port specified under the hypervisor settings.

Requirements

• All IP addresses must be usable on the destination hypervisor. No address changes are made (for obvious reasons).
• All storage mount points must exist on the destination hypervisor.
• Servers must have all storage enabled.
• The destination hypervisor CPU vendor must match the source hypervisor. This is only the basics where the CPU is concerned. If CPU flags are missing on the destination hypervisor, the migration will fail.

There are many more requirements for live migration. The rule of thumb is to make sure your hypervisors are as identical as possible. This includes the hypervisor operating system and version and also Libvirt and QEMU versions.

Start a Migration

vfcli-ctrl server:migrate-live start --dst=DESTINATION_HYPERVISOR_ID --server=SERVER_ID

info

A live migration can't be started if a server is offline. You can use the --force-offline argument to temporarily start the server in a paused mode so it can be transferred. It will then be shutdown once complete.

Argument	Required	Description
--dst=<destination hypervisor id>	Yes	ID of the destination hypervisor.
--server=<server id>	Yes	ID of the server.
--force-offline	No	If a server is not running. Attempt to start it in a paused mode.
--xfer-speed=<Mib/sec>	No	Set the max speed of the data transfer in Mib/sec (mebibyte/second).
--max-downtime=<ms>	No	Set the max downtime in milliseconds (default 300).
--abort-after=<sec>	No	Automatically abort the migration after the specified amount of time in seconds.
--disable-compression	No	By default compression is used. This argument will disable compression.
--disable-auto-converge	No	Auto converge is enabled by default. This argument will disable it.
--auto-converge-initial=<%>	No	if auto converge is enabled, reduce the CPU frequency by the specified percentage (1 - 70) when the migration starts.
--auto-converge-increment=<%>	No	if auto converge is enabled and the initial throttling rate is not enough to ensure convergence, the rate is periodically increased by the specified percentage (1 - 15).
--auto-post-copy	No	Enables post-copy logic and automatically switch to post-copy mode after the first pass of pre-copy is finished (disabled by default).
--disable-filter-check	No	By default, the source filters are checked and updated before transfer. This argument will disable the filter check.
--detach	No	Once the migration has started, detach from the migration process. This is useful if you would like to start more than one migration in the same session.
--json	No	Output all information is JSON format (non interactive).

If all pre tests pass. The migration will begin.

Each step will be shown in the console. The possible statuses are complete, in-progress or failed.

If the migration fails, you can attempt it again using the same command used to start the migration or simply server:migrate-live start --server=SERVER_ID.

Once the migration is complete. All steps will show as complete and no further action needs to be taken.

info

Using a remote console session can sometimes be troublesome. Disconnects are very common.

If you lose connection while a migration is ongoing, you can re-attach to the session by using the same command you started the migration. If the migration has already completed by the time you re-attach, you will receive an error that the server is already on the destination. In this case, no further action is required.

You may also use server:migrate-live start --server=SERVER_ID to re-attach and if the migration has already completed by the time you re-attach, you will receive the error Specify a destination hypervisor ID. In this case, no further action is required.

You may also use --detach if you don't want to monitor the migration. The --json argument is also available, but does not offer interactivity, just a hard status in JSON format.

Cancel a Migration

If a migration fails, it can be cancelled up to the point of a successful data transfer.

vfcli-ctrl server:migrate-live cancel --server=SERVER_ID

Status of a Migration

You can retrieve the last status of a migration. The possible statuses are complete, in-progress or failed

vfcli-ctrl server:migrate-live last-status --server=SERVER_ID

Debug Information for a Migration

You can retrieve the debug information of the last migration.

vfcli-ctrl server:migrate-live last-debug --server=SERVER_ID

Abort a Migration

You can abort a migration when its running a data transfer. If you try to abort a migration before it starts transferring data, you will receive an error. The same applies if you run this command after the data transfer.

vfcli-ctrl server:migrate-live abort --server=SERVER_ID

info

If an abort is successful, the migration will enter a failed status. To fully exit the migration process, you will need to run the cancel command.

Retrieve a List of Servers for a Specific Hypervisor

vfcli-ctrl server:migrate-live servers --src=SOURCE_HYPERVISOR_ID --json

info

This command is useful for scripting the migration process. For example https://github.com/chunguscodes/virtfusion-live-migrate

Expected output using the --json option.

{
  "servers": [
    {
      "id": 1902,
      "name": "Limited Arm",
      "uuid": "807127b4-dffb-4794-baa6-faf42028901f"
    },
    {
      "id": 1903,
      "name": "Immaterial Slide",
      "uuid": "265b131c-5f3f-4a6c-a961-364e969feedc"
    },
    ...
  ]
}

And without --json

1902,1903

Force Change Data Status

Important

This command is potentially dangerous and may result in data loss if used incorrectly.

This command can be used to set the data transfer process as complete. This would be used if all data tracking has been lost (unlikely situation) and you are sure the data transfer process has completed. If this command is successful, You are required to run the start command to complete the migration.

vfcli-ctrl server:migrate-live data-success-force --server=SERVER_ID

Force Cancel

Important

This command is potentially dangerous and may result in data loss if used incorrectly.

This command is similar to the cancel command, however it skips several of the migration checks (source server online, migration still running). This would be used if all data tracking has been lost (unlikely situation) and you are sure the data transfer process has failed.

vfcli-ctrl server:migrate-live cancel-force --server=SERVER_ID