Zero-Downtime Migration

The pmigrate utility also allows you to migrate your Containers from one Parallels server 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 Parallels server is transparent for you and the Container applications and network connections. This means that on the source and destination servers, 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 server 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 pctl enter command.

Before performing zero-downtime 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 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 server with different system clock parameters.

In the current version of Parallels Server Bare Metal, 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 server 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 server by leaving the main amount of memory in a locked state on the source server and swapping this memory from the source server on demand. Thus, the migrated Container can be started before the whole memory is transferred to the destination server, 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 server where this page is stored.
• Iterative online migration . In this case the main amount of Container memory is transferred to the destination server 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 server before 'dumping' a Container and the rest is transported after the Container has been successfully 'undumped' on the server.

To migrate a Container by using the zero downtime migration technology, you should pass the --online option to the pmigrate utility. By default, the iterative online migration type is used to move a Container from one Parallels server to another. For example, you can migrate Container 101 from the current server to the destination server named my_node.com by executing the following command:

Note: If the CPU capabilities on the source server exceed those on the destination server (e.g. you migrate from a source server running the Pentium 4 processor to a destination server 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 server is sufficient to start and run the Container(s) being migrated, you can use the -f option to force the migration process.

# pmigrate c 101 c --online --require-realtime my_node.com

Enter password:

Connection to destination server (192.168.1.57) \

is successfully established

Moving/copying Container#101 -> Container#101, [], [] ...

Syncing private area '/vz/private/101'

- 100% |***************************************

done

Suspending Container#101 ...

done

Dumping Container#101 ...

done

...

Migration completed

The --require--realtime option tells pmigrate 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, pmigrate 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 Parallels server one by one.

If you wish to use another migration type for moving your Containers to another server, you should additionally pass certain options to pmigrate :

• 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.