6,534
edits
Changes
Enlarged →Resource Management
Resource management is much more important for OpenVZ than for a standalone computer since computer resource utilization in a OpenVZ-based system is considerably higher than that in a typical system.
As all the VEs are using the same kernel, resource management is of paramount importance. Really, each VE should stay within its boundaries and not affect other VEs in any way — and this is what resource management does.
OpenVZ resource management consists of three components: two-level disk quota, fair CPU scheduler, and user beancounters. Please note that all those resources can be changed during VE runtime, there is no need to reboot. Say, if you want to give your VE less memory, you just change the appropriate parameters on the fly. This is either very hard to do or not possible at all with other virtualization approaches such as VM or hypervisor.
====Two-Level Disk Quota====
Host system (OpenVZ) owner (root) can set up a per-VE [[disk quota]]s, in terms of disk blocks and i-nodes (roughly number of files). This is the first level of disk quota. In addition to that, a VE owner (root) can use usual quota tools inside own VE to set standard UNIX per-user and per-group [[disk quota]]s.
If you want to give your VE more disk space, you just increase its disk quota. No need to resize disk partitions etc.
====Fair CPU scheduler====
CPU scheduler in OpenVZ is a two-level implementation of [[fair-share scheduling]] strategy.
On the first level scheduler decides which VE is give the CPU time slice to, based on per-VE cpuunits values. On the second level the standard Linux scheduler decides which process to run in that VE, using standard Linux process priorities and such.
OpenVZ administrator can set up different values of cpuunits for different VEs, and the CPU time will be given to those proportionally.
Also there is a way to limit CPU time, e.g. say that this VE is limited to, say, 10% of CPU time available.
====User Beancounters====
User Beancounters is a set of per-VE counters, limits, and guarantees. There is a set of about 20 parameters which are carefully chosen to cover all the aspects of VE operation, so no single VE can abuse any resource which is limited for the whole node and thus do harm to another VEs.
Resources accounted and controlled are mainly memory and various in-kernel objects such as IPC shared memory segments, network buffers etc. etc. Each resource can be seen from <tt>/proc/user_beancounters</tt> and has five values assiciated with it: current usage, maximum usage (for the lifetime of a VE), barrier, limit, and fail counter. The meaning of barrier and limit is parameter-dependant; in short, those can be thought of as a soft limit and a hard limit. If any resource hits the limit, fail counter for it is increased, so VE owner can see if something bad is happening by analyzing the output of <tt>/proc/user_beancounters</tt> in her VE.
== Checkpointing and live migration ==
FIXME