6,534
edits
Changes
→Migrating Container: filled in
* As distinct from a Container name, a Container description cannot be used for performing Container-related operations (e.g. for starting or stopping a Container) and is meant for reference purposes only.
== Expand Migrating Container == The OpenVZ Hardware Node is the system with higher availability requirements in comparison with a typical Linux system. If you are running your company mail server, file server, and web server in different Containers on one and the same Hardware Node, then shutting it down for hardware upgrade will make all these services unavailable at once. To facilitate hardware upgrades and load balancing between several Hardware Nodes, the OpenVZ software provides you with the ability to migrate Containers from one physical box to another. Migrating Containers is possible if OpenVZ is installed on two or more Hardware Nodes, so you are able to move a Container to another Node. Migration may be necessary if a Hardware Node is undergoing a planned maintenance or in certain other cases. {{Note|Containers created under the 32-bit OpenVZ version can be migrated to Hardware Nodes running the 64-bit OpenVZ version for the x86_64 processors and cannot be moved to Hardware Nodes running the OpenVZ for the IA-64 processors. Moreover, you can migrate Containers created under the corresponding OpenVZ 64-bit version to Nodes running the same OpenVZ version for 64-bit processors.}} === Standard (offline) 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: # 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.# The Container on the Source Node is stopped.# 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.# 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. The following session moves Container 101 from the current Hardware Node to a new one named ts7.mydomain.com: # '''vzmigrate ts7.mydomain.com 101''' Starting migration of container 101 on ts7.mydomain.com Preparing remote node Initializing remote quota Syncing private Syncing 2nd level quota Turning quota off Cleanup {{Note|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 removed on the Source Node. 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 <code>vzmigrate</code> behavior by using the <code>–r no</code> switch. === Zero-downtime (online) migration === OpenVZ 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 <code>vzctl enter ''CTID''</code> 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. To migrate a Container by using the zero downtime migration technology, you should pass the <code>--online</code> option to the <code>vzmigrate</code> utility. 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'. 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: # '''vzmigrate --online my_node.com 101'''
== Moving Container Within Hardware Node ==
== Copying Container Within Hardware Node ==
