Previous page

Next page

Locate page in Contents

Print this page

Standard Migration

The standard migration procedure allows you to move both stopped and running Containers. Migrating a stopped Container includes copying all Container private files from one Node to another and does not differ from copying a number of files from one server to another over the network. In its turn, the migration procedure of a running Container is a bit more complicated and may be described as follows:

  1. After initiating the migration process, all Container private data are copied to the Destination Node. During this time, the Container on the Source Node continues running.
  2. The Container on the Source Node is stopped.
  3. The Container private data copied to the Destination Node are compared with those on the Source Node and, if any files were changed during the first migration step, they are copied to the Destination Node again and rewrite the outdated versions.
  4. The Container on the Destination Node is started.

There is a short downtime needed to stop the Container on the Source Node, copy the Container private data changes to the Destination Node, and start the Container on the Destination Node. However, this time is very short and does not usually exceed one minute.

Note: Before the migration, it might be necessary to detach the Container from its caches. For more information on cached files, see the Cleaning Up Containers subsection.

The following session moves Container 101 from the current Hardware Node to a new one named

# vzmigrate 101's password:

vzmsrc: Connection to destination Hardware Node ( \

is successfully established

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

vzmsrc: Container migrating mode : first stage sync, with tracking, \

second stage sync, with Container stopping

vzmsrc: Syncing private area of Container#101 [/vz/private/101] ...

/ 100% |*****************************|

vzmsrc: done

vzmsrc: Stopping Container#101 ...

vzmsrc: done

vzmsrc: Fast syncing private area of Container#101 [/vz/private/101] ...

/ 100% |*****************************|

vzmsrc: done

vzmsrc: DST: Starting Container#101 ...

vzmsrc: DST: done

vzmsrc: Successfully completed

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.

Important! For the command to be successful, a direct SSH connection (on port 22) should be allowed between the Source and Destination Nodes.

By default, after the migration process is completed, the Container private area and configuration file are renamed on the Source Node by receiving the .migrated suffix. However, if you wish the Container private area on the Source Node to be removed after the successful Container migration, you can override the default vzmigrate behavior by changing the value of the REMOVEMIGRATED variable in the Virtuozzo global configuration file (/etc/vz/vz.conf) to "yes" or by using the r yes switch of the vzmigrate command.

To migrate one or more Containers to another Hardware Node with Parallels Virtuozzo Containers for Linux using Parallels Management Console, select these Containers from the list in the right pane after selecting the Virtuozzo 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 Management Console; otherwise, the migration option will not be available. A migration dialog appears, for example:

Management Console - Migrating Containers

In this window, you should do the following:

You can also specify the following options for the Container to be migrated:

When you are ready, click the Migrate button.

Please send us your feedback on this help page