User`s guide

Operations on Virtual Machines and Containers 54
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.