Changes

Jump to: navigation, search

User Guide/Managing Resources

2,253 bytes added, 15:29, 29 May 2009
Validating Container Configuration: added manual/automatic adj
=== Disk Quota Parameters ===
The table below summarizes the disk quota parameters that you can control. The '''File ''' column indicates whether the parameter is defined in the OpenVZ global configuration file (G), in the CT configuration files (V), or it is defined in the global configuration file but can be overridden in a separate CT configuration file (GV). 
{| class="wikitable"
! Parameter !! Description !! File
=== Setting Up Per-CT Disk Quota Parameters ===
Three parameters determine how much disk space and inodes a Container can use. These parameters are specified in the Container configuration file:
{| class="wikitable"| ; DISKSPACE| : Total size of disk space that can be consumed by the Container in 1-Kb blocks. When the space used by the Container hits the soft limit, the CT can allocate additional disk space up to the hard limit during the grace period specified by the QUOTATIME parameter.|-| ; DISKINODES| : Total number of disk inodes (files, directories, and symbolic links) the Container can allocate. When the number of inodes used by the Container hits the soft limit, the CT can create additional file entries up to the hard limit during the grace period specified by the QUOTATIME parameter.|-| ; QUOTATIME| : The grace period of the disk quota specified in seconds. The Container is allowed to temporarily exceed the soft limit values for the disk space and disk inodes quotas for no more than the period specified by this parameter.|}
The first two parameters have both soft and hard limits (or, simply, barriers and limits). The hard limit is the limit that cannot be exceeded under any circumstances. The soft limit can be exceeded up to the hard limit, but as soon as the grace period expires, the additional disk space or inodes allocations will fail. Barriers and limits are separated by colons (“:”) in Container configuration files and in the command line.
# Second-level (per-user and per-group) disk quotas are enabled for the given Container;
 
# The value that you assign to this parameter will be the limit for the number of file owners and groups of this Container, including Linux system users. Note that you will theoretically be able to create extra users of this Container, but if the number of file owners inside the Container has already reached the limit, these users will not be able to own files.
Unable to apply new quota values: ugid quota not initialized
Saved parameters for CT 101
# '''vzctl stop 101; vzctl start restart 101''' Restarting container Stopping CT container ... CT Container was stopped CT Container is unmounted Starting CT container ... CT Container is mounted Adding IP address(es): 192.168.116.101123 Setting CPU units: 1000 Hostname for CT setConfigure meminfo: vps10165536 File resolv.my.orgconf was modified CT Container start in progress...
=== Setting Up Second-Level Disk Quota Parameters ===
Any CT is configured by means of its own configuration file. You can manage your CT configurations in a number of ways:
<ol>
<li>Using configuration sample files shipped with OpenVZ. These files are used when a new Container is being created (for details, see the [[#Creating and Configuring New Container]] section). They are stored in (<code>/etc/vz/conf/</code> and have the <code>ve‑''name''.conf-sample</code> mask. Currently, the following configuration sample files are provided:
* light – to be used for creating “light” CTs having restrictions on the upper limit of quality of service parameters;
* vps.basic – to be used for common CTs.
{{Note|Configuration sample files cannot contain spaces in their names.}}
Config /etc/vz/conf/ve-vps.mytest.conf-sample was created
# '''vzcfgvalidate /etc/vz/conf/ve-vps.mytest.conf-sample'''
Recommendation: kmemsize.lim-kmemsize.bar should be > 253952 \ (currently, 126391)
Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 93622)
The number of Containers you can run on the Hardware Node is actually several times greater than the value specified in the command line because Containers normally do not consume all the resources that are guaranteed to them. To illustrate this idea, let us look at the Container created from the configuration produced above:
# '''vzctl create 101 --ostemplate fedoracentos-core-4 5 --config vps.mytest'''
Creating CT private area: /vz/private/101
CT private area was created
=== Validating Container Configuration ===
The system resource control parameters have complex interdependencies. Violation of these interdependencies can be catastrophic for the Container. In order to ensure that a Container does not break them, it is important to validate the CT configuration file before creating CTs on its basis.
The typical validation scenario Here is shown belowhow to validate a CT configuration:
# '''vzcfgvalidate /etc/vz/conf/101.conf'''
Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536)
Recommendation: othersockbuf.bar should be > 132096 (currently, 122880)
# '''vzctl set 101 --kmemsize 2211840:2359296 --save'''
Saved parameters for CT 101
# '''vzcfgvalidate /etc/vz/conf/101.conf'''
Recommendation: kmemsize.lim-kmemsize.bar should be > 163840 (currently, 147456)
Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536)
Recommendation: othersockbuf.bar should ba > 132096 (currently, 122880)
Validation completed: success
The utility checks constraints on the resource management parameters and displays all the constraint violations found. There can be three levels of violation severity:
|}
==== Manual adjustment ==== To fix errors or warnings reported by <code>vzcfgvalidate</code>, adjust the parameters accordingly and re-run the <code>vzcfgvalidate</code>.  # '''vzctl set 101 --kmemsize 2211840:2359296 --save''' Saved parameters for CT 101 # '''vzcfgvalidate /etc/vz/conf/101.conf''' Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536) Recommendation: othersockbuf.bar should ba > 132096 (currently, 122880)t Validation completed: success In the scenario above, the first run of the <code>vzcfgvalidate </code> utility found a critical error for the <code>kmemsize </code> parameter value. After setting reasonable values for <code>kmemsize</code>, the resulting configuration produced only recommendations, and the Container can be safely run with this configuration. ==== Automatic adjustment ==== FIXME: vzcfgvalidate -r|-i === Applying New Configuration Sample to Container === The OpenVZ software enables you to change the configuration sample file a Container is based on and, thus, to modify all the resources the Container may consume and/or allocate at once. For example, if Container 101 is currently based on the <code>light</code> configuration sample and you are planning to run some more heavy-weight application inside the Container, you may wish to apply the <code>basic</code> sample to it instead of <code>light</code>, which will automatically adjust the necessary Container resource parameters. To this effect, you can execute the following command on the Node:  # '''vzctl set 101 --applyconfig basic --save''' Saved parameters for CT 101 This command reads the resource parameters from the <code>ve-basic.conf-sample</code> file located in the <code>/etc/vz/conf</code> directory and applies them one by one to Container 101. When applying new configuration samples to Containers, please keep in mind the following: * All Container sample files are located in the /etc/vz/conf directory on the Hardware Node and are named according to the following pattern: <code>ve-''name''.conf-sample</code>. You should specify only the <code>''name''</code> part of the corresponding sample name after the <code>--applyconfig</code> option (<code>basic</code> in the example above).* The <code>--applyconfig</code> option applies all the parameters from the specified sample file to the given Container, except for the <code>OSTEMPLATE</code>, <code>VE_ROOT</code>, <code>VE_PRIVATE</code>, <code>HOSTNAME</code>, <code>IP_ADDRESS</code>, <code>TEMPLATE</code>, <code>NETIF</code> parameters (if they exist in the sample file).* You may need to restart your Container depending on the fact whether the changes for the selected parameters can be set on the fly or not. If some parameters could not be configured on the fly, you will be presented with the corresponding message informing you of this fact. 
<noinclude>{{UG/Footer}}</noinclude>

Navigation menu