1. Pourquoi virtualiser ?

1.1 Le problème que la virtualisation résout

Pendant longtemps, chaque service informatique vivait sur sa propre machine physique. Un serveur pour la messagerie, un pour la base de données, un pour le site web.

Résultat : des salles machine bondées de serveurs sous-utilisés, et des coûts d'électricité et de refroidissement disproportionnés. Surtout, un gaspillage colossal de ressources : un serveur physique typique tournait en moyenne à 10 à 15 % de sa capacité CPU.

La virtualisation répond à cette absurdité en permettant à plusieurs systèmes d'exploitation de coexister sur un seul matériel physique. Chaque système croit disposer de sa propre machine, alors qu'il partage en réalité les ressources avec ses voisins. Cette illusion est produite par une couche logicielle — l'hyperviseur — qui s'intercale entre le matériel et les systèmes d'exploitation invités.

Mais réduire la virtualisation à « faire des économies de serveurs » serait passer à côté de l'essentiel. Ce qui a vraiment transformé le métier d'administrateur, ce sont les propriétés qui viennent avec le fait qu'une machine n'est plus qu'un ensemble de fichiers :

• L'isolation des pannes. Chaque service vit dans sa propre machine virtuelle. Un serveur applicatif sature sa mémoire, une mise à jour tourne mal : le problème reste confiné à sa VM.

  Il n'emporte pas les voisins, qui partagent pourtant le même matériel.

• L'instantané et le retour arrière. Avant une mise à jour risquée, on prend un snapshot ; si ça se passe mal, on revient à l'état d'avant en quelques secondes. Sur une machine physique, il aurait fallu une réinstallation.

• La maintenance sans interruption. Une VM peut être déplacée d'un serveur à un autre pendant qu'elle tourne (migration à chaud). On vide ainsi un serveur pour le mettre à jour ou remplacer une barrette de RAM, sans que les utilisateurs ne s'en aperçoivent.

• La reproductibilité. Une machine virtuelle se clone, se transforme en modèle, se déploie en série.

  Monter dix serveurs identiques devient l'affaire de quelques minutes, là où l'installation manuelle en demandait des heures. C'est le rôle des templates (modèles de machines) et de cloud-init (l'outil qui personnalise une machine à son premier démarrage).

• La reprise après sinistre. Puisqu'une VM est un ensemble de fichiers, la sauvegarder et la restaurer ailleurs — sur un autre site, après un incident — devient une opération standard, et non un projet.

C'est cette combinaison — densité et souplesse d'exploitation — qui explique que la quasi-totalité des serveurs d'entreprise tournent virtualisés. Proxmox VE est l'une des plateformes qui rendent tout cela accessible sans licence propriétaire, et c'est ce que ce chapitre commence à mettre en place.

1.2 Les trois grandes familles

La virtualisation ne se présente pas sous une forme unique. Trois familles coexistent, chacune avec ses compromis.

L'hyperviseur de type 1 — aussi appelé "bare metal" — s'installe directement sur le matériel, sans système d'exploitation hôte intermédiaire. Il est le premier programme à s'exécuter au démarrage, bien avant tout système invité.

Cette position privilégiée lui donne un accès direct aux ressources physiques, ce qui se traduit par des performances proches du natif. VMware ESXi, Microsoft Hyper-V, et Proxmox VE appartiennent à cette famille.

L'hyperviseur de type 2 fonctionne différemment : il s'installe comme une application dans un système d'exploitation hôte déjà en place. VirtualBox que vous avez peut-être déjà utilisé sur votre poste, ou VMware Workstation, sont des hyperviseurs de type 2. Pratiques pour le poste de développeur ou la formation, ils introduisent une couche supplémentaire qui dégrade légèrement les performances et les rend inadaptés à la production.

La conteneurisation adopte une approche radicalement différente : plutôt que d'émuler un matériel complet, elle partage le noyau du système hôte entre les environnements isolés. Chaque conteneur ne contient que les binaires et bibliothèques dont il a besoin — pas de noyau, pas de firmware, pas d'émulation matérielle.

LXC (Linux Containers) et Docker sont les représentants les plus connus. Le gain en densité et en vitesse de démarrage est spectaculaire.

Il a un prix : tous les conteneurs partagent le même noyau Linux. Impossible, donc, de faire tourner un système Windows dans un conteneur.

Le schéma ci-dessous empile les trois familles couche par couche. Cliquez sur l'une d'elles pour afficher ses exemples et son compromis. On y lit d'un coup d'œil la couche supplémentaire du type 2, et le système hôte que tous les conteneurs se partagent.

Proxmox VE se range dans la première famille, et fait aussi tourner des conteneurs LXC : c'est ce qui le distingue.

Pour chaque système invité, deux questions décident de la famille : sur quoi repose-t-il, et partage-t-il le noyau avec ses voisins ?

Un défaut du noyau de l'hôte touche tous les conteneurs du nœud : c'est la limite des conteneurs. Une VM a son propre noyau : si elle plante, ses voisines continuent de tourner.

Où voir chaque famille sur votre nœud :

À retenir : la virtualisation fait tourner plusieurs systèmes sur un seul matériel, au lieu d'un serveur sous-utilisé par service. Trois familles. L'hyperviseur de type 1 : sur le matériel, pour la production.

Le type 2 : sur un système hôte, pour le poste de travail. L'isolation par conteneurs : un noyau partagé.