Editing User Guide/Operations on Containers
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 2: | Line 2: | ||
This chapter describes how to perform day-to-day operations on separate Containers taken in their wholeness. | This chapter describes how to perform day-to-day operations on separate Containers taken in their wholeness. | ||
− | {{Note|We assume that you have successfully installed, configured, and deployed your OpenVZ system. In case you have not, please turn to the [[Installation Guide]] providing detailed information on all these operations. | + | {{Note|We assume that you have successfully installed, configured, and deployed your OpenVZ system. In case you have not, please turn to the [[Installation Guide]] providing detailed information on all these operations. |
== Creating New Container == | == Creating New Container == | ||
Line 26: | Line 26: | ||
* ID 0 is used for the Hardware Node itself. You cannot and should not try to create a Container with ID 0. | * ID 0 is used for the Hardware Node itself. You cannot and should not try to create a Container with ID 0. | ||
− | * The OpenVZ software reserves the IDs ranging from 0 to 100. Though OpenVZ uses only ID 0, future versions might use additional Container IDs for internal needs. | + | * The OpenVZ software reserves the IDs ranging from 0 to 100. Though OpenVZ uses only ID 0, future versions might use additional Container IDs for internal needs. Please do not create Containers with IDs below 101. |
The only strict requirement for a Container ID is to be unique for a particular Hardware Node. However, if you are going to have several computers running OpenVZ, we recommend assigning different Container ID ranges to them. For example, on Hardware Node 1 you create Containers within the range of IDs from 101 to 1000; on Hardware Node 2 you use the range from 1001 to 2000, and so on. This approach makes it easier to remember on which Hardware Node a Container has been created, and eliminates the possibility of Container ID conflicts when a Container migrates from one Hardware Node to another. | The only strict requirement for a Container ID is to be unique for a particular Hardware Node. However, if you are going to have several computers running OpenVZ, we recommend assigning different Container ID ranges to them. For example, on Hardware Node 1 you create Containers within the range of IDs from 101 to 1000; on Hardware Node 2 you use the range from 1001 to 2000, and so on. This approach makes it easier to remember on which Hardware Node a Container has been created, and eliminates the possibility of Container ID conflicts when a Container migrates from one Hardware Node to another. | ||
Line 58: | Line 58: | ||
After the Container ID and the installed OS template have been chosen, you can create the Container ''private area'' with the <code>vzctl create</code> command. The ''private area'' is the directory containing the actual files of the given Container; it is usually residing in <code>/vz/private/''CTID''/</code>. The private area is mounted to the <code>/vz/root/''CTID''</code> directory on the Hardware Node and provides Container users with a complete Linux file system tree. | After the Container ID and the installed OS template have been chosen, you can create the Container ''private area'' with the <code>vzctl create</code> command. The ''private area'' is the directory containing the actual files of the given Container; it is usually residing in <code>/vz/private/''CTID''/</code>. The private area is mounted to the <code>/vz/root/''CTID''</code> directory on the Hardware Node and provides Container users with a complete Linux file system tree. | ||
− | The <code>vzctl create</code> command requires only the Container ID and the name of the OS template as arguments; however, in order to avoid setting all the Container resource control parameters after creating the private area, you can specify a sample configuration to be used for your new Container. The sample configuration files are residing in the | + | The <code>vzctl create</code> command requires only the Container ID and the name of the OS template as arguments; however, in order to avoid setting all the Container resource control parameters after creating the private area, you can specify a sample configuration to be used for your new Container. The sample configuration files are residing in the /etc/vz/conf directory and have names with the following mask: <code>ve-''configname''.conf-sample</code>. The most commonly used sample is the <code>ve-basic.conf-sample</code> file; this sample file has resource control parameters suitable for most Containers. |
Thus, for example, you can create a new Container by typing the following string: | Thus, for example, you can create a new Container by typing the following string: | ||
Line 114: | Line 114: | ||
Adding IP address(es): 10.0.186.1 | Adding IP address(es): 10.0.186.1 | ||
Saved parameters for CT 1010101 | Saved parameters for CT 1010101 | ||
− | # | + | # vzctl set 101 --nameserver 192.168.1.165 --save |
File resolv.conf was modified | File resolv.conf was modified | ||
Saved parameters for CT 1010101 | Saved parameters for CT 1010101 | ||
Line 141: | Line 141: | ||
Setting the root user password is necessary for connecting to a Container via SSH. By default, the root account is locked in a newly created Container, and you cannot log in. In order to log in to the Container, it is necessary to create a user account inside the Container and set a password for this account, or unlock the root account. The easiest way of doing it is to run: | Setting the root user password is necessary for connecting to a Container via SSH. By default, the root account is locked in a newly created Container, and you cannot log in. In order to log in to the Container, it is necessary to create a user account inside the Container and set a password for this account, or unlock the root account. The easiest way of doing it is to run: | ||
+ | # '''vzctl start 101''' | ||
+ | ''[This command starts Container 101, if it is not started yet]'' | ||
# '''vzctl set 101 --userpasswd root:test''' | # '''vzctl set 101 --userpasswd root:test''' | ||
− | In this example, we set the root password for Container 101 to "test", and you can log in to the Container via SSH as root and administer it in the same way as you administer a standalone Linux server: install additional software, add users, set up services, and so on. The password will be set inside the Container in the <code>/etc/shadow</code> file in an encrypted form and will not be stored in the Container configuration file. Therefore, if you forget the password, you have to reset it. Note that <code>--userpasswd</code> ignores the <code>--save</code> switch, the password is persistently set for the given Container. | + | In this example, we set the root password for Container 101 to "test", and you can log in to the Container via SSH as root and administer it in the same way as you administer a standalone Linux server: install additional software, add users, set up services, and so on. The password will be set inside the Container in the <code>/etc/shadow</code> file in an encrypted form and will not be stored in the Container configuration file. Therefore, if you forget the password, you have to reset it. Note that <code>--userpasswd</code> ignores the <code>--save</code> switch, the password is anyway persistently set for the given Container. |
While you can create users and set passwords for them using the <code>vzctl exec</code> or <code>vzctl set</code> commands, it is suggested that you delegate user management to the Container administrator advising him/her of the Container root account password. | While you can create users and set passwords for them using the <code>vzctl exec</code> or <code>vzctl set</code> commands, it is suggested that you delegate user management to the Container administrator advising him/her of the Container root account password. | ||
Line 175: | Line 177: | ||
# vzlist 101 | # vzlist 101 | ||
CTID NPROC STATUS IP_ADDR HOSTNAME | CTID NPROC STATUS IP_ADDR HOSTNAME | ||
− | + | 101 10 running 10.0.186.1 server101.mydomain.com | |
− | Still another way of getting the Container status is checking the <code>/proc/vz/veinfo</code> file. This file lists all the Containers currently running on the Hardware Node. Each line presents a running Container in the '' | + | Still another way of getting the Container status is checking the <code>/proc/vz/veinfo</code> file. This file lists all the Containers currently running on the Hardware Node. Each line presents a running Container in the ''CT_ID reserved number_of_processes IP_address...'' format: |
# '''cat /proc/vz/veinfo''' | # '''cat /proc/vz/veinfo''' | ||
− | + | 101 0 10 10.0.186.1 | |
0 0 79 | 0 0 79 | ||
− | This output shows that Container 101 is running, there are | + | This output shows that Container 101 is running, there are 20 running processes inside the Container, and its IP address is 10.0.186.1. The second line corresponds to the Container with ID 0, which is the Hardware Node itself. |
The following command is used to stop a Container: | The following command is used to stop a Container: | ||
Line 221: | Line 223: | ||
Container start in progress... | Container start in progress... | ||
− | {{Note|You can also use Container names to start, stop, and restart the corresponding Containers. For detailed information on Container names, please turn to the [[#Setting Name for Container]] section. | + | {{Note|You can also use Container names to start, stop, and restart the corresponding Containers. For detailed information on Container names, please turn to the [[#Setting Name for Container]] section. |
== Listing Containers == | == Listing Containers == | ||
Line 240: | Line 242: | ||
103 200000 | 103 200000 | ||
− | This shows only running Containers with the information about their IDs and soft limit on disk inodes (see the {{ | + | This shows only running Containers with the information about their IDs and soft limit on disk inodes (see the {{Chapter link|Managing Resources}} chapter for more information), with the list sorted by this soft limit. The full list of the <code>vzlist</code> command line switches and output and sorting options is available in the {{man|vzlist|8}} man page. |
+ | FIXME | ||
== Setting Name for Container == | == Setting Name for Container == | ||
Line 343: | Line 346: | ||
# The Container on the Destination Node is started. | # 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. | 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. | ||
Line 358: | Line 360: | ||
{{Note|For the command to be successful, a direct SSH connection (on port 22) should be allowed between the Source and Destination Nodes.}} | {{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 === | === Zero-downtime (online) migration === | ||
Line 381: | Line 385: | ||
You can delete a Container that is not needed anymore with the <code>vzctl destroy ''CTID''</code> command. This command removes the Container private area completely and renames the Container configuration file and action scripts by appending the <code>.destroyed</code> suffix to them. | You can delete a Container that is not needed anymore with the <code>vzctl destroy ''CTID''</code> command. This command removes the Container private area completely and renames the Container configuration file and action scripts by appending the <code>.destroyed</code> suffix to them. | ||
− | {{Note|Since vzctl-3.0.24, you can also use the | + | {{Note|Since vzctl-3.0.24, you can also use the vzctl delete command introduced in Virtuozzo Containers 4.0 to remove Containers from your Hardware Node. This command has the syntax identical to vzctl destroy and is meant to replace the latter in the future.}} |
A running Container cannot be destroyed with the <code>vzctl destroy</code> command. The example below illustrates destroying Container 101: | A running Container cannot be destroyed with the <code>vzctl destroy</code> command. The example below illustrates destroying Container 101: | ||
− | + | # vzctl destroy 101 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Destroying Container private area: /vz/private/101 | |
− | + | Container is currently mounted (unmount first) | |
− | + | # vzctl stop 101 | |
− | + | Stopping Container ... | |
− | + | Container was stopped | |
− | + | Container is unmounted | |
− | + | # vzctl destroy 101 | |
− | + | Destroying Container private area: /vz/private/101 | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Container private area was destroyed | |
− | + | # ls /etc/vz/conf/101.* | |
− | + | /etc/vz/conf/101.conf.destroyed | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | # vzctl status 101 | |
− | + | VEID 101 deleted unmounted down | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | If you do not need the backup copy of the Container configuration files (with the .destroyed suffix), you may delete them manually. | ||
+ | == Disabling Container == | ||
+ | == Suspending Container == | ||
== Running Commands in Container == | == Running Commands in Container == | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<noinclude>{{UG/Footer}}</noinclude> | <noinclude>{{UG/Footer}}</noinclude> |