Creating migrations
A migration defines how virtual machines are transferred from a source cloud to the target environment. It includes the selection of source VMs, target configuration, and mapping of networks and storage.
Changed Block Tracking (CBT) is enabled automatically on source VMs. It allows disk replication to run while source VMs remain online. Source VM downtime is expected only during the final switch to the target environment and OS morphing, when the source VM is stopped and the target VM is started.
Limitations
- Fixed IP addresses can be retained only if the source VM is powered on.
Prerequisites
- A source cloud is added, as described in Managing source clouds.
- For Windows migrations, the migration worker template is prepared and uploaded into the compute cluster, as described in Preparing the Windows migration worker template. (Linux migration worker templates are provided by default.)
- You have a network for target virtual machines. It can be either a shared physical network or a virtual network linked to a physical one via a virtual router. The virtual network needs to have a gateway and a DNS server specified.
To create a migration
Admin panel
- Go to the Compute > Migration > Migrations tab and click Migrate. The migration wizard opens, where you specify the migration parameters.
- On the Source cloud step, select a source cloud from which to migrate virtual machines.
- On the Source VMs step, select one or more virtual machines to migrate.
- On the Source options step, configure source-side options for the selected VMs. Select the vixDiskLib compatibility mode for your VMware environment. The default version 8.0 supports vSphere 6.7–8.x.
- On the Network mapping step, select target networks for each source network.
-
On the Target options step, configure the target environment:
- Enable DHCP client to automatically configure networking for the target VM.
- Enable Preserve fixed IPs to retain source IP addresses on the target VM.
- Select the correct OS distribution for the target VM. This parameter should match the source VM to ensure correct driver and configuration handling.
-
Specify advanced settings (if not specified, default values are applied):
-
Select a Flavor (CPU and RAM configuration) for the target VM. If not specified, a suitable flavor is created automatically.
The selected flavor must not be smaller than the source VM, as this may cause issues or result in an unusable VM due to insufficient resources.
- Select the Disk bus type: SCSI, IDE, or VirtIO. This parameter should match the source VM configuration to ensure compatibility and performance.
- Select the SSH key pair to inject into the target VM for access.
- Select the VM Machine type on the target platform: pc-i440fx or pc-q35. This parameter should match the source VM to ensure successful boot and compatibility.
-
- Enable Retain user credentials to preserve existing OS user credentials during migration.
- Enable Delete disks on VM deletion to automatically remove attached disks when the VM is deleted.
- If you selected a virtual compute network as a target network, you can enable Use floating IPs and select the Floating IP pool on the target platform to allocate floating IPs to the target VM.
- On the Storage mapping step, select a storage policy for target VM disks.
-
On the User scripts step, upload custom scripts to run on the guest OS during migration. Scripts can be uploaded per OS type (Windows or Linux). They are executed before OS morphing and only when OS morphing is enabled.
Supported script types include:
- For Linux VMs: any scripting language available on a standard Linux system (bash, python, etc.)
- For Windows VMs: PowerShell and batch scripts are supported.
User scripts can be used for the following scenarios:
- Install or remove packages inside the VM
- Make additional configuration changes
- Download files on the VM
- Install third-party drivers
-
On the Migration options step, configure how replication and deployment are performed:
-
Enable Start replication immediately to begin replication after creating the migration. If enabled, you can configure the following options:
- Enable Shut down source VMs to shut down source VMs during the final switch to the target environment.
- Enable Auto-deploy VMs to automatically deploy VMs after replication.
- Enable Clone disks to clone disks on the target platform instead of moving them. This allows continuous incremental synchronization to the same disks. If disabled, disks must be fully re-synced during the next replication.
-
Enable OS morphing to prepare the guest OS to run on the target platform by applying required drivers and removing source-specific components.
This step can be skipped when migrating between platforms using the same hypervisor (for example, KVM to KVM).
- Enable Start target VMs after deployment to start target VMs when they are deployed.
-
- On the Summary step, review the configuration. You can return to previous steps to make changes without losing data. Click Migrate to create the migration.
After creation, the migration appears in the Migrations list.
Depending on the selected options, replication starts immediately, or the migration is created and can be replicated later.
You can monitor the migration progress and manage replications and deployments on the migration details page.
Command-line interface
Use the following command:
vinfra service compute maas migration add --source-cloud <source_cloud> --instances <instances>
--network-mapping <source_network_name:target_network_name|target_network_id>
[--execute-now] [--automatically-enable-cbt | --dont-automatically-enable-cbt]
[--vixdisklib-compatibility-version <vixdisklib_version>] [--enable-dhcp | --disable-dhcp]
[--preserve-fixed-ips | --ignore-fixed-ips] [--flavor-name <flavor_name>]
[--disk-bus <disk_bus>] [--keypair-name <keypair_name>] [--os-distro <os_distro>]
[--machine-type <machine_type>] [--server-group <server_group>]
[--floating-ip-pool <floating_ip_pool>] [--enable-floating-ip | --disable-floating-ip]
[--preserve-floating-ip | --ignore-floating-ip] [--retain-user-credentials |
--ignore-user-credentials] [--delete-disks-on-vm-termination | --keep-disks-on-vm-termination]
[--clone-disks | --dont-clone-disks] [--force-deployment | --no-force-deployment]
[--os-morphing | --no-os-morphing] [--save-snapshot | --dont-save-snapshot] [--start | --dont-start]
[--windows-user-script-file <windows_user_script_file>] [--linux-user-script-file <linux_user_script_file>]
[--shutdown-instances | --dont-shutdown-instances] [--auto-deploy | --manual-deploy]
--source-cloud <source_cloud>- Source cloud ID or name
--instances <instances>- A comma-separated list of source instances to migrate
--execute-now- Run the migration immediately
--automatically-enable-cbt- Automatically enable CBT for the migrated instance
--dont-automatically-enable-cbt- Do not automatically enable CBT for the migrated instance
--vixdisklib-compatibility-version <vixdisklib_version>- VixDiskLib compatibility version
--enable-dhcp- Enable DHCP during OS morphing
--disable-dhcp- Disable DHCP during OS morphing
--preserve-fixed-ips- Preserve fixed IP addresses from the source environment
--ignore-fixed-ips- Do not preserve fixed IP addresses from the source environment
--flavor-name <flavor_name>- Flavor name to use in the target environment
--disk-bus <disk_bus>- Disk bus type
--keypair-name <keypair_name>- SSH key pair name to inject for VM access
--os-distro <os_distro>- OS distribution label
--machine-type <machine_type>- Specify the hardware class
--server-group <server_group>- Assign the VM a to server group
--floating-ip-pool <floating_ip_pool>- Specify the pool for floating IP address allocation
--enable-floating-ip- Enable allocation of floating IP addresses to the VM
--disable-floating-ip- Disable allocation of floating IP addresses to the VM
--preserve-floating-ip- Retain the original VM's floating IP address
--ignore-floating-ip- Do not retain the original VM's floating IP address
--retain-user-credentials- Keep existing OS credentials during migration
--ignore-user-credentials- Do not keep existing OS credentials during migration
--delete-disks-on-vm-termination- Automatically remove disks when the VM is deleted
--keep-disks-on-vm-termination- Keep disks when the VM is deleted
--network-mapping <source_network_name:target_network_name|target_network_id>- Network mapping between source and target environments. The target network can be specified by name or ID. Can be specified multiple times.
--clone-disks- Clone disks instead of moving them during migration
--dont-clone-disks- Move disks instead of cloning them during migration
--force-deployment- Force deployment even if some checks fail
--no-force-deployment- Do not force deployment if some checks fail
--os-morphing- Perform OS morphing
--no-os-morphing- Do not perform OS morphing
--save-snapshot- Keep existing snapshots of the source instances
--dont-save-snapshot- Do not keep existing snapshots of the source instances
--start- Start the instances after deployment
--dont-start- Do not start the instances after deployment
--windows-user-script-file <windows_user_script_file>- Path to a user script file to run on Windows deployments
--linux-user-script-file <linux_user_script_file>- Path to a user script file to run on Linux deployments
--shutdown-instances- Shut down source instances after migration completes
--dont-shutdown-instances- Do not shut down source instances after migration completes
--auto-deploy- Automatically create deployments for the migration
--manual-deploy- Create deployments manually for the migration
For example, to create a migration of the source VM ubuntu_24.04 from the cloud mycloud, run:
# vinfra service compute maas migration add --source-cloud mycloud --instances ubuntu_24.04 --network-mapping "VM Network":private \
--execute-now --automatically-enable-cbt \
--vixdisklib-compatibility-version 8.0 --enable-dhcp --ignore-fixed-ips --flavor-name medium --disable-floating-ip \
--retain-user-credentials --delete-disks-on-vm-termination --clone-disks --no-force-deployment \
--os-morphing --dont-save-snapshot --start --dont-shutdown-instances --auto-deploy
You can check that the migration is successfully created in the vinfra service compute maas migration list output:
# vinfra service compute maas migration list +---------------+--------------+-----------+----------------------+ | id | name | status | source_cloud_id | +---------------+--------------+-----------+----------------------+ | dc434e69<...> | ubuntu-22.04 | DEPLOYING | 3008d5c9<...> | +---------------+--------------+-----------+----------------------+