Les applications de virtualisation ne fonctionnent pas : que faire ?
Lorsque vous installez une application de virtualisation sur un ordinateur Windows sur lequel Hyper-V ou des services associés sont installés, des erreurs peuvent souvent se produire. Les erreurs qui se produisent lorsque vous exécutez des VMs sur des applications de virtualisation non Hyper-V causent des problèmes importants. Cet article de blog explique les causes de ces erreurs, comment les corriger et comment exécuter d’autres applications de virtualisation sur un ordinateur équipé d’Hyper-V.
Contexte et principe de fonctionnement
Après avoir installé VMware Workstation, VMware Player ou Oracle VirtualBox sur un ordinateur Windows, vous pouvez rencontrer des erreurs lors du démarrage d’une machine virtuelle dans ces applications de virtualisation. Les erreurs se produisent même si les machines virtuelles Hyper-V ne sont pas en cours d’exécution à ce moment-là. Vous pouvez installer VMware Workstation et VirtualBox, et exécuter des machines virtuelles VMware et VirtualBox sur le même ordinateur, mais pas simultanément. Qu’est-ce qui cause ce problème avec Hyper-V ? Examinons cela de plus près.
VMware Workstation, VMware Player et VirtualBox sont des hyperviseurs de type 2, tandis que Hyper-V est un hyperviseur de type 1. Un hyperviseur de type 2 est installé sur le système d’exploitation qui fonctionne sur le matériel. Un hyperviseur de type 1 est installé au-dessus du matériel. Tous les hyperviseurs nécessitent des extensions de virtualisation du processeur, qui sont des jeux d’instructions pour la virtualisation matérielle : Intel VT-x ou AMD-V. Hyper-V prend le contrôle des extensions de virtualisation lors de l’amorçage de Windows. Ces extensions de virtualisation ne sont pas disponibles pour VMware Workstation et VirtualBox lors de l’amorçage de Windows. Un seul composant logiciel peut utiliser Intel VT-x ou AMD-V à la fois.
Cette incompatibilité est due à Hyper-V, car les extensions de virtualisation ne sont pas exposées aux hyperviseurs de type 2 installés sur une machine Windows où le rôle Hyper-V est activé.
Erreurs VMware Workstation :
VMware Workstation et Hyper-V ne sont pas compatibles. Enlevez le rôle Hyper-V du système avant d’exécuter VMware Workstation.
VMware Workstation et Device/Credential Guard ne sont pas compatibles. VMware Workstation peut être exécuté après avoir désactivé Device/Credential Guard.
Erreurs VirtualBox :
BSOD, tel que BSOD avec SYSTEM_SERVICE_EXCEPTION
VT-x n’est pas disponible (VER_VMX_NO_VMX). E_FAIL (0x80004005).
Une machine virtuelle VirtualBox fonctionne trop lentement et utilise le mode de paravirtualisation (émulation).
La situation la plus intéressante est celle où un utilisateur n’installe pas Hyper-V et rencontre néanmoins l’une des erreurs mentionnées précédemment lorsqu’il utilise VMware Workstation ou VirtualBox. L’erreur se produit lorsque les mises à jour automatiques de Windows sont activées. Avec les mises à jour (Windows 10 v1607 et les versions appropriées de Windows Server à partir de Windows Server 2016), certaines nouvelles fonctionnalités liées à Hyper-V sont installées et activées automatiquement sans le consentement de l’utilisateur Windows. Ces fonctionnalités sont Device Guard et Credential Guard. Windows met à jour les vulnérabilités connues, mais peut ajouter des problèmes et détruire une configuration qui fonctionne. C’est pourquoi de nombreux utilisateurs n’apprécient pas les mises à jour automatiques.
Device Guard est un groupe de fonctionnalités de sécurité dans Windows. L’idée derrière la mise en œuvre de cette fonctionnalité est de renforcer la sécurité contre l’exécution de code malveillant. Device Guard est disponible dans Windows 10, Windows Server 2019 et Windows Server 2019. Les conditions à remplir sont les suivantes : UEFI fonctionnant en mode natif et Secure Boot activé.
Credential Guard est une fonctionnalité qui permet de minimiser l’impact des attaques si un code malveillant est déjà en cours d’exécution, en isolant les identifiants de connexion du système et des utilisateurs afin de rendre leur compromission plus difficile.
Virtual Secure Mode (VSM) est une fonctionnalité qui exploite les extensions de virtualisation du processeur pour sécuriser les données dans une région isolée de la mémoire. HVCI signifie « intégrité du code protégée par l’hyperviseur ». LSA signifie « autorité de sécurité locale ».
La sécurité basée sur la virtualisation (VBS) est une catégorie de technologies qui utilise des extensions de virtualisation, notamment VSM, pour assurer la sécurité dans Windows. Le rôle Hyper-V est nécessaire pour que ces fonctionnalités fonctionnent (les outils de gestion Hyper-V ne sont pas nécessaires).
L’hyperviseur (Hyper-V) se charge en premier, puis le système d’exploitation (Windows) se charge. Hyper-V fournit une couche d’abstraction entre le matériel et le système d’exploitation. Un VSM permet le marquage de processus critiques spécifiques et de la mémoire qu’ils utilisent, car ils appartiennent à un système d’exploitation indépendant distinct contrôlé par Hyper-V. Le principe est similaire à l’isolation de deux VMs fonctionnant sur un hôte Hyper-V, chaque VM ne pouvant utiliser que les ressources matérielles qui lui sont attribuées.
Remarque : Si vous avez besoin d’un hyperviseur de type 1 de VMware, utilisez VMware ESXi et l’environnement VMware vSphere. Pour en savoir plus, consultez les articles de blog suivants : Hyper-V vs VMware, VMware Workstation vs VMware Player, et Comment installer ESXi sur Hyper-V.
Voyons en détail comment résoudre le problème d’incompatibilité entre Hyper-V et d’autres applications de virtualisation.
Méthode 1 : désinstaller Hyper-V dans l’interface graphique
Vérifiez les informations système relatives à la configuration Windows en exécutant la commande suivante dans CMD :
msinfo32.exe
Une fenêtre Informations système s’ouvre. Sur la capture d’écran suivante, vous pouvez voir que Hyper-V est activé (un hyperviseur a été détecté) et que la sécurité basée sur la virtualisation Device Guard est en cours d’exécution. Vous pouvez maintenant enlever ces fonctionnalités.
Sachez que les fonctionnalités suivantes liées à Hyper-V ne seront plus disponibles après l’enlèvement de Hyper-V :
- Hyper-V
- Credential Guard et Device Guard
- Plateforme de machines virtuelles
- Windows Sandbox
- WSL2.
Enlevez la fonctionnalité Hyper-V dans l’interface utilisateur graphique (GUI) par le Panneau de configuration, Ajouter des rôles et des fonctionnalités.
Sous Windows 10, ouvrez le Panneau de configuration, cliquez sur Programmes et fonctionnalités, puis cliquez sur Activer ou désactiver des fonctionnalités Windows.
La fenêtre Fonctionnalités Windows s’ouvre.
Décochez la case Hyper-V et cliquez sur OK.
Pour terminer l’enlèvement d’Hyper-V, redémarrez l’ordinateur.
Les étapes pour enlever Hyper-V sous Windows 10 et Windows Server 2016 sont similaires.
Sous Windows Server 2016, ouvrez Gestionnaire de serveur et cliquez sur Gérer > Enlever les rôles et fonctionnalités. Dans l’assistant Enlever des rôles et des fonctionnalités , accédez à l’étape Rôles de serveur et désélectionnez Hyper-V. Cliquez sur Suivant à chaque étape pour continuer. Un redémarrage est nécessaire pour terminer la suppression du rôle Hyper-V.
Méthode 2 : utiliser PowerShell pour désactiver la fonctionnalité Hyper-V
Vous pouvez effectuer une action similaire en utilisant l’interface de ligne de commande plutôt que l’interface graphique.
Connectez-vous à PowerShell en tant qu’administrateur et exécutez la commande pour désactiver la fonctionnalité Hyper-V :
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor
Redémarrez votre machine hôte :
shutdown -r -t 0
Méthode 3 : désactiver Hyper-V par l’intermédiaire de BCDedit
L’idée derrière cette méthode est de modifier les données d’amorçage et de désactiver le démarrage de Hyper-V sans désinstaller le rôle Hyper-V.
Connectez-vous à PowerShell en tant qu’administrateur ou exécutez la commande from une invite de commande élevée pour désactiver Hyper-V :
bcdedit /set hypervisorlaunchtype off
Si vous devez réactiver Hyper-V et rétablir la valeur par défaut, exécutez cette commande :
bcdedit /set hypervisorlaunchtype auto
Pour plus de contrôle et de commodité, désactivez le démarrage rapide dans Windows 10. Ouvrez l’éditeur de registre Windows et accédez à :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerPower
Définissez le paramètre HiberbootEnabled sur 0
Si vous devez parfois utiliser des VMs Hyper-V, créez deux entrées pour le chargeur d’amorçage Windows : une pour démarrer Windows avec Hyper-V et une autre pour démarrer Windows sans Hyper-V. Ensuite, sélectionnez l’option requise avant de démarrer Windows. Cette approche vous évite d’avoir à exécuter manuellement des commandes dans PowerShell chaque fois que vous devez activer ou désactiver Hyper-V.
bcdedit /copy "{current}" /d "No Hyper-V"
« L’entrée a été copiée avec succès dans {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. »
Copiez et collez votre valeur à la place de xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
bcdedit /set "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" hypervisorlaunchtype off
Redémarrez l’ordinateur.
Une fois votre ordinateur redémarré, vous devriez voir deux options dans le Gestionnaire de démarrage Windows.
Si vous souhaitez enlever l’entrée de démarrage No Hyper-V amorçage, use the /delete option for bcdedit.
Get a list of the current amorçages:
bcdedit /v
A list of all amorçages avec leurs identifiants est affichée dans le résultat. Copiez l’ID de l’entrée que vous souhaitez enlever, puis exécutez la commande suivante :
bcdedit /delete "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
Méthode 4 : désinstaller le rôle Hyper-V dans PowerShell avec dism.exe
Cette méthode consiste à utiliser l’outil Deployment Image Servicing and Management dans l’interface de ligne de commande pour désinstaller Hyper-V.
Connectez-vous à CMD ou PowerShell en tant qu’administrateur. Exécutez la commande suivante pour désinstaller Hyper-V :
dism.exe /Online /Disable-Feature:Microsoft-Hyper-V
Si vous souhaitez réinstaller Hyper-V , utilisez cette commande :
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Méthode 5 : désactiver la sécurité basée sur la virtualisation dans Windows
Cette méthode permet de désactiver Device Guard et Credential Guard, qui sont des fonctionnalités liées à Hyper-V.
Ouvrez l’éditeur de stratégie de groupe pour un ordinateur local. L’éditeur de stratégie de groupe est disponible dans Windows 10 Pro, Enterprise et Education. Dans l’invite de commande, exécutez gpedit.msc
Accédez à Stratégie de l’ordinateur local > Configuration de l’ordinateur > Modèles d’administration > Système > Device Guard
Double-cliquez sur Activer la sécurité basée sur la virtualisation. Par défaut, le statut de ce paramètre est Non configuré.
Dans la fenêtre qui s’ouvre, sélectionnez Désactivé et cliquez sur OK pour enregistrer les paramètres et fermer la fenêtre.
Modifier le registre comme alternative
Dans Windows 10 Home, où l’éditeur de stratégie de groupe n’est pas présent, vous pouvez désactiver la sécurité basée sur la virtualisation dans le registre Windows.
Créez une sauvegarde du registre Windows avant de modifier les paramètres du registre afin d’éviter les erreurs et les problèmes.
Ouvrez l’éditeur de registre. Exécutez regedit dans la ligne de commande qui doit être ouverte en tant qu’administrateur.
Accédez à HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard
Créez l’entrée EnableVirtualizationBasedSecurity si celle-ci est manquante. Pour créer une nouvelle entrée, cliquez avec le bouton droit sur un emplacement vide dans le répertoire DeviceGuard , puis dans le menu contextuel, cliquez sur Nouvelle > valeur DWORD (32 bits). Entrez le EnableVirtualizationBasedSecurity nom de cette entrée de registre. Par défaut, les données définies pour cette entrée doivent être 0 (voir la capture d’écran suivante). Vous pouvez double-cliquer sur EnableVirtualizationBasedSecurity et définir 0 manuellement.
Accédez à HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Lsa
Créez une nouvelle entrée de registre dans le répertoire Lsa . Cliquez avec le bouton droit sur un espace vide dans le volet droit de la fenêtre de l’éditeur de registre. Dans le menu contextuel, cliquez sur Nouvelle > valeur DWORD (32 bits).
Entrez le LsaCfgFlags nom de cette valeur. Cette valeur doit être définie sur 0.
Fermez l’éditeur de registre et redémarrez votre ordinateur.
Vous pouvez exécuter les commandes suivantes dans PowerShell (en tant qu’administrateur) pour désactiver Device Guard et Credential Guard au prochain amorçage de Windows.
Montez une partition système UEFI sur le lecteur X: (sélectionnez un volume inutilisé) :
mountvol X: /s
Copiez le fichier C:WindowsSystem32SecConfig.efi vers X:EFIMicrosoftBootSecConfig.efi avec une option permettant de remplacer le fichier s’il existe déjà. Ce fichier est une image d’amorçage pour l’outil de configuration de sécurité Windows.
copy %WINDIR%System32SecConfig.efi X:EFIMicrosoftBootSecConfig.efi /Y
Créez une nouvelle option dans le menu d’amorçage avec l’ID {0cb3b571-2f2e-4343-a879-d86a476d7215} et le DebugTool Nom :
bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
Définissez l’option d’amorçage que vous avez créée à l’étape précédente pour amorcer sur EFIMicrosoftBootSecConfig.efi:
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "EFIMicrosoftBootSecConfig.efi"
Configurez le gestionnaire d’amorçage Windows pour que la nouvelle entrée soit celle par défaut au prochain redémarrage. Après cela, redémarrez Windows qui devrait revenir à un amorçage normal.
bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
Configurez le chargeur d’amorçage pour qu’il transmette les Options DISABLE-LSA-ISO,DISABLE-VBS au fichier SecConfig.efi lorsque le chargeur d’amorçage lance le fichier.
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
Définissez la partition du lecteur démarré sur le lecteur X :
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
Démontez le lecteur X : du système :
mountvol X: /d
Méthode 6 : mettre à jour VMware Workstation
Si vous disposez de Windows 10 version 2004 (20H1) build 19041 ou plus récent sur votre ordinateur physique, vous pouvez mettre à niveau VMware Workstation vers VMware Workstation 15.5.6 ou plus récent et exécuter des VMs VMware sur votre machine Windows sans désactiver/désinstaller les fonctionnalités Hyper-V et Virtualization Based Security (VBS), y compris Device Guard et Credential Guard.
En raison des nombreuses plaintes de clients, Microsoft et VMware ont décidé de développer un projet commun qui adopte les API Microsoft Windows Hypervisor Platform (WHP) afin de permettre aux hyperviseurs de type 2, tels que VMware Workstation, de fonctionner sur un hôte où Hyper-V est activé. Ces API permettent aux applications de gérer les ressources du processeur, de lire/écrire les valeurs du registre, d’arrêter le fonctionnement du processeur et de générer des interruptions.
VMware Workstation avant la version 15.5.5 utilise un moniteur de machine virtuelle (VMM) qui a un accès direct à un processeur et à des jeux d’instructions de virtualisation (Intel VT-x ou AMD-V). Un VMM fonctionne en mode privilégié. Si les fonctionnalités de sécurité basées sur la virtualisation sont activées sur un hôte Windows, une couche d’hyperviseur supplémentaire (Hyper-V) est ajoutée entre le matériel et Windows. Hyper-V a un accès direct aux fonctionnalités du processeur utilisées pour la virtualisation matérielle, et le VMM n’a pas accès aux fonctionnalités de virtualisation du processeur.
VMware a apporté des modifications à l’architecture de VMware Workstation 15.5.6 afin de permettre à son produit d’utiliser les API WHP de Microsoft et de résoudre le problème de compatibilité. VMM peut désormais s’exécuter au niveau utilisateur (et non en mode privilégié) à l’aide des API WHP et exécuter des VMs sans accès direct aux extensions de virtualisation du processeur. Ce mode est appelé « User Level Monitor » (ULM) ou mode « Host VBS ». Si vous désinstallez les fonctionnalités liées à Hyper-V de votre hôte Windows, VMware Workstation le détecte automatiquement et VMM passe en mode d’accès direct aux extensions de virtualisation du processeur (fonctionnant en mode privilégié).
Windows Hypervisor Platform (WHP) doit être installé sur une machine Windows physique sur laquelle Hyper-V est activé pour permettre à VMware Workstation d’exécuter des VMs VMware sur cette machine. Installez la fonctionnalité Windows Hypervisor Platform dans le Panneau de configuration en cliquant sur Activer ou désactiver des fonctionnalités Windows.
Vous pouvez ainsi mettre à jour Windows 10 et VMware Workstation sur votre machine physique vers des versions qui prennent en charge l’exécution des fonctionnalités liées à Hyper-V et des VMs VMware Workstation sur la même machine.
Limitations du mode VBS hôte :
- La plate-forme Windows Hypervisor n’est pas prise en charge sur Windows Server 2016 et les autres versions et éditions de Windows Server. Par conséquent, VMware Workstation ne peut pas exécuter de VMs en mode VBS hôte sur des machines physiques exécutant Windows Server.
- La virtualisation imbriquée n’est pas prise en charge. Vous ne pouvez pas exécuter de VMs imbriquées (VMs à l’intérieur de VMs VMware Workstation).
- Les VMs VMware peuvent fonctionner plus lentement.
- Les compteurs de surveillance des performances x86 (PMC) ne sont pas pris en charge.
- La fonctionnalité de clés de protection en mode utilisateur (PKU) n’est pas disponible.
- Les fonctionnalités de mémoire transactionnelle restreinte (RTM) et d’élision de verrouillage matériel (HLE) ne sont pas disponibles.
VirtualBox et Hyper-V
VirtualBox peut coexister avec Hyper-V, Device Guard et Credential Guard à partir de VirtualBox 6.0. VirtualBox 6 peut fonctionner avec les API Hyper-V de la même manière que VMware Workstation sur Windows 10 v1803 x64.
Ces fonctionnalités doivent être activées sur une machine Windows hôte pour permettre à VirtualBox de fonctionner avec les API Hyper-V :
- Hyper-V
- Plateforme hyperviseur Windows
Si la fonctionnalité Hyper-V est activée, mais que la fonctionnalité Plateforme hyperviseur Windows est désactivée, dans Accélération du système > dans le résumé de la configuration de la VM, vous pouvez voir que le mode de paravirtualisation est activé. Si vous essayez de démarrer une VM, VirtualBox vous rappelle que vous devez activer la plate-forme Windows Hypervisor et affiche le message d’erreur.
Message d’erreur :
WHvCapabilityCodeHypervisorPresent est FALSE ! Assurez-vous d’avoir activé la fonctionnalité « Windows Hypervisor Platform ».
(VERR_NEM_NOT_AVAILABLE).
VT-x n’est pas disponible (VERR_VMX_NO_VMX).
Si les fonctionnalités Hyper-V requises dans Windows sont activées, les informations suivantes s’affichent pour la machine virtuelle dans la section Système :
Accélération : VT-x/AMD-v, pagination imbriquée, paravirtualisation Hyper-V
La machine virtuelle devrait démarrer correctement. Une icône représentant une tortue verte s’affiche dans le panneau inférieur de la fenêtre VirtualBox. Cette icône indique qu’une machine virtuelle fonctionne en mode de paravirtualisation Hyper-V-V au lieu du mode natif généralement utilisé par VirtualBox lorsqu’il interagit directement avec les extensions de virtualisation du processeur. Les performances des VMs VirtualBox se dégradent sur les machines sur lesquelles Hyper-V et les fonctionnalités associées sont activées. Vous pouvez désactiver ou enlever Hyper-V comme expliqué précédemment afin d’exécuter les VMs sur VirtualBox en mode natif en utilisant directement les extensions de virtualisation du processeur.
Lisez également la comparaison VirtualBox vs Hyper-V et la comparaison VirtualBox vs VMware .
Conclusion
Les nouvelles fonctionnalités de Windows telles que la sécurité basée sur la virtualisation (Device Guard et Credential Guard), Windows Sandbox, WSL qui utilisent le moteur Hyper-V causent de nombreux problèmes aux utilisateurs, administrateurs et développeurs de logiciels utilisant d’autres hyperviseurs tels que VMware Workstation, VirtualBox, QEMU et Google Android Emulator sur des machines Windows. Il existe deux approches pour résoudre ces problèmes d’incompatibilité : Désactiver/désinstaller Hyper-V ou utiliser de nouvelles versions d’applications de virtualisation qui prennent en charge les API Hyper-V, telles que l’API Windows Hypervisor Platform fournie par Microsoft.
L’exécution de VMs sur VirtualBox, VMware Workstation et d’autres hyperviseurs sur des machines équipées d’Hyper-V à l’aide d’API peut dégrader les performances des VMs non Hyper-V. La sauvegarde des données est cruciale en cas de défaillance des applications de virtualisation. Si vous n’avez pas encore choisi la meilleure solution de sauvegarde Hyper-V pour votre environnement, pensez à NAKIVO Backup & Replication. Cette solution offre une sauvegarde robuste, une protection contre les ransomwares, une reprise après sinistre et bien plus encore. Téléchargez l’Édition gratuite pour découvrir la solution en action.
