Pour résumer de manière plus concrète, un serveur virtuel est en fait une entité qui tourne sur une machine hôte. Il peut exister grâce à divers procédés, appelés techniques de virtualisation, ce sont ces procédés qui déterminent en grande partie ses performances en tant que serveur. Pour différencier la machine du serveur virtuel, on a coutume d'appeler la machine qui supporte tous les VServers l'hôte et les VServers les guests. 
Comment faire en sorte qu'un hôte ait la capacité de faire tourner plusieurs serveurs virtuels ? Comme dit précédemment, il existe des techniques permettant d'émuler un serveur virtuel. Ce sont les techniques de virtualisation.
Techniques de virtualisation.
D'elles dépendent en grande partie les performances des serveurs virtuel, elles constituent aussi les principales différences entre les solutions existantes sur le marché et qui permettent de gérer des serveurs virtuels.
La virtualisation peut intervenir sur différents niveaux, et c'est là toute la différence avec d'autres systèmes de virtualisation tels que Xen, UML ou OPENVZ.
Il s'agit d'un partitionnement logique, ou serveur virtuel. Dans ce cas, il n'y a plus aucune émulation. C'est le noyau du système d'exploitation qui fait une isolation entre des machines logiques, tout comme il isole déjà les processus entre eux. Des exemples existent au moins sur FreeBSD (jails) et Solaris 10 (zones). Sous Linux, le projet Linux-VServer représente cette catégorie.
= Linux Vserver =
Introduction.
Cette technologie open source est assez récente sous Linux. La version 0.0 date d'octobre 2001. Jacques Gélinas, canadien à l'origine de plusieurs projets bien connus sous Linux (linuxconf, umsdos) a démarré le projet. Cette solution est spécifique à Linux, mais non liée à la plateforme IA-32. Le développement des versions s'est ralenti fin 2002. De nombreuses modifications ont alors fait leur apparition, et le projet s'est transformé en un projet communautaire. Le leader de ce projet est devenu Herbert Poetzl à partir d'octobre 2003. Depuis ce moment de nombreuses évolutions ont vu le jour. La version 1.0 est sortie le 1er novembre 2003, suivie de la version 1.2 le 5 décembre 2003. Cette branche est toujours active pour le noyau Linux 2.4 (version 1.2.10 pour noyau 2.4.29). La version 2.0 est sortie le 7 août 2005 pour le noyau 2.6.12. Cette version apporte de nombreux perfectionnements.
Fonctionnement.
Il s'agit d'une modification du noyau Linux (sous la forme d'un patch, le code n'étant pas actuellement intégré dans le noyau officiel). Ce patch est accompagné d'utilitaires pour configurer le système. Debian intègre depuis la version Sarge les utilitaires de gestion des VServers. L'intégration est donc assez simple. Concrètement, un VServer fonctionne par un système de contexte supplémentaire ajouté à chaque processus. C'est un système de virtualisation léger et peu intrusif. 
La machine physique démarre le noyau Linux. Tous les processus lancés par ce noyau (à partir d'init) le sont avec un contexte 0, celui dédié à la machine hôte. Jusque là, tout se comporte strictement comme d'habitude. 
Le lancement d'un VServer se fait via la commande VServer nom_du_VServer start . Cette commande va lire un fichier de configuration correspondant au serveur virtuel à démarrer. Elle crée un contexte (un numéro dit xid), qui est unique à la machine physique. Ensuite, le processus change de racine (chroot). Les adresses IPv4 du VServer sont créées en tant qu'adresses secondaires de l'interface réseau de la machine physique, puis liées au contexte actuel par des règles de routage internes au noyau Linux. Ensuite la commande VServer se remplace par un processus unique (le programme init , qui est le processus standard de démarrage des UNIX). Ainsi démarre le serveur virtuel. 
Tous les processus ensuite démarrés par init sont dans le même contexte, et héritent de ses caractéristiques. Le contexte s'applique donc aux processus et aux adresses IP, qui sont ainsi isolés de tout ce qui n'appartient pas au contexte local. Ce sont les seuls éléments virtualisés. Il n'y a pas de virtualisation des couches réseaux ou de stockage. Le VServer se base sur la gestion de “"capabilities"” du noyau Linux, qui permet de descendre les privilèges d'une tâche (et des tâches héritées), et de limiter les appels systèmes possibles. Et ainsi sécuriser l'ensemble.
À l'intérieur d'un VServer, il est par exemple impossible de manipuler les adresses IP de l'interface, de manipuler iptables , ou encore d'utiliser mknod. Comme un VServer hérite d'une tâche unique, il est possible au lancement du serveur virtuel, de le limiter en nombre de processus, de lui donner une priorité (nice)... Cela est implémenté en interne via la commande ulimit. Il est facile de voir l'état des serveurs sur la machine hôte via la commande VServer-stat 
La version 2.0 des VServers (disponible sur noyau 2.6 uniquement) permet de limiter plus nettement les ressources entre VServers au niveau du noyau, par exemple l'utilisation processeur (système de seau à jeton). 
Le pseudo système de fichiers /proc est monté dans les VServers mais masque toutes les entrées hors contexte, évitant ainsi des problèmes de sécurité possibles. 
Le pseudo système de fichiers /sys n'est par contre pas monté. Il n'est disponible que sur le serveur hôte. La principale limite est qu'il est impossible d'héberger un système autre que Linux puisque le noyau est partagé entre serveur hôte et ses VServers. 
Les processus d'un VServer ne sont que des processus standards, juste isolés et bridés sur les appels systèmes qu'ils peuvent utiliser. Les disques ainsi que la mémoire sont également partagés, ce qui permet une forte montée en charge, mais peut aussi compromettre la stabilité de l'intégralité du système, si on n'y prend garde. 
La racine d'un VServer se trouve dans un sous-répertoire du serveur maître 
/var/lib/VServers/nom_du_VServer.
Pour éviter tout débordement et tout effet de bord, il est souhaitable d'utiliser une partition dédiée pour chaque VServer (voire plusieurs). De cette façon, un VServer ne peut saturer le disque du serveur hôte. 
La création de nouveaux VServers peut se faire via une commande VServer build , qui est capable de gérer un certain nombre de distributions, dont DEBIAN (utilisation de la commande deboostrap pour installer un système de base DEBIAN). Quelques corrections sont ensuite apportées au serveur fraîchement installé (essentiellement un /dev quasiment vide), afin de fonctionner au mieux dans un VServer. 
Une fois cette commande terminée, un VServer de base est installé. Il peut être sauvegardé pour ensuite servir de patron (sous la forme d'un fichier tar.gz, qu'il suffit de décompresser ensuite, au besoin). Cela permet des déploiements « minute ». 
Pour information, un serveur Debian Sarge de base « pèse » environ 180 Mo. Puisque l'objectif est de n'avoir qu'un seul service par serveur virtuel, de très nombreux VServers ne nécessitent réellement jamais plus de 1 à 2 Go de disque. Il est possible d'utiliser des distributions Linux différentes, serveur hôte DEBIAN et VServer Fedora, par exemple. En effet, les librairies ne sont pas partagées, chaque VServer aura son propre jeu de librairies.
Particularité.
C'est la performance qui rend les VServers si attractifs. Puisqu'il ne s'agit pas d'un PC virtuel, mais plutôt de "serveurs Linux" virtuels. Cela peut simplement être vu comme un chroot amélioré. Les avantages sont des performances natives (pas de perte mesurable). À part la gestion du contexte, un processus dans un VServer a les mêmes caractéristiques qu'un processus d'une machine Linux standard. La consommation mémoire est légère (la mémoire est mutualisée entre le serveur hôte et les VServers et la mémoire demandée à l'hôte est celle réellement utilisée par les processus du VServer). La possibilité de mutualisation est donc ici très importante ; il est possible de déployer plusieurs dizaines de VServers sur un serveur actuel correctement taillé.
Sécurité.
De par les restrictions des appels systèmes que peut utiliser un VServer, un processus en son sein a moins de possibilités que celui d'un serveur standard. S'il y a intrusion dans un VServer, par une faille de sécurité d'un logiciel quelconque, le pirate ne pourra pas écouter les interfaces réseau, ou lancer des commandes comme nmap. 
Seul l'hôte a la possibilité de manipuler iptables. Les règles sont très restrictives, et correspondent strictement aux services déployés sur le VServer. Ceux-ci ne peuvent initier des connexions, hors celles nécessaires pour assurer le service. Ainsi un pirate, même root sur un VServer, restera enfermé car il ne pourra pas lancer de connexions vers l'extérieur. 
Un démon ssh installé sur un port non standard verra ses paquets refusés par le firewall de l'hôte. Il n'est pas possible d'accéder aux disques physiques de la machine (il est par contre possible d'effacer le volume du serveur virtuel).
Un risque est constitué par l'escalade de privilège d'un VServer vers le serveur hôte. En effet, les VServers sont basés sur une couche de virtualisation logique assez fine. Par le passé, elle a été contournée une fois. Cet unique bug a été rapidement corrigé (chroot barrier), mais prouve que le concept n'est pas à l'épreuve des balles. Si l'escalade arrive jusqu'à l'hôte, en tant que root (ou si l'hôte fait tourner des services exploitables), alors la sécurité est mise à mal, puisque le serveur hôte a une vision complète de tous les fichiers des VServers, et peut accéder à chacun des processus de ceux-ci, ainsi que de s'y authentifier en tant que root... Il ne s'agit plus cette fois d'un seul serveur piraté, mais de la totalité des VServers hébergés sur cet hôte. Il n'y a cependant actuellement pas de faille de ce type connue.
Enfin, un seul noyau est partagé entre l'hôte et les VServers. Si un bug noyau existe, il peut être utilisé dans ou via un VServer, et provoquer un déni de service pour la machine hôte – et par ricochet – celui des autre VServers hébergés. Cela amène à un autre risque, qui est celui de la panne matérielle ; si la machine est en panne, ce sont tous ses VServers qui le sont. Déployer un VServer est dangereux si des services redondants ne sont pas prévus. 
Les précautions conseillées sont les suivantes : Tous les service importants déployés sur des VServers sont redondés. Les VServers co-hébergés sur une même machine hôte sont, autant que possible, avec des catégories d'usage et des contraintes de sécurité proches. Et bien sûr, la règle primordiale est de ne faire tourner AUCUN service sur l'hôte à part SSH et les iptables.
Limitations.
Chaque médaille a son revers... Vserver a l'inconvénient de ses avantages, c'est à dire sa légèreté. Dans un grand nombre de cas, son fonctionnement est tout à fait satisfaisant. Cependant, le noyau est partagé par toutes les instances de serveurs, et tous les drivers et couches de communication ne sont pas virtualisés ; les conséquences sont multiples : 
Certains programmes nécessitant des privilèges élevés, ou manipulant directement le matériel ne pourront fonctionner correctement. Par exemple, le déploiement d'un serveur NFS kernel ne peut se faire qu'au niveau de l'hôte principal. Pas plus que démarrer un serveur X window n'est possible simplement... Dans un hôte il est possible de démarrer un démon NFS en privilège utilisateur5, mais les performances sont moins bonnes.
La mutualisation de la couche réseau peut aussi entraîner des problèmes de routage complexes (un cas est exposé en annexe) et empêche IPv6 de fonctionner. 
Dans les déploiements envisagés, certaines de ces limitations sont gênantes. Il a donc été considéré que pour certaines applications, un système de virtualisation plus complet devait être déployé.
Mise en Œuvre.
Introduction.
Pour mettre en place la solution Linux Vserver, il nous faut d'abord rendre une machine hôte capable de faire tourner plusieurs VServers. Nous allons donc détailler la préparation de l'hôte, de la mise en place du patch au statut opérationnel de la machine.
Préparation du noyau.
On commence par la préparation du kernel. Nous travaillons avec une Debian Sarge.
Première étape : mettre à jour la base de données d'apt avant l'installation et mettre à jour les packages installés.
 > apt-get update && apt-get upgrade
Seconde étape, il nous faut plusieurs outils, qui sont les suivants :
 > apt-get install util-VServer ssh ncurses-base libncurses5-dev
On se retrouve avec les fichiers suivants :
Le noyau (kernel).
Nous allons maintenant nous attaquer à la partie noyau. Tout d'abord rapatrier le dernier noyau Debian stable compatible VServer (2.6.12.4) via la commande suivante :
 > cd /usr/src
 > wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.4.tar.gz
Ensuite, le dernier patch stable de http://linux-VServer.org ou de www.13thfloor.at
 > wget http://www.13thfloor.at/VServer/s_rel26/v2.0/patch-2.6.12.4-vs2.0.diff.gz<br />
 > gzip -d linux-2.6.12.4.tar.gz <br />
 > tar -xvf linux-2.6.12.4.tar<br />
 > gzip -d patch-2.6.12.4-vs2.0.diff.gz<br />
 > mv patch-2.6.12.4-vs2.0.diff /usr/src/linux-2.6.12.4<br />
Patcher le noyau.
 > cd /usr/src/linux-2.6.12.4
 > cat patch-2.6.12.4-vs2.0.diff | patch -p1
Si vous êtes déjà sous une version similaire du noyau (2.6.x), il est préférable de copier la configuration actuelle avant de compiler le noyau. Votre configuration devrait se trouver vers "/boot/config-2.6.x"
 > cp /boot/config-2.6.X /usr/src/linux-2.6.12.4/.config
C'est parti. Vous devez d'abord inclure quelques choses pendant la compilation. Première chose, vous devez être en mesure de compiler sous votre système... Je conseille http://www.howtoforge.com/forums/showthread.php?t=21 si vous n'êtes pas très à l'aise avec cette histoire de compilation.
 > make menuconfig
Vous pouvez voir une catégorie pour «Linux VServer ». Si elles ne sont pas sélectionnées, activez
La configuration est prête. Il ne reste plus qu'à compiler le kernel :
 > make
 > make modules_install
 > cp .config /boot/config-2.6.12.4-vs2.0
 > cp System.map /boot/System.map-2.6.12.4-vs2.0
 > cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.12.4-vs2.0
 > mkinitrd -o /boot/initrd.img-2.6.12.4-vs2.0 2.6.12.4-vs2.0
Il faut mettre à jour le menu grub. Éditez (pico, nano, vi...) le fichier /boot/grub/menu.lst et ajoutez les lignes suivantes avant les autres entrées. Assurez vous que la ligne "default" est mise à 0
 title Vanilla 2.6.12.4-vs2.0
 root (hd0,0)
 kernel /vmlinuz-2.6.12.4-vs2.0 root=/dev/hda2 ro
 initrd /initrd.img-2.6.12.4-vs2.0
 savedefault
 boot
"Note" : Sous debian update-grub fait tout le boulot de modification du fichier /boot/grub/menu.lst automatiquement à partir du moment où le noyau est présent dans /boot
L'hôte est prêt. Il ne reste plus qu'à redémarrer pour avoir notre noyau prêt pour supporter VServer.
 > reboot
 > uname -r
 2.6.12.4-vs2.0
C'est le bon kernel !
Créer un serveur virtuel.
La création d'un serveur virtuel Debian sur un hôte Debian est simple. Voici la syntaxe de la commande :
 > VServer <VSERVER_NAME> build
 -n <VSERVER_NAME>
 --hostname <FQDN>
 --interface <NET_DEVICE>:<IP>/<CIDR>
 -m debootstrap -- -d <DEBIAN_DISTRO>
Ici, notre VServer a les informations suivantes :
 VSERVER_NAME viu
 FQDN viu.bux.com
 NET_DEVICE eth0
 IP 192.168.1.50
 CIDR 24 (255.255.255.0)
 DEBIAN_DISTRO sarge
On aura donc :
 > VServer viu build 
 -n viu
 --hostname viu.bux.com
 --interface eth0:192.168.1.50/24
 -m debootstrap -- -d sarge
On obtient
> ls -lah /var/lib/VServers/viu
total 80K
drwxr-xr-x 20 root root 4.0K Nov 10 08:17 .
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 ..
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 bin
drwxr-xr-x 2 root root 4.0K Dec 15 2004 boot
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 dev
drwxr-xr-x 37 root root 4.0K Nov 10 08:17 etc
drwxrwsr-x 2 root staff 4.0K Dec 15 2004 home
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 initrd
drwxr-xr-x 7 root root 4.0K Nov 10 08:17 lib
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 media
drwxr-xr-x 2 root root 4.0K Dec 15 2004 mnt
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 opt
drwxr-xr-x 2 root root 4.0K Dec 15 2004 proc
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 root
drwxr-xr-x 2 root root 4.0K Nov 10 08:17 sbin
drwxr-xr-x 2 root root 4.0K Nov 10 08:16 srv
drwxr-xr-x 2 root root 4.0K May 10 2005 sys
drwxrwxrwt 2 root root 4.0K Nov 10 08:17 tmp
drwxr-xr-x 11 root root 4.0K Nov 10 08:16 usr
drwxr-xr-x 13 root root 4.0K Nov 10 08:16 var
> ls -lah /etc/VServers/viu
total 28K
drwxr-xr-x 5 root root 4.0K Nov 10 08:13 .
drwxr-xr-x 6 root root 4.0K Nov 10 08:13 ..
drwxr-xr-x 4 root root 4.0K Nov 10 08:13 apps
-rw-r--r-- 1 root root 112 Nov 10 08:13 fstab
drwxr-xr-x 3 root root 4.0K Nov 10 08:13 interfaces
-rw-r--r-- 1 root root 5 Nov 10 08:13 name
lrwxrwxrwx 1 root root 22 Nov 10 08:13 run -> /var/run/VServers/viu
drwxr-xr-x 2 root root 4.0K Nov 10 08:13 uts
lrwxrwxrwx 1 root root 37 Nov 10 08:13 vdir -> /etc/VServers/.defaults/vdirbase/viu
Astuce : Notez que si vous omettez la ligne –interface, tout n'est pas perdu, il suffit juste, ultérieurement, de rajouter à la main le répertoire /etc/VServers/viu/interfaces/ et d'y stocker 
Si vous n'arrivez toujours pas à pinguer, mettez tout dans le sous répertoire /etc/VServers/viu/interfaces/0/. Selon la distribution, le répertoire .../0/ est le seul considéré ou complètement ignoré.
Maintenant que notre VServer est créé, expérimentons un peu les commandes. La syntaxe pour la commande VServer est la suivante :
 > VServer <VSERVER_NAME> [ start | stop | restart | enter ] 
Donc pour notre viu :
> VServer viu start
Starting system log daemon: syslogd.
Starting kernel log daemon: klogd.
Starting MTA: exim4.
Starting internet superserver: inetd.
Starting deferred execution scheduler: atd.
Starting periodic command scheduler: cron.
> VServer-stat
CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME
0 35 73.4M 5.4K 0m05s21 0m02s33 1m13s00 root server
49152 5 11M 967 0m00s00 0m00s00 0m30s52 viu
> VServer viu enter
viu:/# 
On est dans le contexte de viu. Pour sortir de ce contexte et revenir à l'hôte, il faut juste taper "exit". 
Paramétrage du Vserver.
Maintenant que nous avons notre VServer, il faut pouvoir le brider, c'est à dire limiter ses ressources, son espace disque, sa charge CPU ...
Vserver permet le paramétrage via des fichiers textes, avec tout un ensemble de restrictions/permissions sous forme de flags, de bcap, de ccap, ... Voici un rapide aperçu des fichiers et leur utilisation. Nous nous attarderons sur leur contenu un peu plus loin.
/etc/VServers/viu.conf le fichier de configuration basique du VServer viu.
/etc/VServers/viu/context le fichier contenant le xid (context id) du VServer viu.
/etc/VServers/viu/flags permet de définir un certain nombre de restrictions à appliquer à viu
/etc/VServers/viu/bcapabilities permet de donner un certain nombre de permission via des CAP_* 
/etc/VServers/viu/ccapabilities permet d'activer la prise en charge de la limitation des ressources 
/etc/VServer/viu/rlimits/ contient les fichiers qui restreignent l'accès aux ressources
/etc/VServers/viu/dlimits/0/ contient les fichiers qui restreignent l'accès aux disques
/etc/VServers/viu/schedule permet de paramétrer la charge et l'utilisation CPU (sceau de jeton)
/etc/VServers/viu.conf
Le fichier /etc/VServers/viu.conf pourrait être le fichier qui permettrait d'éviter de redéfinir les paramètres, cependant, pour avoir expérimenté cette solution, je conseille la redondance. Quand Vserver figure dans les applications à démarrer au boot de l'hôte, le fichier /etc/VServers.conf est lu au boot, ce qui le renvoie sur les fichiers basiques /etc/VServers/xxx.conf. Cela permet notamment de lancer tous les VServers au boot de l'hôte, avec les bons paramètres. 
Le contenu de notre /etc/VServers/viu.conf pourrait se résumer ainsi :
> cat /etc/VServers/viu.conf
IPROOT=192.168.1.50
IPROOTDEV=eth0
IPROOTMASK=255.255.255.0
S_HOSTNAME=viu
S_DOMAINNAME=viu.bux.com
S_FLAGS= « lock nproc fakeinit hideinfo ulimit sched_hard sched_prio virt_mem virt_uptime virt_cpu virt_load hide_mount fork_rss »
ULIMIT= « -H -u 1000 »
S_NICE=8
S_CONTEXT=10001
S_CAPS= « CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_NET_BROADCAST »
ONBOOT=no
On retrouvera la plupart de ces indications dans les autres fichiers, nous détaillerons les valeurs à ce moment là. On peut déjà se douter que le contenu du fichier 
/etc/VServers/viu/bcapabilities sera idem à la valeur de la variable S_CAPS du fichier 
/etc/VServers/viu.conf et que l'on retrouvera les valeurs de la variable S_FLAGS dans le fichier 
/etc/VServers/viu/flags.
/etc/VServers/viu/context
Ce fichier contient le xid du VServer, plus explicitement, le context id. Ce xid est très important puisque c'est ce numéro qui est utilisé pour marquer les dossiers, processus, ... du VServer viu, c'est donc grâce à lui que l'on peut mettre en œuvre la notion d'invisibilité lorsque un VServer veut, par exemple, jeter un coup d’œil aux processus tournant sur un autre VServer (ce qui est impossible s'il n'a pas le même xid). Le fichier en lui même n'est pas obligatoire, il faut savoir que s'il n'est pas défini, alors la machine hôte attribuera un xid dynamique au VServer, toujours dans l'optique de l'isoler de tout autre contexte. Autre règle, il est plutôt déconseillé de faire en sorte que le xid soit dynamique, puisque à chaque redémarrage du VServer, il nous sera difficile de savoir quel est son xid. Il existe une règle pour demander à l'hôte d'attribuer un xid en statique.
Si la valeur stockée dans le fichier /etc/VServers/viu/context (exemple 10001) est : 
supérieure à 49151, le xid est attribué de manière dynamique
comprise entre 3 et 49150, le xid vaut la valeur indiquée (statique) 
Les xid de 0 à 2 sont réservés, 0 pour la machine hôte (le « root suprême »), le 1 pour le contexte Spectateur (qui voit tous les processus de l'hôte), quant au xid 2, mieux vaut ne pas l'utiliser sans une bonne raison.
/etc/VServers/viu/flags
Ce fichier contient, ligne par ligne, les flags qui permettent de restreindre le VServer viu et de moduler sa capacité à voir les informations.
Voici notre fichier /etc/VServers/viu/flags
> cat /etc/VServers/viu/flags
lock
nproc
fakeinit
hideinfo
ulimit
sched_hard
sched_prio
virt_mem
virt_uptime
virt_cpu
virt_load
^20
hide_mount
^37
fork_rss
Pour les principaux flags (mettre le mot de la colonne config)
Context Flags (vs2.0)
Bit Mask Flag config Description 
0 0x00000001 INFO_LOCK lock interdire d'autres commutateurs de contexte 
1 0x00000002 INFO_SCHED * Compter tous les processus comme un seul processus
2 0x00000004 INFO_NPROC nproc appliquer les limitation de processus au contexte
3 0x00000008 INFO_PRIVATE private On ne peut pas entrer dans le contexte
4 0x00000010 INFO_INIT fakeinit Créer un faux init process 
5 0x00000020 INFO_HIDE hideinfo montrer le context info dans le status des tâches 
6 0x00000040 INFO_ULIMIT ulimit appliquer ulimits au contexte
7 0x00000080 INFO_NSPACE namespace Utilise les namespaces privés
8 0x00000100 SCHED_HARD sched_hard active le hard cpu scheduler (voir /etc/VServers/viu/schedule)
9 0x00000200 SCHED_PRIO sched_prio Active le priority scheduler (voir /etc/VServers/viu/schedule)
10 0x00000400 SCHED_PAUSE sched_pause Met le context en pause (unschedule) 
16 0x00010000 VIRT_MEM virt_mem Montrer la meminfo virtuelle (top) 
 (la mémoire virtuelle totale équivaut à environ 4*/etc/VServers/viu/rlimits/rss)
17 0x00020000 VIRT_UPTIME virt_uptime Montrer l'uptime virtuel
18 0x00040000 VIRT_CPU virt_cpu Montrer temps cpu virtuel
19 0x00080000 VIRT_LOAD virt_load Montrer la load average virtuelle
20 0x00100000 VIRT_TIME ^20 utiliser le temps système virtuel
24 0x01000000 HIDE_MOUNT hide_mount Cacher les mount hors du guest
25 0x02000000 HIDE_NETIF hide_netif Cacher les interfaces réseau 
37 0x00000020 REBOOT_KILL ^37 Tue les processus au reboot 
48 0x00010000 FORK_RSS fork_rss Bloque les forks quand la limite rss est atteinte (voir /etc/VServers/viu/rlimits/rss) 
49 0x00020000 PROLIFIC prolific Le contexte peut créer de nouveaux contextes
52 0x00100000 IGNEG_NICE igneg_nice ignore silencieusement les priority raise 
 Attention : en mettant sched_pause, il devient alors impossible de stopper, d'interagir, de killer le VServer, il faut donc redémarrer. Ce flag est donc déconseillé. Il existe aussi 5 autres flags qui n'ont pas été effectifs : hide_netif, namespace, state_setup, state_init, * (state change helper).
/etc/VServers/viu/bcapabilities
Ce fichier liste les capacités du VServer viu, et accepte une capacité par ligne. Il est de la forme : 
> cat /etc/VServers/viu/bcapabilities
CAP_NET_RAW
CAP_NET_BIND_SERVICE
CAP_NET_BROADCAST
Il permet de définir ce que le VServer peut faire, en terme de privilège. Il existe un certain nombre de CAPS, et les reproches qui leur sont souvent adressés sont qu'ils sont trop grossièrement définis. 
Il serait donc un « plus » si un outil pouvait être intégré dans la solution Linux Vserver qui soit capable de créer des CAPS sur mesure sans toucher à la librairie capability.h. En attendant, pour l'ensemble des possibilités de valeur de bcapabilities actuelle : 
/usr/include/linux/capability.h 
BCAP
 /etc/VServers/viu/ccapabilities
Basiquement, cela permettrait, tout comme /etc/VServers/viu/bcapabilities, d'activer un certain nombre de paramètres, comme rlimit. Il existe théoriquement 8 ccaps qui sont : 
utsname
raw_icmp
syslog
secure_mount
secure_remount
binary_mount
quota_ctl
rlimit
Cependant, après les avoir testés un par un, je me suis aperçue qu'un seul était reconnu et appliqué par le kernel : rlimit. En effet cette fonctionnalité, bien que présente et exploitée sur le site officiel, n'est pour le moment (06/2006) qu'à l'état de prototype, et n'a donc pas été développée ni mise en place sur le noyau Vserver 2.6.12.4-vs2.0. Il faudra donc sûrement repatcher le kernel avec un patch VServer Expérimental qui permettra d'exploiter la totalité des ccaps définie, et d'en définir à notre tour. 
Cependant, je ne compte repatcher le noyau avec cette catégorie de patch puisque le stade expérimental ne convient pas au contexte de solution stable pour l'entreprise qui a été définie dans mon cahier des charges.
Voici, pour la documentation, à quoi correspondraient les différents ccapabilities.
Context Caps (vs2.0) 
/etc/VServers/viu/rlimits/
Le répertoire qui contient les limitations de ressource. /etc/VServers/viu/rlimits/ peut contenir plusieurs fichiers, comme as, rss, memlock, nproc, data... où est définie la limite de la ressource en question pour le VServer. Voici les différents fichiers et leur unité.
Un exemple : 
> cat /etc/VServers/viu/rss
100000
Notez ici aussi que pas mal de paramètres manquent à l'appel, comme le nombre de socket ou encore la taille de la queue de message. Ici aussi, la cause se trouve dans le fait que Linux Vserver est un projet relativement récent, et donc en plein développement. La priorité à la sécurité a été notamment donnée sur ce projet puisque les récentes mises à jour concernent le problème chroot et la mise en œuvre de la solution chroot barrier (barrière chroot).
 /etc/VServers/viu/dlimits/0/
 Nous en arrivons aux limitations d'espace disque. Le répertoire est composé de 7 éléments : 
le répertoire /etc/VServers/viu/dlimits/0/
le fichier /etc/VServers/viu/dlimits/0/directory
le fichier /etc/VServers/viu/dlimits/0/space_total
le fichier /etc/VServers/viu/dlimits/0/space_used
le fichier /etc/VServers/viu/dlimits/0/inodes_total
le fichier /etc/VServers/viu/dlimits/0/inodes_used
le fichier /etc/VServers/viu/dlimits/0/reserved
Remarquez le répertoire /0/. Sans lui, les disk limits sont ignorés (dans le cas de la distribution Debian Sarge). Ces fichiers contiennent des entiers, mais on peut aussi les remplir via echo par des équations du genre : > echo $((5*1024*1024))>/etc/VServers/viu/dlimits/0/space_total
Un exemple : 
> cat /etc/VServers/viu/dlimit/0/directory 
/etc/VServers/viu
> cat /etc/VServers/viu/dlimit/0/space_total 
5000000
> cat /etc/VServers/viu/dlimit/0/inodes_total
100000
> cat /etc/VServers/viu/dlimit/0/reserved
5
/etc/VServers/viu/schedule
Le fichier schedule permet de paramètrer l'occupation cpu liée au VServer viu. Il doit contenir au maximum 6 lignes de nombres qui représentent respectivement :
fill rate
interval
Amount of tokens on start
Minimal number of token in token bucket
Maximal number of token in token bucket
dummy line 
Ceci devient très intéressant. En fait le scheduler marche de la manière suivante : 
Chaque <fill rate> jiffies, <fill rate> tokens sont mis dans le sceau à token. Lorsque <Maximal number of token in token bucket> est atteint, tout autre token est rejeté.
Les processus sont mis en attente tant que le sceau à token ne sera pas rempli avec <Minimal number of token in token bucket> tokens.
Il faut bien sûr prendre en compte que la somme de <fill rate> /<fill interval> s'ajoute au nombre de processus de votre système.
Si l'intervalle de remplissage <fill rate / interval> est trop long, cela peut être désastreux pour les perfomances. Le mettre à une petite valeur telle que 1 ou 2 ne posera aucun gros problème, puisque en fait cel recalcule la quantité quand c'est nécessaire. Seulement avec une aussi petite valeur, vous exploserez pas mal de chunks du système. Il vaut mieux donc essayer plus vers 10-20.
Les valeurs par défaut sont les suivantes :
default fill rate 1
default interval 4
no default Amount of token on start
default Minimal amount of token in token bucket 15
default Maximal amount of token in token bucket 125
dummy line
"Tip" : Le jiffies est une variable système interne maintenue par le noyau, qui stocke le nombre de ticks d'horloge depuis la mise sous tension (démarrage) du système. Elle est définie dans <linux/schedule.h>. Cependant, bien qu'elle soit définie comme volatile et longue, elle peut déborder en raison d'un temps utilisable continu (environ un an et demi). 
Sur une machine classique, il y a 100 jiffies dans une seconde.
Sur une machine 32 bits, 497 jours s'avère être la valeur maximum que l'on peut stocker dans un entier non signé. Au delà, l'uptime revient à 0.
À noter que depuis le kernel 2.6, les jiffies sont des intervalles de temps plus court puisqu'ils valent 0.001s ! Je vous renvoie à la librairie en charge : /usr/include/linux/jiffies.h 
Pour notre /etc/VServers/viu/schedule, nous avons à peu près ça :
> cat /etc/VServers/viu/schedule
7
32
500
200
1000
dummy
= Conclusion =
La mise en œuvre de la solution Linux Vserver est assez facile, intuitive, et ne demande pas trop de ressources, ce qui en fait une solution tout à fait convenable. Cependant, il existe plusieurs points noirs à ce projet :
Si l'on devait comparer Linux Vserver à UML et Xen, il en résulterait les résultats suivants : 
« Nous avons donc été en mesure, grâce à ces méthodes, de comparer trois systèmes de virtualisation : Vserver, UML et Xen. Il s’est révélé que Vserver était le plus léger mais qu’il souffrait de quelques lacunes au niveau de l’équité. Xen, quant à lui, s’est montré assez ”lourd” à l’utilisation : le fait de lancer un noyau par machine virtuelle consomme trop de mémoire. En revanche, il est très complet grâce à un grand nombre de configurations possibles, et très fiable au niveau des performances (linéarité, équité, surcoût du système). Pour finir, UML s’est révélé avoir le même défaut que Xen, sans toutefois posséder les qualités de ce dernier. »
Pour plus de renseignements, jetez un coup d'œil à http://www.lri.fr/~quetier/papiers/renpar2005_vmeter.pdf