![[Home]](http://wiki.linux-vserver.org/skins/common/images/wiki.png)
We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.
L'un des objectifs centraux de Linux-VServer est de réduire l'utilisation des ressources partout ou cela est possible. Une excellente idée a donc germé, celle de partager des fichiers à travers les différents contextes sans interférer avec les taches administratives classiques ou diminuer le niveau de sécurité.
Les fichiers communs à plusieurs contextes, peu sujet à être modifiés, comme les bibliothèques ou les binaires, peuvent être soudés via un lien dur sur un système de fichier partagé, réduisant d'autant le besoin en espace disque, cache d'inodes, et surtout, l'occupation mémoire, via l'utilisation des bibliothèques partagées.
Seul inconvénient, si nous ne prenons pas quelques mesures supplémentaires, un contexte malicieux sera en mesure, par accident ou volontairement, de détruire ou modifier un tel fichier partagé, ce qui aurait des conséquences directes sur les autres contextes.
La première étape consiste à placer sur les fichiers partagés un drapeau Immutable (et enlever la caps qui permet de modifier un tel fichier). Il faut toutefois ajouter un attribut supplémentaire à ces fichiers partagés, pour permettre leur suppréssion, lors, par exemple, d'une mise à jour des bibliothèques dans un l'un des contextes.
Such hard linked, immutable but unlink-able files belonging to more than one context are called unified and the process of finding common files and preparing them in this way is called Unification.
The reason for doing this is reduced resource consumption, not simplified administration. While a typical Linux Server install will consume about 500MB of disk space, 10 unified servers will only need about 700MB and as a bonus use less memory for caching.
See Example [XX]
A recent addition to the Linux-VServer branch was the introduction of Private Namespaces. This uses the already existing Virtual Filesystem Layer of the Linux kernel to create a separate view of the filesystem for the processes belonging to a context.
The major advantage over the shared namespace used by default is that any modifications to the namespace layout (like mounts) do not affect other contexts, not even the Host Context.
Obviously the drawback of that approach is that entering such a Private Namespace isn't as trivial as changing the root directory, but with proper kernel support this will completely replace the chroot() in the future.
A structured, dynamically generated subtree of the well-known Proc-FS - actually two of them - has been created to allow for inspecting the different values of Security and Network Contexts.
/proc/virtual
.../info
/proc/virtual/<pid>
.../info
.../status
.../sched
.../cvirt
.../cacct
.../limit
While the basic idea of Linux-VServer is a peaceful coexistence of all contexts, sharing the common resources in a respectful way, it is sometimes useful to control the resource distribution for resource hungry processes.
The basic principle of a Token Bucket is not very new. It is given here as an example for the Hard CPU Limit. The same principle also applies to scheduler priorities, network bandwidth limitation and resource control in general.
The Hard CPU Limit uses this mechanism in the following way: consider a bucket of a certain size S which is filled with a specified amount of tokens R every interval T, until the bucket is "full" - excess tokens are spilled. At each timer tick, a running process consumes exactly one token from the bucket, unless the bucket is empty, in which case the process is put on a hold queue until the bucket has been refilled with a minimum M of tokens. The process is then rescheduled.
A major advantage of a Token Bucket is that a certain amount of tokens can be accumulated in times of quiescence, which later can be used to burst when resources are required.
Where a per-process Token Bucket would allow for a CPU resource limitation of a single process, a Context Token Bucket allows to control the CPU usage of all confined processes.
Another approach, which is also implemented, is to use the current fill level of the bucket to adjust the process priority, thus reducing the priority of processes belonging to excessive contexts.
See Example [XX]
This Feature requires the use of XID Tagged Files, and allows for independent Disk Limits for different contexts on a shared partition.
The number of inodes and blocks for each filesystem is accounted, if an XID-Hash was added for the Context-Filesystem combo.
Those values, including current usage, maximum and reserved space, will be shown for filesystem queries, creating the illusion that the shared filesystem has a different usage and size, for each context.
Similar to the Context Disk Limits, Per-Context Quota uses separate quota hashes for different Contexts on a shared filesystem. This is not required to allow for Linux-VServer quota on separate partitions.
Quota operations (ioctls) require some access to the block device, which for security reasons is not available inside a VPS.
For some applications, for example the preparation of a honey-pot or an especially realistic imitation of a real server for educational purposes, it can make sense to make the context indistinguishable from a real server.
However, since other freely available alternatives like QEMU or UML are much better at this, and require much less effort, this is not a central issue in Linux-VServer development.