VirtualBox fonctionnait parfaitement. Vous activez WSL2 ou BitLocker, vous redémarrez et VirtualBox refuse de lancer ses VM ou perd la moitié de ses performances. Aucune mise à jour, aucune modification apparente. Ce qui s’est passé en coulisse, c’est que Windows a activé Hyper-V via VBS et votre PC tourne désormais comme un hyperviseur de type 1 même si vous n’avez jamais coché la case.
Au programme de cet article
- La différence entre un hyperviseur de type 1 et 2
- L’hyperviseur de type 1 contrôle le matériel dès le boot
- L’hyperviseur de type 2 s’appuie sur l’OS hôte
- KVM est un type 1 même s’il tourne sous Linux
- Hyper-V, Xen et la partition de gestion
- Ce que la distinction change en production
- Les hyperviseurs type 1 aujourd’hui
- Quel hyperviseur choisir selon votre usage ?
La différence entre un hyperviseur de type 1 et 2
Un hyperviseur crée et gère des machines virtuelles (VM) sur un hôte physique. Il alloue le CPU, la RAM, le stockage et le réseau entre les VM et garantit qu’elles ne s’interfèrent pas.
La distinction type 1 / type 2 tient à qui contrôle le matériel en premier. Sur un type 2, c’est l’OS hôte (Windows, macOS, Linux) qui a la main et l’hyperviseur s’exécute par-dessus comme une application. Sur un type 1, c’est l’hyperviseur lui-même qui prend le contrôle du matériel au démarrage, avant tout OS.
Les processeurs Intel (VT-x) et AMD (AMD-V) réservent pour ça un niveau de privilège dit ring −1, plus bas que le ring 0 auquel accède un OS classique. Seul l’hyperviseur s’exécute à ce niveau. Les OS invités ne voient jamais le matériel directement.
L’hyperviseur de type 1 contrôle le matériel dès le boot
Un type 1 s’installe directement sur la machine nue, sans OS préexistant. C’est lui qui démarre en premier, prend la main sur le CPU, la RAM et les périphériques, puis crée des machines virtuelles pour y faire tourner les OS invités.
Type 1 — bare metal
VM 1 VM 2 VM 3
(Windows) (Linux) (FreeBSD)
│ │ │
└───────────┴───────────┘
│
Hyperviseur (ring −1) ←── seul accès au matériel réel
│
Matériel physique (CPU · RAM · Disque · Réseau)
L’hyperviseur de type 2 s’appuie sur l’OS hôte
Un type 2 s’installe comme n’importe quelle application (VirtualBox sur Windows, VMware Workstation sur Linux). Il s’appuie sur l’OS hôte pour accéder au matériel. Quand une VM a besoin du réseau, la requête passe par l’hyperviseur, puis par l’OS hôte, puis par le pilote, puis par le matériel. Une couche de plus à chaque fois, ce qui ajoute de la latence et un point de défaillance supplémentaire.
Type 2 — hébergé
VM 1 VM 2
(Linux) (Windows)
│ │
└─────┬─────┘
│
Hyperviseur (application)
│
OS hôte (Windows / Linux / macOS) ←── contrôle réel du matériel
│
Matériel physique
| Critère | Type 1 (bare metal) | Type 2 (hébergé) |
|---|---|---|
| Qui contrôle le matériel | L’hyperviseur directement (ring −1) | L’OS hôte, l’hyperviseur passe par lui |
| Performances | Accès direct, latence minimale | Couche OS hôte supplémentaire |
| Sécurité | Surface d’attaque réduite, isolation forte | Dépend de la sécurité de l’OS hôte |
| Live migration VM | Oui (vMotion ESXi, KVM) | Non |
| Passthrough GPU / IOMMU | Oui (Proxmox, ESXi) | Limité ou non supporté |
| Installation | Dédiée, sans OS préexistant | Simple, comme un logiciel |
| Usage recommandé | Production, datacenter, homelab sérieux | Tests, développement, desktop |
| Exemples | ESXi, Proxmox, KVM, Hyper-V, Xen | VirtualBox, VMware Workstation, Parallels |
assistouest.frKVM est un type 1 même s’il tourne sous Linux
KVM (Kernel-based Virtual Machine) s’installe sur un système Linux, donc beaucoup le classent en type 2 par analogie avec VirtualBox. C’est faux pour une raison précise.
KVM est un module du noyau Linux. Une fois chargé, il ne s’exécute pas par-dessus Linux comme une application. Il transforme le noyau Linux lui-même en hyperviseur. Linux passe en ring −1 via les extensions VT-x/AMD-V et devient la couche de gestion qui pilote le matériel. Les VM tournent en ring 0 virtuel, exactement comme avec ESXi.
Linux n’est pas ici l’OS hôte au sens type 2. C’est la partition de gestion, équivalente à ce que Hyper-V appelle la partition parente ou à ce que Xen appelle le dom0. Sans le module KVM, Linux est un OS ordinaire. Avec lui, c’est un hyperviseur de type 1.
KVM — Linux devient l'hyperviseur
VM 1 (QEMU) VM 2 (QEMU)
│ │
└───────┬────────┘
│ hypercalls
▼
Linux + module KVM ── ring −1 via VT-x / AMD-V
│
Matériel physique
Proxmox VE repose entièrement sur KVM. Proxmox n’est pas un type 2 sous prétexte qu’il y a Debian en dessous. Debian avec KVM chargé est l’hyperviseur. C’est pour ça que Proxmox supporte la live migration, le passthrough GPU et la haute disponibilité qu’un type 2 ne peut pas offrir. KVM alimente environ 80 % des clouds publics (AWS EC2, Google Compute Engine, une partie d’Azure).
Hyper-V, Xen et la partition de gestion
Hyper-V est livré avec Windows, activable depuis le panneau des fonctionnalités. Dès le redémarrage après activation, il s’insère en ring −1 sous Windows. Windows ne dialogue plus directement avec le matériel, il devient la partition parente, une VM de gestion qui fournit les pilotes aux autres VM via le VMbus.
Xen fait exactement la même chose avec le dom0, une VM Linux de gestion avec accès privilégié au matériel. Dom0 Xen et partition parente Hyper-V sont deux noms pour la même idée. Les deux sont des type 1 hybrides où l’OS de gestion tourne dans une partition privilégiée plutôt que d’être absent.
Pour comprendre en détail pourquoi Hyper-V est classé type 1 malgré son apparence de logiciel Windows, le mécanisme VMbus et l’impact de VBS sur votre PC, voir notre article dédié à Hyper-V et son classement type 1.
Ce que la distinction change en production
La différence type 1 / type 2 n’est pas que théorique. 3 fonctions sont exclusivement disponibles sur type 1.
Live migration : Déplacer une VM d’un serveur physique à un autre sans coupure de service. vMotion sur ESXi, live migration sur KVM et Proxmox. VirtualBox ne peut pas faire ça car il est lié à l’OS hôte, donc la VM est liée à la machine.
Passthrough GPU et IOMMU : Donner à une VM un accès direct à une carte graphique physique avec des performances quasi-natives. Utile pour faire tourner Windows dans Proxmox avec le vrai GPU ou pour des workloads IA qui ont besoin du CUDA d’une carte dédiée. Le type 2 ne supporte pas le passthrough PCIe.
Haute disponibilité : Redémarrer automatiquement une VM sur un autre nœud si le serveur physique tombe. Exclusif aux clusters type 1 (Proxmox HA, vSphere HA). Sur type 2, la VM meurt avec l’OS hôte.
Les hyperviseurs type 1 aujourd’hui
ESXi a longtemps été la référence. Depuis le rachat de VMware par Broadcom en 2024 et la suppression des licences gratuites, beaucoup de homelabs et de petites entreprises sont passés à Proxmox. Proxmox est open source, gratuit, basé sur KVM et LXC avec live migration, HA et passthrough GPU sans abonnement.
À l’autre extrémité, AWS a développé Firecracker, un hyperviseur KVM ultra-léger pour les microVMs. Chaque fonction Lambda AWS tourne dans une microVM Firecracker qui démarre en moins de 125 millisecondes et consomme environ 5 Mo de RAM. C’est du type 1 (KVM en ring −1) conçu pour démarrer et s’arrêter des milliers de fois par seconde.
KVM, Hyper-V, Xen et Firecracker sont tous des type 1 avec des architectures de gestion différentes. Ce qu’ils partagent, c’est le ring −1 et l’accès direct au matériel sans passer par un OS hôte indépendant. Pour aller plus loin sur les optimisations de pilotes entre VM et hyperviseur, voir la paravirtualisation de Xen aux pilotes modernes (VirtIO, VMware Tools).
Quel hyperviseur choisir selon votre usage ?
Homelab ou petit serveur : Proxmox est le choix le plus rationnel depuis 2024. Gratuit, basé sur KVM, interface web complète, live migration et HA disponibles. ESXi est toujours pertinent si vous avez déjà un parc VMware sous licence.
Poste de développement sous Windows : WSL2 couvre la majorité des besoins Linux sans VM complète.
Environnement Windows Server en entreprise. Hyper-V s’intègre nativement avec Active Directory et Azure. Pas besoin d’une couche supplémentaire si votre infrastructure est déjà Microsoft.
Cloud ou infrastructure distribuée : KVM sous la couche cloud, Firecracker pour les fonctions éphémères, Xen dans certains environnements Citrix. Pour comparer les solutions disponibles, voir les meilleurs logiciels de virtualisation pour Windows.