>Hyper-V est un hyperviseur de type 1 et non un hyperviseur de type 2_

Hyper-V est livré avec Windows. On l’active depuis le panneau des fonctionnalités Windows, on le configure dans une interface graphique et on garde le même bureau. La majorité des techniciens le classent spontanément dans les hyperviseurs de type 2, au même rang que VirtualBox ou VMware Workstation. C’est une erreur. Dès que la case est cochée, Windows n’est plus maître de votre machine.

La reconfiguration des couches matérielles par Hyper-V

Sur un PC sans Hyper-V, Windows dialogue directement avec le processeur, la mémoire et les périphériques via ses pilotes. C’est l’architecture classique, le matériel en bas et l’OS juste au-dessus.

Quand vous cochez la case Hyper-V et que vous redémarrez, cette architecture bascule. Hyper-V s’insère entre le matériel et tout le reste. Windows ne parle plus directement au processeur. Il passe par l’hyperviseur, exactement comme n’importe quelle autre machine virtuelle. La seule différence, c’est qu’il reçoit des privilèges spéciaux pour continuer à fournir les pilotes et administrer les VM enfants. On appelle ça la partition parente (ou root partition).

Comment fonctionne Windows sans Hyper-V ?

Applications (Chrome, jeux, Office…)
      │
      ▼
Windows OS  ────────  Ring 0 — dialogue direct avec le matériel
      │
      ▼
Matériel physique  (CPU · RAM · Disque · Réseau)

L’architecture de Windows avec Hyper-V actif

Applications Windows
      │
      ▼
Partition parente — Windows OS  ──  Ring 0 virtuel · pilotes via VMbus
      │              ┌──────────────────────────┐
      │              │  VM enfant 1  (FreeBSD)  │
      │              │  VM enfant 2  (pfSense)  │
      │              └──────────────────────────┘
      │  hypercalls
      ▼
Hyper-V  ───────────────────────  Ring −1 (VMX root) — contrôle réel
      │  VT-x / AMD-V requis
      ▼
Matériel physique  (CPU · RAM · Disque · Réseau)

Pourquoi Hyper-V est un type 1 et non un type 2 ?

La distinction type 1 / type 2 se joue à un seul endroit. Qui contrôle le matériel en ring 0 ou en-dessous ?

Les processeurs Intel (VT-x) et AMD (AMD-V) ont ajouté un niveau de privilège encore plus bas que le ring 0 classique, (ring −1 ou mode VMX root). Seul l’hyperviseur peut s’exécuter à ce niveau. Les OS invités, même Windows avec ses privilèges de partition parente, s’exécutent en ring 0 virtuel, c’est-à-dire ring 0 émulé par l’hyperviseur.

Hyper-V tourne en ring −1 dès le boot. VMware ESXi aussi. VirtualBox et VMware Workstation non. Ils s’appuient sur Windows ou Linux pour accéder au matériel, ce qui les place en type 2.

Le VMbus : le canal propriétaire entre Windows et Hyper-V

La partition parente ne parle pas directement au matériel physique comme avant. Elle passe par le VMbus, un bus virtuel propriétaire Microsoft qui relie la partition parente aux partitions enfants et à l’hyperviseur. Concrètement, quand une VM enfant a besoin d’accéder au réseau ou au disque, elle envoie une requête via le VMbus à la partition parente, qui dispose des vrais pilotes. La partition parente répond et retourne les données.

C’est ce mécanisme qui explique pourquoi Hyper-V n’a pas besoin de ses propres pilotes pour chaque matériel. Il délègue à Windows (partition parente), qui connaît le matériel. C’est une architecture hybride, mais le contrôle effectif du matériel est dans les mains de l’hyperviseur.

Hyper-V s’active à votre insu sous Windows 11 ?

Beaucoup d’utilisateurs découvrent qu’Hyper-V tourne sur leur machine sans l’avoir jamais activé manuellement. VBS (Virtualization Based Security) et Credential Guard, deux fonctions de sécurité activées par défaut sur Windows 11 éditions Pro et Enterprise, s’appuient sur Hyper-V pour isoler des zones mémoire critiques.

Si vous avez VBS actif, Hyper-V tourne en ring −1 sur votre machine même si vous ne créez aucune VM. Windows est déjà une partition parente. C’est aussi pourquoi VirtualBox et VMware Workstation perdent en performance ou refusent de démarrer certaines VM sur ces configurations. Ils ne peuvent pas accéder au ring 0 puisqu’Hyper-V l’a déjà pris.

Pour vérifier si Hyper-V est actif sur votre machine, ouvrez une invite de commande en administrateur et tapez.

systeminfo | findstr /i "hyper-v"

Si la ligne Exigences Hyper-V : un hyperviseur a été détecté apparaît, Hyper-V est déjà actif sur votre système.

La comparaison avec ESXi, Proxmox et KVM

VMware ESXi s’installe sur un serveur nu, sans OS préexistant. Son interface d’administration est accessible via un navigateur depuis un autre poste. C’est un type 1 pur. Aucun OS hôte, l’hyperviseur est la seule couche logicielle entre le matériel et les VM.

Proxmox VE repose sur Linux (Debian) et KVM. KVM est un module du noyau Linux qui transforme Linux en hyperviseur de type 1 en passant lui aussi par les extensions VT-x/AMD-V. Proxmox est donc aussi un type 1, avec Linux comme partition de gestion, exactement comme Windows l’est avec Hyper-V.

Hyper-V partage avec Proxmox/KVM cette architecture hybride où l’OS de gestion tourne dans une partition privilégiée plutôt que d’être absent. La différence entre Hyper-V et ESXi n’est pas une différence de type, c’est une différence d’architecture de gestion.

Quand utiliser Hyper-V plutôt qu’une alternative ?

Hyper-V est le bon choix dans les environnements Windows-centric (Windows Server, postes en entreprise avec Active Directory, déploiements hybrides avec Azure). L’intégration native évite d’installer un OS dédié et la partition parente Windows sert directement d’interface d’administration.

Si vous voulez de la virtualisation sur un PC personnel sous Windows 11 sans toucher à VBS ni à la compatibilité VirtualBox, désactiver Hyper-V (et VBS) reste possible depuis les fonctionnalités Windows. Mais désactiver VBS retire aussi les protections mémoire de Credential Guard, ce qui est un compromis à peser selon l’usage de la machine.

Pour de la virtualisation multi-OS, open source, ou sur du matériel Linux, Proxmox ou KVM seront plus flexibles. ESXi reste la référence pour les datacenters VMware.