User Guide/Managing Resources - Revision history

Kir: /* Validating Container Configuration */ added manual/automatic adj

2009-05-29T15:29:24Z

‎Validating Container Configuration: added manual/automatic adj

Kir: + /* Applying New Configuration Sample to Container */

2009-04-28T12:35:26Z

+ ‎Applying New Configuration Sample to Container

Kir: /* Splitting Hardware Node Into Equal Pieces */ use centos-5 OS template

2009-04-28T12:22:12Z

‎Splitting Hardware Node Into Equal Pieces: use centos-5 OS template

Kir: /* Turning On and Off Second-Level Quotas for Container */ fix numbered list; use vzctl restart

2009-04-28T11:56:03Z

‎Turning On and Off Second-Level Quotas for Container: fix numbered list; use vzctl restart

Kir: /* Setting Up Per-CT Disk Quota Parameters */ use definition list for params

2009-04-28T11:53:26Z

‎Setting Up Per-CT Disk Quota Parameters: use definition list for params

Kir: /* Disk Quota Parameters */ formatting

2009-04-28T11:47:25Z

‎Disk Quota Parameters: formatting

Kir: /* Managing CT Resources Configuration */ fixed the path to configs

2009-04-27T16:20:44Z

‎Managing CT Resources Configuration: fixed the path to configs

Kir: /* Splitting Hardware Node Into Equal Pieces */ fix config file path

2009-04-27T16:19:02Z

‎Splitting Hardware Node Into Equal Pieces: fix config file path

Akaras: /* Splitting Hardware Node Into Equal Pieces */

2009-03-14T19:44:50Z

‎Splitting Hardware Node Into Equal Pieces

Kir: added header/footer

2009-01-16T10:22:29Z

added header/footer

@@ Line 572: / Line 572: @@
 === 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 is shown below:
   # '''vzcfgvalidate /etc/vz/conf/101.conf'''
@@ Line 578: / Line 579: @@
   Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 65536)
   Recommendation: othersockbuf.bar should be > 132096 (currently, 122880)
 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 598: / Line 592: @@
 |}
-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.
+==== Manual adjustment ====
 === Applying New Configuration Sample to Container ===

← Older revision		Revision as of 12:35, 28 April 2009
Line 599:		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 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.
		+
		+	=== 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>		<noinclude>{{UG/Footer}}</noinclude>

@@ Line 547: / Line 547: @@
   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 \
+  Recommendation: kmemsize.lim-kmemsize.bar should be > 253952 (currently, 126391)
   Recommendation: dgramrcvbuf.bar should be > 132096 (currently, 93622)
@@ Line 555: / Line 554: @@
 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 fedora-core-4 --config vps.mytest'''
+  # '''vzctl create 101 --ostemplate centos-5 --config vps.mytest'''
   Creating CT private area: /vz/private/101
   CT private area was created

@@ Line 144: / Line 144: @@
 # 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.
@@ Line 154: / Line 153: @@
   Unable to apply new quota values: ugid quota not initialized
   Saved parameters for CT 101
-  # '''vzctl stop 101; vzctl start 101'''
+  # '''vzctl restart 101'''
-  Stopping CT ...
+ Restarting container
-  CT was stopped
+  Stopping container ...
-  CT is unmounted
+  Container was stopped
-  Starting CT ...
+  Container is unmounted
-  CT is mounted
+  Starting container ...
-  Adding IP address(es): 192.168.1.101
+  Container is mounted
-  Hostname for CT set: vps101.my.org
+  Adding IP address(es): 192.168.16.123
-  CT start in progress...
+ Setting CPU units: 1000
 === Setting Up Second-Level Disk Quota Parameters ===

@@ Line 108: / Line 108: @@
 === 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
+; 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.
+: 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
-| 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.
-| 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.

@@ Line 43: / Line 43: @@
 === 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).
+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

@@ 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:
 <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/</code> and have the <code>ve‑''name''.conf-sample</code> mask. Currently, the following configuration sample files are provided:
+<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.
+* basic – to be used for common CTs.
 {{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:
-  # '''cd /etc/vz/'''
+  # '''cd /etc/vz/conf'''
   # '''vzsplit -n 20 -f vps.mytest'''
-  Config /etc/vz/ve-vps.mytest.conf-sample was created
+  Config /etc/vz/conf/ve-vps.mytest.conf-sample was created
-  # '''vzcfgvalidate /etc/vz/ve-vps.mytest.conf-sample'''
+  # '''vzcfgvalidate /etc/vz/conf/ve-vps.mytest.conf-sample'''
   Recommendation: kmemsize.lim-kmemsize.bar should be > 253952 \
   (currently, 126391)
@@ Line 561: / Line 561: @@
   Saved parameters for CT 101
   # '''vzctl start 101'''
-  Starting CT …
+  Starting CT ...
   CT is mounted
   Adding IP address(es): 192.168.1.101
-  CT start in progress…
+  CT start in progress...
   # '''vzcalc 101'''
   Resource     Current(%)  Promised(%)  Max(%)

← Older revision		Revision as of 10:22, 16 January 2009
Line 1:		Line 1:
		+	<noinclude>{{UG/Header}}</noinclude>
	The main goal of resource control in OpenVZ is to provide Service Level Management or Quality of Service (QoS) for Containers. Correctly configured resource control settings prevent serious impacts resulting from the resource over-usage (accidental or malicious) of any Container on the other Containers. Using resource control parameters for Quality of Service management also allows to enforce fairness of resource usage among Containers and better service quality for preferred CTs, if necessary.		The main goal of resource control in OpenVZ is to provide Service Level Management or Quality of Service (QoS) for Containers. Correctly configured resource control settings prevent serious impacts resulting from the resource over-usage (accidental or malicious) of any Container on the other Containers. Using resource control parameters for Quality of Service management also allows to enforce fairness of resource usage among Containers and better service quality for preferred CTs, if necessary.

Line 599:		Line 600:

	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 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.
		+	<noinclude>{{UG/Footer}}</noinclude>