![[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.
Ces fichiers liés, immutables, que l'ont peut toutefois détruire, et appartenant à plus d'un contexte sont appelés unifiés, et l'action qui consiste à les rechercher et les préparer s'appelle Unification.
Choississez l'unification si vous souhaitez réduire votre usage de ressources. L'inconvénient évident est une administration moins facile. Un Serveur Linux s'installe typiquement sur 500Mo de disque, et 10 serveurs unifiés en consommeront donc seulement 700Mo, et moins de mémoire pour les caches.
Voir Exemple [XX]
Ajoutés récemment dans Linux-VServer, les espaces de noms privés utilisent la couche VFS du noyau linux et offrent une vue différente du système de fichier pour chaque contexte.
Par rapport au schéma traditionnel, l'avantage principal apparait lorsqu'on modifie quelquechose dans un espace de nommage (par exemple, les points de montage); à cet instant, les autres contextes resteront intact, y compris biensur le contexte Hôte.
Désavantage évident d'une telle approche; entrer dans un tel espace de noms privé n'est pas aussi simple que d'entrer dans un chroot. Toutefois, les choses pourraient changer dans les noyaux futurs, si cette fonctionnalité est par exemple intégrée directement à la fonction chroot().
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.
Voir Exemple [XX]
Pour faire usage de cette fonctionnalité, le support pour les fichiers étiquetés XID doit être présent. Grace aux limites par contexte, vous pouvez alors régler une limite différente pour chaque contexte d'une partition partagée.
Chaque block et inode d'un système de fichier est comptabilisé, dès lors qu'un hachage XID a été ajouté à ce système de fichier dans ce contexte donné.
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.
Les opérations sur les Quotas (ioctls) nécessitent un accès aux périphériques de bloc. Ils ne sont donc pas disponible dans un VPS.
Pour certaines applications, par exemple la préparation d'un "pot de miel" (honey-pot), ou d'une imitation particulièrement réaliste d'un vrai serveur à des fins éducatives, vous aurez peut-être besoin de confondre le contexte du serveur hôte (réel) et celui de votre pot de miel.
Toutefois, certaines alternatives libres comme QEMU ou UML vous permettent de faire la même chose beaucoup mieux et avec moins d'efforts. Ce n'est donc pas une question centrale dans le développement de Linux-VServer.