2.13. Migrating Virtual Machines and Containers

To facilitate hardware upgrades and load balancing between multiple hosts, Virtuozzo enables you to migrate virtual machines and containers between physical servers with the prlctl migrate command.

Important

For migration to work, a direct SSH connection on port 22 must be allowed between the source and destination servers.

Before migration, make sure that the destination server:

  • has enough hard disk space to store the resulting virtual machine or container,
  • has enough memory and CPU power to run the resulting virtual machine or container,
  • has a stable network connection with the source server.

Note

Migration of virtual machines with snapshots is not supported (any existing snapshots must be deleted).

You can migrate VMs and containers both to and from a remote server. For example, to move a VM to a remote server, run this command on the local server:

# prlctl migrate MyVM root:passwd@remoteserver.com

To move a VM from a remote server, run this command the local server:

# prlctl migrate root:passwd@remoteserver.com/MyVM localhost

If you do not provide the destination server credentials in the command, you will be asked to do so during migration.

If you want to place the migrated virtual environment in a custom directory on the destination server, specify the full path to that directory in the --dst=<custom_path> option. The resulting path to the migrated virtual environment files will be <custom_path>/<VE_UUID>.

By default, once migration is complete:

  • the original virtual machine is removed from the source server,
  • the .migrated suffix is added to the names of the original container’s private area and configuration file on the source server.

Adding the --clone option to the prlctl migrate command enables you to skip the two default actions above. That is, to keep the original VM and not to add the .migrated suffix to container’s private area and configuration file. The clone will have a different UUID, MAC address, SID (for Windows-based VMs only; if the --changesid option is specified), and offline management disabled.

Migration implies transferring large amounts of data between servers which can take considerable time. To reduce the amount of data to be transferred, Virtuozzo has compression enabled by default. Compression consumes additional server resources and can be disabled if necessary with the --no-compression option.

2.13.1. Types of Migration

Virtuozzo allows you to perform two types of migration between Virtuozzo servers:

  • Offline migration for stopped and suspended containers and virtual machines.
  • Online (live) migration for running containers and running and paused virtual machines. Containers and virtual machines may be located on Virtuozzo Storage or local storage.

Both types are described in the following sections.

2.13.1.1. Offline Migration of Virtual Machines and Containers

Offline migration implies copying all files of a virtual machine or container from one server to another over the network.

2.13.1.2. Live Migration of Virtual Machines and Containers

The process of migrating virtual machines and containers live is as follows:

  1. Once you start the migration, Virtuozzo checks whether the destination server meets all the migration requirements and the virtual machine or container can be migrated to it.
  2. All virtual memory and disks of the virtual machine or container are migrated to the destination server.
  3. The virtual machine or container on the source server is suspended.
  4. The changed memory pages and virtual disk blocks, if any, are migrated to the destination server.
  5. The virtual machine or container is resumed on the destination server.

The virtual machine or container continues running during steps 1 and 2 and is not available to the user during steps 3-5. But since the amount of memory pages and virtual disk blocks changed during step 2 is small, the downtime is almost imperceptible.

After migration, the relocated virtual machine or container may not be accessible over the network for several minutes due to network equipment reconfiguration (for example, as switches are updating their dynamic VLAN membership tables).

Note

For increased security during live migration, Virtuozzo provides connection tunneling between the source and destination servers. Tunneling increases migration time. If you do not need a secure tunnel between servers, you can speed up VM live migration by disabling connection tunneling with the --no-tunnel option. Tunnelless container migration is not supported. To use the option, configure the firewall of the destination server to allow incoming connections on any port on the corresponding network interface.

2.13.1.2.1. Live Migration Requirements and Restrictions

When performing live migration, take into account the following requirements and restrictions:

  • Before starting live migration, it is recommended to synchronize the system time on the source and destination servers, for example, by means of NTP (http://www.ntp.org). The reason is that certain processes running in virtual machines and containers may rely on system time being steady and might behave unpredictably when resumed on a destination server where time is different.

    Note

    In Virtuozzo 7, time synchronization via NTP is enabled by default using the chronyd service. If you want to use ntpdate or ntpd, stop and disable chronyd first.

  • The network must support data transfer rates of at least 1 Gbps.

  • The source and destination servers must belong to the same subnetwork.

  • The CPUs on the source and destination servers must be manufactured by the same vendor, and the CPU capabilities of the destination server must be the same or exceed those on the source server.

  • Virtual machine and container disks can be located on local disks, shared NFS and GFS2 storages, and iSCSI raw devices.

  • Live migration is not supported for virtual machines and containers with open prlctl enter sessions and containers with IPSec connections.

  • Containers with NFS clients inside can be migrated only if the following conditions are met:

    • Block and character device files shared over NFS are not opened.
    • Remote file locking and over-mounted NFS file systems are not used simultaneously.

    Note

    Migration of local file locks is supported only for NFS version 3 as it has native support of such locks.

  • Live migration is not supported for containers with enabled NFS server feature.

2.13.2. Migrating Virtual Machines and Containers Between Virtuozzo 7 Servers

You can migrate Virtuozzo 7 virtual machines and containers to other Virtuozzo 7 servers in any mode: online or offline (for details, see Types of Migration).

Virtual machines and containers stored in a Virtuozzo Storage cluster are migrated between cluster nodes without data copying, which significantly reduces migration time.

2.13.3. Migrating Virtual Machines and Containers from Virtuozzo 6 to Virtuozzo 7

You can migrate older Virtuozzo 6 virtual machines (online) and containers (offline) to Virtuozzo 7 servers. During migration, such VMs and containers will be converted in the Virtuozzo 7 format. In particular, VM devices will be replaced by those supported in Virtuozzo 7 (for a list of VM hardware supported in Virtuozzo 7, see Virtual Machine Hardware).

Note

Migration from Virtuozzo 6 to Virtuozzo 7 implies VM and container downtime that depends on network bandwidth, virtual machine RAM size, and server load. To reduce downtime, it is recommended to at least perform migration when the server load is minimal.

Before migrating Virtuozzo 6 virtual machines, make sure these requirements are met in addition to those listed in Live Migration Requirements and Restrictions:

  • The hardware node must be running the latest version of Virtuozzo 6 (or at least 6.0.11-3466).
  • The VM must have a guest OS installed.
  • The VM must be running.
  • The VM must not have snapshots.

For example, to migrate the virtual machine MyVM from Virtuozzo 6 to Virtuozzo 7, run the following command on the Virtuozzo 6 server:

# prlctl migrate MyVM root:<passwd>@<VZ7_host_IP_address_or_hostname>

During migration, the virtual machine is copied to the destination server and converted to the Virtuozzo 7 format. After a successful migration, the original Virtuozzo 6 virtual machine is unregistered and the .migrated suffix is added to its directory name.

Note

To avoid restarting migrated legacy VMs during conversion, such VMs have their --on-crash parameter set to paused (while the default value is restart). After successful migration, check this parameter, e.g., with prlctl list -i <VM_UUID|VM_name> | grep crash, and reset it if required with prlctl set <VM_UUID|VM_name> --on-crash restart.

If conversion fails, the migrated VM is deleted from the destination server and you can try again. If the second attempt also fails, you need to enable a legacy VM debug mode on the destination Virtuozzo 7 server (see Enabling Legacy VM Debug Mode), make another migration attempt, send the problem report, and contact the technical support team.

With the debug mode enabled, the migrated VM will not be deleted from the destination Virtuozzo 7 server after conversion failure. It will remain stopped or running with disabled network to let the technical support team study the memory dump and find out the reason for failure.

2.13.4. Migrating Virtual Machine and Container Templates

Migrating virtual machine and container templates between Virtuozzo servers is similar to migrating virtual machines and containers offline.

  • To migrate (move) the template template1 to the remote server remoteserver.com, on the local server run:

    # prlctl migrate template1 root:passwd@remoteserver.com
    
  • To migrate (move) the template template1 from the remote server remoteserver.com, on the local server run:

    # prlctl migrate root:passwd@remoteserver.com/template1 localhost
    

If you do not provide the remote server credentials in the command, you will be asked to do so during migration.

Once migration is complete, the original template is removed from the source server (unless --clone is added).

2.13.5. Migrating EZ Templates

Unlike migrating VM and container templates which by default moves them between servers, migrating EZ templates always copies them to a remote server. If the source EZ template is not needed after migration, you can manually delete it with the prlsrvctl cttemplate remove command.

You can migrate OS and application EZ templates between Virtuozzo servers with the prlsrvctl cttemplate copy command. For example, to copy the OS EZ template centos-7-x86-64 to the remote server remoteserver.com, on the local server run:

# prlsrvctl cttemplate copy root:passwd@remoteserver.com centos-7-x86-64

To copy an application EZ template, additionally specify the name of the corresponding OS EZ template.

Note

The specified OS template must be present on the destination server for migration to be successful.

For example, to copy the application template mysql of the OS template centos-7-x86-64 to the remote server remoteserver.com, run:

# prlsrvctl cttemplate copy root:passwd@remoteserver.com mysql centos-7-x86-64

If you do not provide the destination server credentials in the command, you will be asked to do so during migration.

To skip all validation checks, indicate the --force option.

After migration, you can check that the migrated EZ templates are present on the destination server with the prlsrvctl cttemplate list command:

# prlsrvctl cttemplate list
centos-7-x86_64  os  x86_64 yes   Centos 7 (for Intel EM64T) Virtuozzo Template
...
mysql            app x86_64 -     mysql for Centos 7 (for Intel EM64T) Virtuozz