The vzmigrate utility allows you to migrate your Containers from one Hardware Node to another with zero downtime. The zero downtime migration technology has the following main advantages as compared with the standard one:
The process of migrating a Container to another Node is transparent for you and the Container applications and network connections, i.e., on the Source and Destination Nodes, no modifications of system characteristics and operational procedures inside the Container are performed.
The Container migration time is greatly reduced. In fact, the migration eliminates the service outage or interruption for Container end users.
The Container is restored on the Destination Node in the same state as it was at the beginning of the migration.
You can move the Containers running a number of applications which you do not want to be rebooted during the migration for some reason or another.
Note: Zero-downtime migration cannot be performed on Containers having one or several opened sessions established with the vzctl enter CT_ID command.
Before performing zero-downtime migration, it is recommended to synchronize the system time on the Source and Destination Nodes, e.g. by means of NTP (http://www.ntp.org). The reason for this recommendation is that some processes running in the Container might rely on the system time being monotonic and thus might behave unpredictably if they see an abrupt step forward or backward in the time once they find themselves on the new Node with different system clock parameters.
In the current version of Parallels Virtuozzo Containers, you can make use of the following types of zero-downtime migration:
Simple online migration. In this case a Container is 'dumped' at the beginning of the migration, i.e. all Container private data including the state of all running processes are saved to an image file. This image file is then transferred to the Destination Node where it is 'undumped'.
Lazy online migration. Using this type of online migration allows you to decrease the size of the 'dumped' image file storing all Container private data and transferred to the Destination Node by leaving the main amount of memory in a locked state on the Source Node and swapping this memory from the Source Node on demand. Thus, the migrated Container can be started before the whole memory is transferred to the Destination Node, which drastically reduces the service delay of the corresponding Container. When a process tries to access a page of memory that has not yet been migrated, the request is intercepted and redirected to the Source Node where this page is stored.
Iterative online migration. In this case the main amount of Container memory is transferred to the Destination Node before a Container is 'dumped' and saved to an image file. Using this type of online migration allows you to attain the smallest service delay.
Iterative + lazy online migration. This type of online migration combines the techniques used in both the lazy and iterative migration types, i.e. some part of Container memory is transferred to the Destination Node before 'dumping' a Container and the rest is transported after the Container has been successfully 'undumped' on the Node.
-online option to the vzmigrate utility. By default, the iterative online migration type is used to move a Container from one Hardware Node to another. For example, you can migrate Container 101 from the current Hardware Node to the Destination Node named my_node.com by executing the following command:
Note: If the CPU capabilities on the Source Node exceed those on the Destination Node (e.g.
you migrate from a Source Node running the Pentium 4 processor to a Destination Node running the Pentium 3 processor), the migration may fail and you will be presented with the corresponding warning message. However, if you are sure that the CPU power on the Destination Node is sufficient to start and run the Container(s) being migrated, you can use the -f option to force the migration process.
# vzmigrate --online --require-realtime my_node.com 101 Enter password:
Connection to destination Hardware Node (192.168.1.57) \ is successfully established
Moving/copying Container#101 -> Container#101, [], [] ...
Syncing private area '/vz/private/101'
The --require--realtime option tells vzmigrate to move the Container by using the iterative online migration type only. So, if this migration type cannot be carried out for some reason or other, the command will fail and exit. If this option is omitted and in the case of failure while performing the iterative migration, vzmigrate will try to move your Container by means of the simple online migration type or the lazy online migration type (if the --lazy option is given). You can specify more than one Container ID simultaneously; in this case, all specified Containers will be moved to a new Hardware Node one by one.
If you wish to use another migration type for moving your Containers to another Node, you should additionally pass certain options to vzmigrate:
Specify the --noiter option to migrate a Container by using the simple online migration type;
Specify the --noiter and --lazy options to migrate a Container by using the lazy online migration type;
Specify the --lazy option to migrate a Container by using the iterative + lazy online migrate type.
To migrate one or more Containers in Parallels Management Console, select these Containers from the list in the right pane after selecting the Parallels Containers item in the left pane. Then right-click the selection and point to Tasks > Migrate to Another Hardware Node on the context menu. Note that the target Hardware Node must be already registered in Parallels Management Console; otherwise, the migration option will not be available. A migration dialog appears, for example:
Figure 10: Management Console - Migrating Containers In this window you can do the following:
Select the target Hardware Node where you want to migrate the selected Containers.
Select the Live migration radio button allowing you to migrate the Container using the zero downtime migration technology. In this case the Container will be migrated using the 'iterative online migration' type.
Select the Force migration check box to force the Container migration even if the templates necessary for the Container correct operation are not installed on the Destination Node.
However, it will be impossible to start such a Container after the migration in case of the absence of the needed templates.
Select the Remove the Container private area(s) check box to delete the Container private area from the Source Node after the Container successful migration.
When you are ready, click the Migrate button.
Migrating Containers With NFS and AutoFS Mounts
Parallels Virtuozzo Containers 4.6 introduces the following improvements in the process of migrating Containers using the zero downtime migration technology:
You can migrate running Containers with one or more Network File System (NFS) directories mounted.
You can migrate running Containers with one or more AutoFS mount points, including NFS directories managed by AutoFS.