Changes

Jump to: navigation, search

User Guide/Operations on Containers

5,490 bytes added, 20:53, 1 September 2015
fix man page link
Adding IP address(es): 10.0.186.1
Saved parameters for CT 1010101
# '''vzctl set 101 --nameserver 192.168.1.165 --save'''
File resolv.conf was modified
Saved parameters for CT 1010101
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'''
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.
# vzlist 101
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 ''<CT_ID > <reserved > <number_of_processes > <IP_address> ...'' format:
# '''cat /proc/vz/veinfo'''
101 101 0 10 10.0.186.1
0 0 79
This output shows that Container 101 is running, there are 20 10 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:
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.}}
== Listing Containers ==
103 200000
This shows only running Containers with the information about their IDs and soft limit on disk inodes (see the {{UG/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 ==
# The Container on the Destination Node is started.
'''WARNING: By default, after the migration process is completed, the Container private area and configuration file are deleted on the Source Node!''' However, if you wish the Container private area on the Source Node to not be removed after the successful Container migration, you can override the default <code>vzmigrate</code> behavior by using the <code>–r no</code> switch.
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|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 ===
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 <code>vzctl delete </code> 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:
# '''vzctl destroy 101''' Container is currently running. Stop it 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''' CTID 102 deleted unmounted down
Destroying If you do not need the backup copy of the Container private area: /vz/private/101configuration files (with the .destroyed suffix), you may delete them manually.
== Disabling Container is currently mounted (unmount first)==
# vzctl stop 101There may appear situations when you wish to forbid Container owners to use their Containers. For example, it may happen in case the Container owner uses it for unallowed purposes: intruding into computers of other users, participating in DoS attacks, etc.
Stopping In such cases, the OpenVZ software allows you to disable a Container , thus, making it impossible to start the Container once it was stopped...For example, you can execute the following command to disable Container 101 residing on your Hardware Node:
Container was stopped # '''vzctl set 101 --disabled yes --save'''
Container is unmounted{{Note|This option makes no sense without the <code>--save</code> flag, so you have to supply it.}}
# After the Container stopping, the Container user will not be able to start it again until you enable this Container again by passing the <code>--disabled no</code> option to <code>vzctl destroy 101set</code>. You can also use the <code>--force</code> option to start any disabled Container. For example:
Destroying # '''vzctl start 103''' Container private areastart disabled # '''vzctl start 103 --force''' Starting container ... Container is mounted Adding IP address(es): /vz/private/101192.168.16.3 Setting CPU units: 1000 Configure meminfo: 65536 Container start in progress... == Suspending Container ==
OpenVZ allows you to suspend any running Container on the Hardware Node by saving its current state to a special dump file. Later on, you can resume the Container and get it in the same state the Container private area was destroyedat the time of its suspending.
# ls /etc/vz/confIn OpenVZ-based systems, you can use the <code>vzctl chkpnt</code> command to save the current state of a Container. For example, you can issue the following command to suspend Container 101.*:
/etc/vz/conf/ # vzctl chkpnt 101 Setting up checkpoint.conf.destroyed. suspend... dump... kill... Container is unmounted Checkpointing completed succesfully
# vzctl status During the command execution, the <code>/vz/dump/Dump.101</code> file containing the entire state of Container 101 is created and the Container itself is stopped.
VEID Note: You can set another directory to store dump files for your Containers by changing the value of the DUMPDIR parameter in the OpenVZ global file. Detailed information on the OpenVZ global file and the parameters you can specify in it is provided in the {{man|vz.conf|5}}. At any time, you can resume Container 101 deleted unmounted downby executing the following command:  # vzctl restore 101 Restoring container ... Starting container ... Container is mounted undump... Adding IP address(es): 192.168.16.3 Setting CPU units: 1000 Configure meminfo: 65536 resume... Container start in progress... Restoring completed succesfully The Container state is restored from the <code>/vz/dump/Dump.101</code> file on the Node. Upon the restoration completion, any applications that were running inside Container 101 at the time of its suspending will be running and the information content will be the same as it was when the Container was suspended. While working with dump files, please keep in mind the following: * You can restore the Container dump file on the Source Node, i.e. on the Node where this Container was running before its dumping, or transfer the dump file to another Node and restore it there.: {{Note|Before restoring a Container from its dump file, please make sure that the file system on the Destination Node is identical to that at the moment of the Container dumping; otherwise, the Container restoration may fail.}}* You cannot change settings of the suspended Container.
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 ==
 
Usually, a Container administrator logs in to the Container via network and executes any commands in the Container as on any other Linux box. However, you might need to execute commands inside Containers bypassing the normal login sequence. This can be helpful if:
 
* You do not know the Container login information, and you need to run some diagnosis commands inside the Container in order to verify that it is operational.
* Network access is absent for a Container. For example, the Container administrator might have accidentally applied incorrect firewalling rules or stopped the SSH daemon.
 
The OpenVZ software allows you to execute commands in a Container in these cases. Use the <code>vzctl exec</code> command for running a command inside the Container with the given ID. The session below illustrates the situation when the SSH daemon is not started:
 
# '''vzctl exec 103 /etc/init.d/sshd status'''
openssh-daemon is stopped
# '''vzctl exec 103 /etc/init.d/sshd start'''
Starting sshd: [ OK ]
# '''vzctl exec 103 /etc/init.d/sshd status'''
openssh-daemon (pid 9899) is running...
 
Now Container users can log in to the Container via SSH (assuming that networking and firewall are not misconfigured).
 
When executing commands inside a Container from shell scripts, use the <code>vzctl exec2</code> command. It has the same syntax as <code>vzctl exec</code> but returns the exit code of the command being executed instead of the exit code of <code>vzctl</code> itself. You can check the exit code to find out whether the command has completed successfully.
 
If you wish to execute a command in all running Containers, you can use the following script:
 
# '''for CT in $(vzlist -H -o ctid); do echo "== CT $CT =="; vzctl exec $CT ''command''; done'''
 
where ''<code>command</code>'' is the command to be executed in all the running Containers. For example:
 
# '''for CT in $(vzlist -H -o ctid); do echo "== CT $CT =="; vzctl exec $CT uptime; done'''
== CT 103 ==
15:17:19 up 13 min, 0 users, load average: 0.00, 0.00, 0.00
== CT 123123123 ==
15:17:19 up 22:00, 0 users, load average: 0.00, 0.00, 0.00
<noinclude>{{UG/Footer}}</noinclude>

Navigation menu