Migrate VMs
You can migrate a running VM by using live migration or storage live migration to move a VM’s Virtual Disk Image (VDI) without any VM downtime.
Live migration and storage live migration
The following sections describe the compatibility requirements and limitations of live migration and storage live migration.
Live migration
Live migration is available in all versions of XenServer. This feature enables you to move a running VM from one host to another host, when the VM’s disks (VDIs) are on storage shared by both hosts. Pool maintenance features such as high availability and Rolling Pool Upgrade (RPU) can automatically move VMs by using live migration. These features allow for workload leveling, infrastructure resilience, and the upgrade of server software, without any VM downtime.
During the live migration of a VM, its memory is transferred as a data stream between two hosts using the network. The migration stream compression feature compresses this data stream, speeding up the memory transfer on slow networks. This feature is disabled by default, but this can be changed by using XenCenter or the xe CLI. For more information, see Pool Properties - Advanced and Pool parameters. Alternatively, you can enable compression when migrating a VM by using the command line. For more information, see the vm-migrate command in VM Commands.
The parallel host evacuation feature speeds up host evacuation time (during host updates) by moving VMs off a host in parallel instead of sequentially. By default, this feature is enabled and the VMs are migrated in batches of 10 in parallel. You can change the default batch size in the /etc/xapi.conf file.
Note:
Storage can only be shared between hosts in the same pool. As a result VMs can only be migrated to hosts in the same pool.
Storage live migration
Notes:
- Do not use storage live migration in Citrix Virtual Desktops deployments.
- Storage live migration cannot be used on VMs that have changed block tracking enabled. Disable changed block tracking before attempting storage live migration.
- Storage live migration cannot be used on VMs whose VDIs are on a GFS2 or XFS SR.
Storage live migration allows a VM to be moved from one host to another, when the VM’s disks are not on storage shared between the two hosts. As a result, VMs stored on local storage can be migrated without downtime and VMs can be moved from one pool to another. This feature enables system administrators to:
-
Rebalance VMs between XenServer pools (for example from a development environment to a production environment).
-
Upgrade and update standalone XenServer hosts without any VM downtime.
-
Upgrade XenServer server hardware.
Note:
Migrating a VM from one host to another preserves the VM state. The state information includes information that defines and identifies the VM and the historical performance metrics, such as CPU and network usage.
To improve security, you can close TCP port 80 on the management interface of your XenServer hosts. However, you cannot migrate a VM from a Citrix Hypervisor 8.2 CU1 pool without hotfix XS82ECU1033 installed, to a XenServer pool with port 80 closed. To do so, install XS82ECU1033 on your Citrix Hypervisor 8.2 CU1 pool or temporarily open port 80 on your XenServer pool. For more information about how to close port 80, see Restrict use of port 80.
Compatibility requirements
When migrating a VM with live migration or storage live migration, the VM and servers must meet the following compatibility requirements.
General requirements:
-
The target host must have the same or a more recent version of XenServer installed as the source host. For hosts on the same version of XenServer, this requirement also includes ensuring that your target host has the same or more recent level of updates as the source host.
-
XenServer VM Tools for Windows must be installed on each Windows VM that you want to migrate.
-
You cannot concurrently migrate more than three VMs that have their source location in the same pool.
CPU requirements:
-
If the CPUs on the source and target host are different, the target host must be at least as capable as the source host. Generally, this means that the target has the same or a newer CPU.
- If you are migrating within the same pool, the pool automatically attempts to make a VM compatible.
- If you are migrating between pools, you must ensure that the VM is compatible with the feature set in the destination pool.
-
You cannot live migrate a VM between AMD and Intel processors.
Memory requirements:
-
The target host must have sufficient spare memory capacity or be able to free sufficient capacity using Dynamic Memory Control. If there is not enough memory, the migration fails to complete.
-
Storage migration only: A host in the source pool must have sufficient spare memory capacity to run a halted VM that is being migrated. This requirement enables the halted VM to be started at any point during the migration process.
Disk space requirements:
-
Storage live migration only: The target storage must have enough free disk space available for the incoming VMs. The free space required can be three times the VDI size (without snapshots). If there is not enough space, the migration fails to complete.
-
The source storage must have enough free disk space to create temporary snapshots of the VM’s VDIs during the migration. If there is not enough space, the migration fails to complete. The free space required can be up to two times the size of the VM’s disk.
Limitations and caveats
Live migration and storage live migration are subject to the following limitations and caveats:
- Storage live migration cannot be used with VMs created by Machine Creation Services.
- VMs using PCI pass-through devices cannot be migrated (except in the case of NVIDIA SR-IOV GPUs). For more information, see Use SR-IOV enabled NICs.
- VMs with attached vUSBs cannot be migrated.
- VMs with the parameter
no-migrateset cannot be migrated. - You cannot use storage live migration to migrate VMs that have changed block tracking enabled. Disable changed block tracking before attempting storage live migration. For more information, see Changed Block Tracking.
- VMs that have the
on-bootoption set toresetcannot be migrated. For more information, see Intellicache. - If you use the high availability feature and the VM being migrated is marked as protected, you might receive a warning during live migration if the operation causes the HA constraints to not be met.
- VM performance is reduced during migration.
- Time to completion of VM migration depends on the memory footprint of the VM, and its activity. In addition, the size of the VDI and the storage activity of the VDI can affect VMs being migrated with storage live migration. VMs with vGPUs attached migrate the entire vGPU state while the VM is paused. We recommended that you use a fast network card on the management network to reduce downtime, especially with vGPUs that have large amounts of memory.
- If live migration fails, for example, in the case of a network error, the VM on the source host can instantly go to a halted state.
Migrate a VM using XenCenter
-
In the Resources pane, select the VM and do one of the following:
-
To migrate a running or suspended VM using live migration or storage live migration, on the VM menu, click Migrate to Server and then Migrate VM wizard. This action opens the Migrate VM wizard.
-
To move a stopped VM: On the VM menu, select Move VM. This action opens the Move VM wizard.
-
-
From the Destination list, select a standalone host or a pool.
-
From the Home Server list, select a host to assign as the home server for the VM and click Next.
-
In the Storage tab, specify the storage repository where you would like to place the migrated VM’s virtual disks, and then click Next.
-
The Place all migrated virtual disks on the same SR radio button is selected by default and displays the default shared SR on the destination pool.
-
Click Place migrated virtual disks onto specified SRs to specify an SR from the Storage Repository list. This option allows you to select different SR for each virtual disk on the migrated VM.
-
-
From the Storage network list, select a network on the destination pool that is used for the live migration of the VM’s virtual disks. Click Next.
Note:
Due to performance reasons, it is recommended that you do not use your management network for live migration.
-
Review the configuration settings and click Finish to start migrating the VM.
If you are upgrading from 7.1 CU2 to 8.2 CU1, you might need to shut down and boot all VMs after migrating your VMs, to ensure that new virtualization features are picked up.
Live VDI migration
Live VDI migration allows the administrator to relocate the VMs Virtual Disk Image (VDI) without shutting down the VM. This feature enables administrative operations such as:
- Moving a VM from cheap local storage to fast, resilient, array-backed storage.
- Moving a VM from a development to production environment.
- Moving between tiers of storage when a VM is limited by storage capacity.
- Performing storage array upgrades.
Limitations and caveats
Live VDI Migration is subject to the following limitations and caveats
-
Do not use storage live migration in Citrix Virtual Desktops deployments.
-
IPv6 Linux VMs require a Linux Kernel greater than 3.0.
-
If you perform live VDI migration on a VM that has a vGPU, vGPU live migration is used. The host must have enough vGPU space to make a copy of the vGPU instance on the host. If the pGPUs are fully employed, VDI migration might not be possible.
-
When you do a VDI live migration for a VM that remains on the same host, that VM temporarily requires twice the amount of RAM.
To move virtual disks
-
In the Resources pane, select the SR where the Virtual Disk is stored and then click the Storage tab.
-
In the Virtual Disks list, select the Virtual Disk that you would like to move, and then click Move.
-
In the Move Virtual Disk dialog box, select the target SR that you would like to move the VDI to.
Note:
Ensure that the SR has sufficient space for another virtual disk: the available space is shown in the list of available SRs.
-
Click Move to move the virtual disk.