Hyper-V : the hypervisor is not running, le guide

Quand Hyper-V affiche the hypervisor is not running, la couche ne s'est tout simplement jamais réveillée à ce démarrage, et rien n'est réellement cassé. Ça fait des années que je materne Hyper-V sur des machines de labo et des portables de dev, et ce truc plante pour cinq raisons, pas une de plus, qui se déclenchent dans un ordre assez prévisible. Du coup je les passe en revue de haut en bas. Je répare la première barrière qui coince, je reboote, je réessaie. Ça vaut mieux que de cocher des cases au hasard jusqu'à ce que l'une fonctionne, ce qui fait perdre un après-midi à la plupart des gens. Virtualisation BIOS, la fonctionnalité Hyper-V, le flag de boot, un hyperviseur rival ou la VBS, puis les services.

Tu cliques sur Démarrer pour lancer une VM et Hyper-V te claque la porte au nez : "The virtual machine could not be started because the hypervisor is not running", ou dans sa formulation plus ancienne "Virtual machine could not be started because the hypervisor is not running". Et une fois sur deux, le Gestionnaire des tâches est juste là, à afficher Virtualisation : désactivée, histoire de bien remuer le couteau. On dirait que Windows s'est bouffé lui-même. Eh bien non. Ça fait des années que je materne Hyper-V sur des machines de labo et des portables de dev, et franchement ? Ce truc plante pour cinq raisons, pas une de plus, et elles ont tendance à se déclencher dans un ordre assez prévisible. Du coup je les passe en revue de haut en bas. Je répare la première barrière qui coince, je reboote, je réessaie. Ça vaut mieux que de cocher des cases au hasard jusqu'à ce que l'une d'elles fonctionne, ce qui est la façon dont la plupart des gens y perdent un après-midi.

Ce que veut vraiment dire cette erreur

Voilà le détail qui fait tilt avec cette erreur. Hyper-V est un hypervisor de Type-1. Ce qui est une façon savante de dire que ce n'est pas un programme que Windows fait tourner : c'est une fine couche qui se charge avant Windows, tout en bas au boot, directement sur les extensions de virtualisation du CPU. Donc quand Windows dit "the hypervisor is not running", ça veut dire en réalité que cette couche ne s'est jamais réveillée à ce démarrage. Et les raisons sont vite comptées. Les extensions CPU sont désactivées. Ou personne n'a dit à Windows de lancer l'hyperviseur au boot. Ou autre chose a chopé ces extensions en premier : un hyperviseur rival, par exemple, ou bien la Virtualization-Based Security coincée dans un sale état. Tu remarques ce qui ne figure pas dans cette liste ? La corruption. La plupart du temps, rien n'est réellement cassé. La couche ne s'est juste pas chargée, et ta VM ne peut pas tourner sur du vide.

Barrière 1 : activer la virtualisation dans le BIOS/UEFI

Commence ici. Toujours. C'est celle sur laquelle je tombe le plus souvent, et elle a un vrai faible pour les machines toutes neuves et pour tout boîtier dont le CMOS a été réinitialisé. Reboote dans le setup du firmware (martèle Suppr, F2, F10 ou F1 à l'allumage, la touche c'est la loterie selon le constructeur) et active l'extension de virtualisation. Le nom dépend de la marque de ton silicium :

• Intel : active Intel Virtualization Technology (VT-x). Et VT-d aussi, si ton firmware daigne le lister.
• AMD : tu cherches le SVM Mode (Secure Virtual Machine). C'est en général planqué un menu ou deux plus profond que ce qui serait raisonnable.

Et maintenant le truc que tout le monde zappe : sauvegarde, puis fais un arrêt complet, pas un redémarrage. Pas mal de firmwares ne valident le changement que sur un démarrage à froid. Donc un simple reboot te laisse à fixer exactement la même erreur, en jurant que le réglage n'a servi à rien. De retour dans Windows, prouve que ça a pris :

PS> Get-ComputerInfo -Property "HyperV*"
HyperVRequirementVirtualizationFirmwareEnabled : True
HyperVRequirementVMMonitorModeExtensions : True

Pas adepte de PowerShell ? Ouvre le Gestionnaire des tâches, Performance, Processeur et regarde le panneau du bas pour Virtualisation : activée. Même réponse, beaucoup moins de frappe au clavier.

Barrière 2 : vérifier que la fonctionnalité Hyper-V est installée

VT-x est actif et tu es toujours coincé ? Là, je commencerais à suspecter le rôle lui-même. Peut-être qu'il n'a jamais fini de s'installer. Peut-être qu'une installation à moitié bâclée l'a laissé un peu là sans y être vraiment, dans cet étrange état intermédiaire. Dans tous les cas, l'hyperviseur ne se chargera pas. Moi je le réinstalle proprement depuis un PowerShell élevé et je laisse Windows démêler tout seul son bazar :

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
# reboot when prompted, then verify:
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor

State doit afficher Enabled. Et là, le piège qui attrape des gens semaine après semaine : sur Windows 11/10 Home, le rôle Hyper-V n'est pas désactivé, il n'existe tout simplement pas. Du tout. Tu peux cliquer jusqu'à t'en faire mal au poignet, il n'apparaîtra pas. Pro, Education ou Enterprise, c'est le ticket d'entrée. Cela dit, si tout ce que tu veux c'est WSL2 ou Docker, tu n'as pas réellement besoin du rôle complet : active VirtualMachinePlatform à la place. Ça te donne l'hyperviseur sans traîner toute la pile de gestion Hyper-V, et ça tourne très bien sur Home.

Barrière 3 : configurer le démarrage de l'hyperviseur au boot

Celle-là c'est ma préférée, et je crois que c'est parce que la solution tient en une seule ligne alors que la cause est d'une mesquinerie merveilleuse. La fonctionnalité peut être installée à la perfection et l'hyperviseur refuser quand même de se lancer, parce qu'un flag de boot-configuration séparé a le dernier mot. Et toutes sortes de trucs désactivent ce flag dans ton dos. L'anti-triche d'un jeu qui veut les extensions pour lui tout seul. Un VMware un peu vieux. La moitié des guides "répare ta VM" qui traînent partout sur le web. Ils le désactivent, font ce qu'ils sont venus faire, et ne prennent jamais la peine de le réactiver. Va voir :

bcdedit /enum {current}
# look for: hypervisorlaunchtype   Auto
# if it says Off, turn it back on:
bcdedit /set hypervisorlaunchtype auto

Reboot. Les flags de boot ne sont lus qu'au boot, donc rien ne se passe tant que tu ne le fais pas. Et honnêtement, si tout le reste a l'air nickel et que l'erreur est toujours là, je parierais sur cette ligne. Elle est discrètement derrière une énorme part des cas de "hypervisor is not running" que j'ai croisés, peut-être plus que n'importe quelle autre cause à elle seule.

Attention. Si bcdedit te renvoie "The integer data is not valid" ou te refuse carrément, ça veut presque toujours dire une chose : tu n'es pas dans une invite élevée. Ferme-la. Relance PowerShell ou l'Invite de commandes en tant qu'administrateur, relance la même commande, et ça passera.

Barrière 4 : régler les conflits VMware / VirtualBox / VBS

Au niveau matériel, une seule chose a le droit de posséder les extensions de virtualisation du CPU. Une. Donc si autre chose les a déjà chopées, Hyper-V est verrouillé dehors, point, et tu auras l'erreur peu importe à quel point les barrières 1 à 3 ont l'air impeccables. Les coupables habituels que je vais traquer :

• VMware Workstation 15 ou plus ancien refuse tout simplement de partager le CPU avec Hyper-V. C'est un bras de fer architectural, pas une case à cocher dont tu pourras le dissuader. Passe à Workstation 16+, qui parle le Windows Hypervisor Platform et cohabite sans problème, ou accepte que tu devras désactiver Hyper-V pour garder le vieux VMware.
• VirtualBox en dessous de la v6 fait exactement le même cinéma. Mets-le à jour et tout le problème s'évapore, parce que le VirtualBox moderne s'appuie sur le backend Hyper-V au lieu de se bagarrer avec.
• La Virtualization-Based Security (VBS), c'est-à-dire l'Isolation du noyau, l'Intégrité de la mémoire, Credential Guard et cette bande-là, s'appuie elle aussi sur l'hyperviseur. La plupart du temps, ils cohabitent sans histoires. Mais une VBS à moitié activée, ou coincée par une stratégie de groupe quelque part, tuera tes VMs en silence. C'est celle qui met le plus longtemps à être ne serait-ce que suspectée. Si tu n'en as pas besoin, désactive Isolation du noyau, Intégrité de la mémoire dans la Sécurité Windows, reboote, et réessaie.

Avant de te mettre à tout désactiver, sache ce que tu sacrifies. WSL2, Docker Desktop, le bac à sable Windows, Hyper-V, ils boivent tous au même puits. Ils ont tous besoin de cet hyperviseur. Tue-le pour faire plaisir à un vieux VMware et tu viens de les flinguer avec lui, en général des semaines plus tard, bien après avoir oublié que c'est pour ça que tes conteneurs ont cessé de fonctionner. Alors je vais dire ce que je dis à tout le monde : traîne le logiciel en conflit dans cette décennie au lieu de mutiler Hyper-V. C'est la voie que je prendrais, en tout cas.

Barrière 5 : services et réparation des fichiers système

Tu arrives quasiment jamais jusqu'ici. Mais quand les quatre barrières précédentes passent et qu'une VM refuse toujours de démarrer, c'est en général l'une de deux choses : des services de gestion à l'arrêt, ou un magasin de composants qui a pris des dégâts. Relance les services et répare l'image :

Start-Service vmcompute
Start-Service vmms
Set-Service vmms -StartupType Automatic

# repair Windows component store if services refuse to start
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Et si même ça ne bouge pas, voici l'option nucléaire : arrache le rôle et remets-le. Lance Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All, reboote, puis réactive-le. Ça reconstruit l'espace de noms WMI et l'entrée de boot de l'hyperviseur depuis zéro, ce qui a tendance à évacuer tout le foutoir que les étapes précédentes n'arrivaient pas à atteindre. Personnellement je n'ai jamais eu besoin d'aller plus loin que ça.

Vérifier que c'est réglé

Une habitude qui m'a évité pas mal de tracas. Après le moindre changement et le reboot qui suit, confirme que l'hyperviseur s'est bel et bien chargé avant de te remettre à maudire Hyper-V. Une ligne tranche la question :

PS> Get-CimInstance Win32_ComputerSystem | Select HypervisorPresent
HypervisorPresent
-----------------
True

PS> Get-VM | Start-VM   # your VMs now start

HypervisorPresent revient à True ? Alors la couche est debout et cette erreur d'origine est morte. Si c'est toujours False après avoir passé les cinq barrières, ne panique pas, retourne juste dans le BIOS et regarde à nouveau. Une mise à jour de firmware réinitialisera joyeusement ce réglage de virtualisation sans broncher, donc ce que tu as réparé mardi peut être de nouveau désactivé en douce dès vendredi.

Sources et pour aller plus loin

• Microsoft Learn, Hyper-V on Windows
• Microsoft Learn, Windows Server troubleshooting

Questions fréquentes