Editing User Guide/Managing Resources
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 43: | Line 43: | ||
=== Disk Quota Parameters === | === Disk Quota Parameters === | ||
− | The table below summarizes the disk quota parameters that you can control. The | + | 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" | {| class="wikitable" | ||
! Parameter !! Description !! File | ! Parameter !! Description !! File | ||
Line 108: | Line 107: | ||
=== Setting Up Per-CT Disk Quota Parameters === | === 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: | 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. | 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. | ||
Line 144: | Line 146: | ||
# Second-level (per-user and per-group) disk quotas are enabled for the given Container; | # 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. | # 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. | ||
Line 153: | Line 156: | ||
Unable to apply new quota values: ugid quota not initialized | Unable to apply new quota values: ugid quota not initialized | ||
Saved parameters for CT 101 | Saved parameters for CT 101 | ||
− | # '''vzctl | + | # '''vzctl stop 101; vzctl start 101''' |
− | + | Stopping CT ... | |
− | Stopping | + | CT was stopped |
− | + | CT is unmounted | |
− | + | Starting CT ... | |
− | Starting | + | CT is mounted |
− | + | Adding IP address(es): 192.168.1.101 | |
− | Adding IP address(es): 192.168. | + | Hostname for CT set: vps101.my.org |
− | + | CT start in progress... | |
− | |||
− | |||
− | |||
=== Setting Up Second-Level Disk Quota Parameters === | === Setting Up Second-Level Disk Quota Parameters === | ||
Line 523: | Line 523: | ||
Any CT is configured by means of its own configuration file. You can manage your CT configurations in a number of ways: | Any CT is configured by means of its own configuration file. You can manage your CT configurations in a number of ways: | ||
<ol> | <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 | + | <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/</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; | * light – to be used for creating “light” CTs having restrictions on the upper limit of quality of service parameters; | ||
− | * basic – to be used for common CTs. | + | * vps.basic – to be used for common CTs. |
{{Note|Configuration sample files cannot contain spaces in their names.}} | {{Note|Configuration sample files cannot contain spaces in their names.}} | ||
Line 543: | Line 543: | ||
It is possible to create a Container configuration roughly representing a given fraction of the Hardware Node. If you want to create such a configuration that up to 20 fully loaded Containers would be able to be simultaneously running on the given Hardware Node, you can do it as is illustrated below: | It is possible to create a Container configuration roughly representing a given fraction of the Hardware Node. If you want to create such a configuration that up to 20 fully loaded Containers would be able to be simultaneously running on the given Hardware Node, you can do it as is illustrated below: | ||
− | # '''cd /etc/vz/ | + | # '''cd /etc/vz/''' |
# '''vzsplit -n 20 -f vps.mytest''' | # '''vzsplit -n 20 -f vps.mytest''' | ||
− | Config /etc/vz | + | Config /etc/vz/ve-vps.mytest.conf-sample was created |
− | # '''vzcfgvalidate /etc/vz | + | # '''vzcfgvalidate /etc/vz/ve-vps.mytest.conf-sample''' |
− | Recommendation: kmemsize.lim-kmemsize.bar should be > 253952 (currently, 126391) | + | Recommendation: kmemsize.lim-kmemsize.bar should be > 253952 \ |
+ | (currently, 126391) | ||
Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 93622) | Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 93622) | ||
Line 554: | Line 555: | ||
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: | 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 | + | # '''vzctl create 101 --ostemplate fedora-core-4 --config vps.mytest''' |
Creating CT private area: /vz/private/101 | Creating CT private area: /vz/private/101 | ||
CT private area was created | CT private area was created | ||
Line 560: | Line 561: | ||
Saved parameters for CT 101 | Saved parameters for CT 101 | ||
# '''vzctl start 101''' | # '''vzctl start 101''' | ||
− | Starting CT | + | Starting CT … |
CT is mounted | CT is mounted | ||
Adding IP address(es): 192.168.1.101 | Adding IP address(es): 192.168.1.101 | ||
− | CT start in | + | CT start in progress… |
# '''vzcalc 101''' | # '''vzcalc 101''' | ||
Resource Current(%) Promised(%) Max(%) | Resource Current(%) Promised(%) Max(%) | ||
Line 572: | Line 573: | ||
=== Validating Container Configuration === | === 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 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 is shown below: | |
− | |||
# '''vzcfgvalidate /etc/vz/conf/101.conf''' | # '''vzcfgvalidate /etc/vz/conf/101.conf''' | ||
Line 579: | Line 579: | ||
Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536) | Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536) | ||
Recommendation: othersockbuf.bar should be > 132096 (currently, 122880) | 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: | The utility checks constraints on the resource management parameters and displays all the constraint violations found. There can be three levels of violation severity: | ||
Line 592: | Line 599: | ||
|} | |} | ||
− | + | In the scenario above, the first run of the vzcfgvalidate utility found a critical error for the kmemsize parameter value. After setting reasonable values for kmemsize, the resulting configuration produced only recommendations, and the Container can be safely run with this configuration. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | In the scenario above, the first run of the | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
<noinclude>{{UG/Footer}}</noinclude> | <noinclude>{{UG/Footer}}</noinclude> |