La virtualisation fait tourner plusieurs machines virtuelles isolées sur un même serveur physique, chacune avec son propre noyau, son système et ses ressources. Cette section couvre les solutions open source qui la mettent en oeuvre sous Linux : KVM, Proxmox VE, Incus et KubeVirt. Elle pose d'abord les concepts (VM, hyperviseur, type 1 contre type 2), puis ouvre sur trois formations complètes suivies pas à pas : KVM/libvirt (14 leçons, environ 9 h 30), Proxmox VE (15 leçons, environ 7 h 30) et Incus (20 leçons, environ 6 heures). Public visé : administrateurs système, DevOps et SRE qui montent ou reprennent une plateforme de virtualisation.
Qu'est-ce que la virtualisation et à quoi sert un hyperviseur ?
Section intitulée « Qu'est-ce que la virtualisation et à quoi sert un hyperviseur ? »La virtualisation découpe les ressources d'un serveur physique (CPU, mémoire, disque, réseau) en ressources virtuelles attribuées à des machines indépendantes, sous le contrôle d'un composant appelé hyperviseur. Chaque machine virtuelle croit disposer d'un ordinateur complet ; elle démarre son propre noyau, son propre système de fichiers et ses propres services.
L'hyperviseur arbitre l'accès au matériel réel. Sur un processeur moderne, il ne simule pas les instructions : il s'appuie sur des extensions matérielles de virtualisation, Intel VT-x ou AMD-V, qui laissent le code de la VM s'exécuter directement sur le processeur physique. C'est ce qui rend une VM presque aussi rapide qu'une machine réelle, et c'est aussi pourquoi une machine sans ces extensions ne sait faire que de l'émulation logicielle, nettement plus lente.
Les bénéfices sont mesurables et tiennent en cinq points : un meilleur taux d'utilisation du matériel, l'isolation des charges les unes des autres, les snapshots pour revenir à un état antérieur, le clonage quasi instantané d'un modèle, et le pilotage par API qui rend tout cela automatisable avec Terraform ou Ansible.
Machine virtuelle ou conteneur : quelle différence ?
Section intitulée « Machine virtuelle ou conteneur : quelle différence ? »Une machine virtuelle embarque son propre noyau, un conteneur partage celui de l'hôte. Toute la différence de comportement découle de ce seul point, et c'est lui qui doit guider le choix.
| Critère | Machine virtuelle | Conteneur |
|---|---|---|
| Noyau | Le sien, complet | Celui de l'hôte, partagé |
| Système invité possible | Linux, Windows, BSD | Linux uniquement, même famille de noyau |
| Démarrage | Quelques dizaines de secondes | Moins d'une seconde |
| Empreinte disque | Plusieurs gigaoctets | Quelques dizaines de mégaoctets |
| Isolation | Forte, frontière matérielle | Plus fine, frontière logicielle du noyau |
| Usage typique | Systèmes hétérogènes, applications non conteneurisables, bases de données historiques | Applications sans état, montée en charge, cycles de livraison courts |
En pratique, une VM reste le bon choix quand vous devez faire tourner Windows, un noyau différent de celui de l'hôte, une appliance fournie sous forme d'image disque, ou quand la frontière d'isolation doit être aussi nette que possible. Le conteneur gagne dès que l'application est conteneurisable et que la vitesse de démarrage compte. Les deux modèles cohabitent d'ailleurs très bien : Proxmox VE gère les deux, Incus aussi, et KubeVirt fait tourner des VM au milieu de conteneurs Kubernetes.
Type 1 ou type 2 : quel hyperviseur choisir ?
Section intitulée « Type 1 ou type 2 : quel hyperviseur choisir ? »Un hyperviseur de type 1 s'exécute directement sur le matériel, un hyperviseur de type 2 s'installe au-dessus d'un système d'exploitation déjà présent. Cette distinction commande le niveau de performance accessible et le contexte d'usage.
| Type 1 (bare-metal) | Type 2 (poste de travail) | |
|---|---|---|
| S'installe sur | Le matériel nu | Un système hôte existant |
| Exemples | KVM, Proxmox VE, VMware ESXi | VirtualBox |
| Performance | Proche du matériel | Pénalisée par la couche hôte |
| Contexte | Serveurs, clusters, production | Apprentissage, développement, tests |
| Disponibilité | Cluster, migration à chaud, haute disponibilité | Machine unique |
Le cas de KVM mérite une précision, parce qu'il revient souvent dans les discussions : KVM est un module du noyau Linux, ce qui donne l'impression d'un type 2 installé sur un système. C'est bien un type 1 : le module transforme le noyau Linux lui-même en hyperviseur, et la VM s'exécute sur le processeur physique sans couche intermédiaire. La comparaison détaillée se trouve dans Type 1 vs Type 2.
Quelle solution de virtualisation open source choisir ?
Section intitulée « Quelle solution de virtualisation open source choisir ? »Le choix se fait sur le contexte d'exploitation, pas sur les performances brutes : les quatre familles ci-dessous reposent toutes sur les mêmes extensions matérielles. Le tableau situe chacune par rapport au besoin qu'elle sert le mieux.
| Famille | Solutions | Quand la choisir |
|---|---|---|
| Type 1 bare-metal | KVM/libvirt, Proxmox VE, VMware ESXi | Serveurs et clusters de production |
| Conteneurs système et VM | Incus | Infrastructure légère, cloud privé, homelab |
| VM dans Kubernetes | KubeVirt, Harvester | Plateformes cloud native qui unifient VM et conteneurs |
| Type 2 (poste de travail) | VirtualBox | Apprendre, tester, développer sur son poste |
Ces familles ne s'excluent pas. Un même administrateur utilise couramment KVM en local pour ses maquettes, Proxmox VE sur ses serveurs, Incus pour un cloud privé léger, et KubeVirt là où un cluster Kubernetes existe déjà. L'erreur classique consiste à choisir l'outil d'abord et à découvrir ensuite qu'il ne couvre pas le besoin réel : partez des concepts, identifiez la contrainte dominante (production, poste de travail, cluster existant), et l'outil se déduit.
Comment vérifier que votre machine sait faire tourner des VM ?
Section intitulée « Comment vérifier que votre machine sait faire tourner des VM ? »Trois commandes suffisent à savoir si votre processeur expose la virtualisation matérielle et si le noyau Linux l'a activée. Le contrôle prend dix secondes et évite de perdre une heure sur une installation qui ne pouvait pas aboutir.
# 1. Le processeur expose-t-il VT-x (Intel) ou AMD-V (AMD) ?grep -Ec '(vmx|svm)' /proc/cpuinfo
# 2. Le noyau a-t-il chargé le module KVM ?lsmod | grep -E '^kvm'
# 3. Le périphérique est-il présent et accessible ?ls -l /dev/kvmLa première commande renvoie le nombre de coeurs logiques qui exposent l'extension : sur une machine à 32 coeurs logiques, la réponse attendue est 32. Un 0 signifie soit un processeur sans extension de virtualisation, soit, bien plus souvent, une option désactivée dans le BIOS/UEFI sous un nom du genre « Intel Virtualization Technology » ou « SVM Mode ». La deuxième doit lister kvm_intel ou kvm_amd en plus du module kvm. La troisième doit afficher un périphérique caractère appartenant au groupe kvm : si votre compte n'appartient pas à ce groupe, l'accès sera refusé même quand tout le reste est correct.
Les parcours de cette section, et par où entrer
Section intitulée « Les parcours de cette section, et par où entrer »La section se lit dans l'ordre si vous découvrez la virtualisation, et se picore si vous cherchez un point précis. Chaque bloc ci-dessous a son propre point d'entrée, ses guides et ses labs.
Les fondamentaux, à lire en premier
Section intitulée « Les fondamentaux, à lire en premier »Avant de choisir un outil, il faut comprendre la mécanique. Ces trois guides posent le vocabulaire et les modèles mentaux qui resservent quelle que soit la plateforme retenue, y compris le choix du format de disque virtuel, qui décide à la fois des performances et de la place occupée.
- Qu'est-ce qu'une VM ? : machine virtuelle, hyperviseur et ressources partagées, expliqués sans prérequis.
- Type 1 vs Type 2 : bare-metal ou au-dessus d'un système hôte, et les conséquences concrètes de ce choix.
- Disques virtuels : RAW vs QCOW2 : allocation fine ou complète, formats et impact mesuré sur les performances.
KVM et Proxmox VE, les deux piliers open source
Section intitulée « KVM et Proxmox VE, les deux piliers open source »Sur un serveur Linux, ces deux briques couvrent l'essentiel des besoins sans coût de licence. KVM est l'hyperviseur intégré au noyau Linux : c'est le moteur, piloté par libvirt et la commande virsh, sur lequel repose une grande partie de l'écosystème, y compris Proxmox lui-même. On l'apprend pour comprendre ce qui se passe sous le capot et pour automatiser finement avec Terraform ou Ansible. La formation compte 14 leçons pour environ 9 h 30, des concepts au provisionnement par terraform-provider-libvirt.
Proxmox VE ajoute au-dessus de KVM et de LXC une plateforme clé en main : interface web, cluster, sauvegarde intégrée et gestion des permissions. C'est souvent le meilleur point de départ pour une équipe qui veut une console complète sans tout assembler à la main. La formation compte 15 leçons pour environ 7 h 30, réparties en quatre temps : comprendre la plateforme, l'installer et créer ses premières instances, traiter des cas pratiques (Windows 11, reprise d'un parc ESXi, Proxmox Backup Server), puis automatiser en Terraform et Ansible.
- Formation KVM/libvirt : concepts, installation, réseau, stockage, snapshots, cloud-init et Terraform.
- Formation Proxmox VE : des fondamentaux à l'automatisation en Infrastructure as Code.
- Importer ses VM existantes : reprendre un parc ESXi avec l'assistant d'import natif de Proxmox.
- Proxmox Backup Server : sauvegarder ses VM et, surtout, tester ses restaurations.
Incus, la virtualisation légère et le cloud privé
Section intitulée « Incus, la virtualisation légère et le cloud privé »Incus, le fork communautaire de LXD créé par Stéphane Graber, mérite une place à part. Dans une seule CLI et une seule API, il gère à la fois des conteneurs système (des distributions Linux complètes, exploitées comme des VM légères) et de vraies machines virtuelles QEMU. Plus léger qu'un hyperviseur complet, il démarre une instance Debian en quelques secondes et bascule sur une VM avec la même commande quand il faut un autre noyau.
Incus ne s'arrête pas au serveur isolé : avec le cluster, les réseaux OVN et le stockage Ceph, il monte jusqu'au cloud privé multi-tenant. La formation compte 20 leçons pour environ 6 heures.
- Découvrir Incus : le gestionnaire de conteneurs système et de machines virtuelles en une CLI.
- Premiers pas avec Incus : lancer son premier conteneur, puis sa première VM.
- Cluster Incus : passer d'un serveur unique au cluster à haute disponibilité.
Faire tourner des VM dans Kubernetes
Section intitulée « Faire tourner des VM dans Kubernetes »Quand la plateforme est déjà Kubernetes, les machines virtuelles peuvent s'exécuter aux côtés des conteneurs, sans monter un hyperviseur séparé. KubeVirt ajoute cette capacité à un cluster existant : les VM deviennent des objets Kubernetes, décrites en YAML et gérées avec kubectl, donc soumises au même RBAC et au même GitOps que le reste. Harvester, la distribution hyperconvergée de SUSE, va plus loin en fournissant une plateforme clé en main bâtie sur KubeVirt et Longhorn.
- KubeVirt : le parcours complet, des concepts à la création de VM dans un cluster.
- SUSE Harvester : la plateforme hyperconvergée clé en main bâtie sur KubeVirt.
Apprendre et tester sans matériel dédié
Section intitulée « Apprendre et tester sans matériel dédié »On n'a pas toujours un serveur sous la main. Pour apprendre les concepts sans rien casser, un hyperviseur de type 2 sur son poste suffit largement. Et pour tester de l'outillage qui pilote un environnement VMware sans en payer la licence, le simulateur vcsim reproduit une API vCenter et ESXi complète, ce qui permet de valider des scripts govc ou un provider Terraform sans infrastructure.
- Créer une VM Type 2 : la checklist et les premiers pas sur un poste de travail.
- vcsim : simuler un vCenter et des ESXi : tester ses scripts et son outillage sans matériel VMware.
Pourquoi choisir un hyperviseur open source en 2026 ?
Section intitulée « Pourquoi choisir un hyperviseur open source en 2026 ? »Parce que l'open source supprime le coût de licence, garantit la réversibilité et laisse la donnée sous votre contrôle. Le marché de la virtualisation a été fortement bousculé ces deux dernières années : hausses tarifaires, fin de certaines licences perpétuelles et changements de politique de distribution ont poussé beaucoup d'équipes à réévaluer leur socle.
Trois exigences concrètes en découlent. L'absence de coût de licence change la façon de dimensionner : on ajoute un noeud parce que la charge l'exige, pas parce que le contrat le permet. La réversibilité compte autant : un format de disque ouvert comme QCOW2 ou RAW s'importe et s'exporte sans outil propriétaire, ce qui rend une sortie possible à tout moment. La souveraineté, enfin, tient au fait que la plateforme tourne sur votre matériel, avec un code auditable.
Le point décisif d'une transition réussie reste la capacité à reprendre l'existant sans tout reconstruire. C'est exactement ce que permet l'import des machines depuis un environnement VMware vers Proxmox VE, ou la reconstruction d'un cloud privé léger avec Incus. Cette section vous outille pour cette bascule, des concepts jusqu'à l'exploitation quotidienne.
À retenir
Section intitulée « À retenir »- La virtualisation mutualise un serveur physique en VM isolées via un hyperviseur ; tout part de ce modèle.
- Une VM embarque son noyau, un conteneur partage celui de l'hôte : c'est la seule différence qui compte pour choisir.
- Type 1 (bare-metal) pour la production, type 2 pour apprendre et développer sur son poste. KVM est un type 1, malgré son intégration au noyau Linux.
grep -Ec '(vmx|svm)' /proc/cpuinforenvoie0quand la virtualisation matérielle est absente ou désactivée dans le BIOS/UEFI.- KVM est le moteur du noyau Linux, Proxmox VE la plateforme clé en main au-dessus ; Incus couvre la virtualisation légère jusqu'au cloud privé, KubeVirt exécute des VM dans Kubernetes.
- L'open source garantit la réversibilité : les formats QCOW2 et RAW s'importent et s'exportent sans outil propriétaire.