Le noyau d'OpenVZ est un noyau Linux modifié qui ajoute la notion d'environnement virtuel. Le noyau fournit la virtualisation, l'isolement, la gestion de ressource, et le checkpoint/restart.
Virtualisation et isolement
Un VE est une entité séparée, et du point de vue de son propriétaire, il ressemble à un vrai serveur physique. Chaque VE a ses propres :
Fichiers
Les bibliothèques système, applications, /proc et /sys virtualisés, verrous virtualisés, etc.
Utilisateurs et groupes
Chaque VE a son propre utilisateur root, ainsi que ses propres utilisateurs et groupes.
Arborescence de processus
Chaque VE voit seulement ses propres processus (à partir de l'init). Les Identifiant de processus (PID) sont virtualisés, de telle sorte que le PID de la tâche init est 1, tel qu'il devrait l'être.
Réseau
Interface réseau virtuelle, qui permet à un VE d'avoir ses propres adresses IP, aussi bien qu'un ensemble de règles Netfilter (iptables) et de routage.
Périphériques
Si nécessaire, on peut accorder à n'importe quel VE l'accès à de vrais périphériques comme des interfaces réseau, des ports séries, des partitions de disque, etc.
IPC
Mémoire partagée, sémaphores, file d'attente de messages.
Gestion des ressources
Comme tous les VEs utilisent le même noyau, la gestion des ressources est d'importance primordiale. Chaque VE doit rester dans ses limites et ne pas affecter d'autres VEs.
La gestion des ressources d'OpenVZ est composée des trois éléments suivants : des quotas disque à deux niveaux, un scheduler fair CPU, et des beancounters utilisateurs. Toutes ces ressources peuvent être modifiées pendant le temps d'exécution d'un VE, sans avoir à rebooter. Il est par exemple possible d'allouer à chaud plus de mémoire à un VE, en changeant des paramètres appropriés à la volée. C'est une fonctionnalité souvent impossible ou complexe avec d'autres approche de virtualisation telles que la VM ou l'hyperviseur.
Quotas disque à deux niveaux
L'utilisateur root du système hôte (OpenVZ) peut établir des quotas disque par VE, spécifiés en termes de bloc disque et d'inode (plus ou moins le nombre de fichiers). C'est le premier niveau des quotas disque. En plus de ceux-ci, un propriétaire de VE (utilisateur root) peut utiliser les outils habituels de gestions des quotas à l'intérieur de son propre VE pour placer des quotas disque standards par utilisateur et par groupe d'UNIX.
Il est possible d'allouer dynamiquement de l'espace disque à un VE, en modifiant simplement son quota disque (autrement dit, sans qu'il soit nécessaire de redimensionner les partitions du disque).
Scheduler Fair CPU
Le scheduler CPU d'OpenVZ est également à deux niveaux. Au premier niveau, le scheduler décide à quel VE le time slice sera affecté, basé sur des cpuunits par VE. Au deuxième niveau, le scheduler standard Linux décide quel processus s'exécutera dans le VE, en utilisant les priorités de processus standards.
L'administrateur d'OpenVZ peut établir différentes valeurs des cpuunits pour des VEs différent, et le temps CPU sera donné à ceux-ci proportionnellement.
Il est en outre possible de limiter le temps CPU, par exemple à 10% de temps CPU disponible.
Beancounters Utilisateur
Les Beancounters utilisateur sont un ensemble de compteurs, de limites, et de garanties par VE. Environ 20 paramètres, soigneusement choisis, couvrent tous les aspects des opérations d'un VE ; ainsi, aucun VE ne peut abuser d'une ressource qui est limitée pour le nœud entier et de cette façon nuire à un autre VE.
Les ressources comptabilisées et contrôlées sont principalement la mémoire et divers objets noyau tels que les segments de mémoire partagés, les buffers réseau, etc. Chaque ressource peut être vue depuis /proc/user_beancounters et cinq valeurs lui sont associées : utilisation courante, utilisation maximum (pour la vie d'un VE), barrière, limite, et compteur d'échec. La signification de la barrière et de la limite est dépendante du paramètre ; en bref, ceux-ci peuvent être considérés comme une limite soft et une limite hard. Si n'importe quelle ressource atteint la limite, le compteur d'échec est incrémenté, ainsi le propriétaire du VE peut voir si quelque chose de néfaste se produit en analysant la sortie de /proc/user_beancounters dans son VE.
Checkpointing et migration live
La fonctionnalité de migration live et de checkpoint pour OpenVZ a été annoncé au milieu d'avril 2006. Elle permet de migrer un VE d'un serveur physique à un autre sans arrêt/relance du VE. Ce processus est connu comme application checkpointing : le VE est gelé et son état entier est sauvegardé dans un fichier sur disque. Ce fichier peut alors être transféré sur une autre machine sur laquelle le VE pourra être restauré. Le délai de migration est de quelques secondes, et ce n'est pas un temps d'arrêt, juste un retard.
Chaque morceau d'état de VE, y compris les connexions de réseau ouvertes, est sauvé. De la perspective de l'utilisateur, cela ressemble à un retard dans la réponse : une transaction de base de données prendra un peu plus longtemps que d'habitude, quand le VE redémarre, l'utilisateur ne note pas que sa base de données fonctionne déjà sur une autre machine.
Cette fonctionnalité rend possible des scénarios tels que la mise à jour du serveur sans avoir besoin de le rebooter : si votre base de données a besoin de plus de mémoire ou de CPU, vous achetez un nouveau serveur, migrez votre VE dessus et vous augmentez ensuite ses limites. Si vous voulez ajouter plus de RAM à votre serveur, vous migrez tous les VEs sur un autre serveur, vous arrêtez le premier, ajoutez la mémoire, puis rebootez et remigrez tous les VEs.
