3. Sous le capot : la pile logicielle et le moteur des VM

Proxmox est maintenant présenté : ce qu'il fait, d'où il vient, où il est le bon choix. Cette section ouvre le capot — de quoi la plateforme est faite, brique par brique, et comment le moteur KVM/QEMU exécute les machines virtuelles.

3.1 La pile logicielle

Proxmox VE n'est pas un système d'exploitation écrit de zéro. C'est une surcouche spécialisée construite sur Debian : l'écosystème Debian est disponible, et un administrateur Linux s'y retrouve immédiatement.

Les composants s'empilent ainsi :

Le noyau : userland Debian, noyau Proxmox. Les paquets et les outils sont ceux de Debian (Debian 13 « Trixie » pour Proxmox VE 9).

Mais le noyau est fourni par Proxmox, dérivé d'un noyau Ubuntu récent. Il apporte des pilotes plus récents pour le matériel neuf, des correctifs pour KVM et LXC, et le module ZFS intégré, ce qui permet d'installer le système directement sur ZFS. On le reconnaît au suffixe -pve que répond uname -r.

Conséquence pratique, le jour où l'on installe Proxmox sur une Debian déjà en place : il faut retirer le noyau Debian (linux-image-*). Ce noyau peut entrer en conflit avec le paquet proxmox-ve lors des mises à jour. Sur un nœud installé depuis l'ISO, c'est déjà réglé.

QEMU/KVM gère les machines virtuelles. Chaque VM tourne comme un processus QEMU, avec accélération KVM ; sa configuration est dans /etc/pve/qemu-server/<vmid>.conf.

LXC (Linux Containers) gère les conteneurs : des conteneurs système, avec leur propre init, leurs services et leur réseau, qui partagent le noyau de l'hôte.

pmxcfs est le système de fichiers de Proxmox : il stocke toute la configuration de la plateforme dans /etc/pve/, et la réplique entre les nœuds d'un cluster. Même sur un nœud seul, il est présent et actif.

Corosync assure la communication entre les nœuds d'un cluster. Sur un nœud seul, il est installé mais ne tourne pas : systemctl status corosync affiche inactive (dead), ce n'est pas une panne.

L'API REST et l'interface web (pveproxy) donnent accès à toutes les fonctions par HTTPS. L'interface est construite au-dessus de cette API : ce qu'on fait à la souris se fait aussi avec pvesh.

• 📖 Documentation officielle Proxmox VE — guide d'administration

3.2 Sous le capot : KVM/QEMU et le prérequis processeur

Maintenant que Proxmox est présenté, ouvrons le capot du côté des machines virtuelles. KVM — Kernel-based Virtual Machine — est un module du noyau Linux, pas un logiciel externe. Depuis sa fusion dans le noyau Linux 2.6.20 en 2007, KVM transforme n'importe quel noyau Linux en hyperviseur.

Il ne réinvente pas la gestion de la mémoire, des interruptions et de l'ordonnancement. Il réutilise tout ce que le noyau sait déjà faire, et y ajoute la capacité d'isoler des contextes d'exécution. C'est le moteur des VM de Proxmox ; les conteneurs LXC, eux, n'en dépendent pas.

Pour fonctionner, KVM s'appuie sur les extensions matérielles de virtualisation intégrées dans les processeurs modernes. Intel les appelle VT-x (Virtualization Technology, pour ses processeurs IA — Intel Architecture — 32 et 64 bits). AMD (l'autre fabricant de processeurs x86) les appelle AMD-V (ou SVM — Secure Virtual Machine).

Ces extensions permettent au processeur de basculer rapidement entre le contexte de l'hyperviseur et celui des machines virtuelles. Les instructions sensibles (accès matériel, gestion de la mémoire) ne peuvent pas "s'échapper" vers le matériel réel.

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Depuis le Shell du noeud Proxmox — pas depuis votre poste Windows
# Verifier que les extensions de virtualisation sont presentes ; -m 1 : la premiere ligne trouvee
grep -m 1 -E 'vmx|svm' /proc/cpuinfo

# vmx = Intel VT-x
# svm = AMD-V

Résultat attendu — sur un processeur Intel :

root@pve1:~# grep -m 1 -E 'vmx|svm' /proc/cpuinfo
flags       : ... vmx sse4_1 sse4_2 x2apic ...

Sur un processeur AMD, c'est svm qui apparaît à la place :

root@pve1:~# grep -m 1 -E 'vmx|svm' /proc/cpuinfo
flags       : ... svm sse4a abm ...

Une sortie vide est le seul cas préoccupant : la virtualisation matérielle est désactivée dans le BIOS (Basic Input/Output System) ou l'UEFI (Unified Extensible Firmware Interface). C'est le micrologiciel de démarrage du serveur.

Proxmox ne pourra alors démarrer aucune machine virtuelle KVM. Les conteneurs LXC, eux, continueront de fonctionner : ils ne s'appuient pas sur ces instructions.

Si la commande ne renvoie rien, les extensions de virtualisation sont soit absentes du processeur (rare sur le matériel récent), soit désactivées dans le BIOS/UEFI. Proxmox affichera une erreur au démarrage des VMs dans ce cas. Sur nos ateliers, le matériel a été vérifié en amont — les extensions sont actives.

KVM seul ne suffit pas pour créer une machine virtuelle complète : il gère la virtualisation CPU et mémoire, mais pas l'émulation des périphériques (carte réseau, disque, clavier). C'est QEMU qui prend en charge cette émulation. Dans Proxmox, KVM et QEMU travaillent toujours en tandem — vous entendrez d'ailleurs parfois parler de "KVM/QEMU" comme d'un seul bloc.

À retenir : Proxmox est une surcouche de Debian : son noyau, pmxcfs (la configuration partagée dans /etc/pve), pveproxy (l'interface web sur 8006) et les outils qm / pct. Les VM passent par KVM, un module du noyau, et QEMU ; KVM exige les extensions VT-x ou AMD-V du processeur (grep -E 'vmx|svm' /proc/cpuinfo).