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 survenir. Les erreurs qui se produisent lors de l’exécution de VMs sur des applications de virtualisation autres qu’Hyper-V entraînent des problèmes importants. Cet article de blog explique les causes de ces erreurs, comment les résoudre 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 une machine Windows, vous pourriez rencontrer des erreurs lors du démarrage d’une VM dans ces applications de virtualisation. Les erreurs surviennent même si les VM Hyper-V ne sont pas en cours d’exécution à ce moment-là. Vous pouvez installer VMware Workstation et VirtualBox, et exécuter des VM VMware et des VM VirtualBox sur le même ordinateur, mais pas simultanément. Qu’est-ce qui cause ce problème avec Hyper-V? Examinons 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é sur le 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 lorsque Windows démarré. Ces extensions de virtualisation ne sont pas disponibles pour VMware Workstation et VirtualBox lorsque Windows se charge. Un seul composant logiciel peut utiliser Intel VT-x ou AMD-V à la fois.
Cette incompatibilité est causée par 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 de VMware Workstation :
VMware Workstation and Hyper-V are not compatible. Remove the Hyper-V role from the system before running VMware Workstation.
VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential guard.
Erreurs de VirtualBox :
BSOD, such as BSOD with SYSTEM_SERVICE_EXCEPTION
VT-x is not available (VER_VMX_NO_VMX). E_FAIL (0x80004005).
A VirtualBox VM works too slowly and uses the paravirtualisation (emulation) mode.
La situation la plus intéressante est quand un utilisateur n’installe pas Hyper-V et rencontre néanmoins l’une des erreurs mentionnées précédemment lors de l’utilisation de 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. Les mises à jour Windows corrigent des vulnérabilités connues mais peuvent ajouter des problèmes et détruire une configuration fonctionnelle. C’est pourquoi de nombreux utilisateurs n’aiment pas les mises à jour automatiques.
Device Guard est un groupe de fonctionnalités de sécurité dans Windows. L’idée de la mise en œuvre de cette fonctionnalité est de renforcer l’exécution du code malveillant. Device Guard est disponible dans Windows 10, Windows Server 2019 et Windows Server 2019. Les exigences principales sont : UEFI fonctionnant en mode natif et Secure Boot activé. Credential Guard est une fonctionnalité visant à minimiser l’impact des attaques si un code malveillant est déjà en cours d’exécution en isolant les secrets du système et de l’utilisateur pour rendre leur compromission plus difficile.
Virtual Secure Mode (VSM) est une fonctionnalité qui tire parti des extensions de virtualisation du processeur qui sécurisent les données dans une région isolée de la mémoire. HVCI est l’intégrité de code protégée par hyperviseur. LSA est l’Autorité de Sécurité Locale.
Sécurité Basée sur la Virtualisation (VBS) est une classe de technologies utilisant des extensions de virtualisation, y compris VSM, pour assurer la sécurité sous 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 comme appartenant à un système d’exploitation indépendant contrôlé par Hyper-V. Le principe est similaire à l’isolation de deux VM s’exécutant sur un hôte Hyper-V lorsque chaque VM ne peut utiliser que les ressources matérielles qui lui sont provisionnées.
Remarque : Si vous avez besoin d’un hyperviseur de type 1 de VMware, utilisez VMware ESXi et l’environnement VMware vSphere. En savoir plus dans ces articles de blog : Hyper-V contre VMware, VMware Workstation ou VMware Player ?, et Comment installer ESXi sur Hyper-V.
Explorons comment résoudre en détail le problème d’incompatibilité de 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 concernant la configuration de Windows en exécutant la commande suivante dans CMD :
msinfo32.exe
Une fenêtre d’information système s’ouvre. Sur la capture d’écran suivante, vous voyez que Hyper-V est activé (un hyperviseur a été détecté), et la sécurité basée sur Device Guard Virtualization est en cours d’exécution. Vous pouvez maintenant retirer ces fonctionnalités.
Soyez conscient que les fonctionnalités liées à Hyper-V suivantes ne seront plus disponibles après avoir retiré Hyper-V :
- Hyper-V
- Credential Guard and Device Guard
- Virtual Machine Platform
- Windows Sandbox
- WSL2.
Retirez la fonctionnalité Hyper-V dans l’interface utilisateur graphique (GUI) en utilisant Control Panel, Add Roles, et l’assistant Features.
Dans Windows 10, ouvrez Control Panel, cliquez sur Programs and Features, puis cliquez sur Turn Windows features on or off.
La fenêtre Windows Features s’ouvre.
Désélectionnez la case à cocher Hyper-V, et appuyez sur OK.
Pour terminer le retrait de Hyper-V, redémarrez l’ordinateur.
Les étapes pour retirer Hyper-V sur Windows 10 et Windows Server 2016 sont similaires.
Dans Windows Server 2016, ouvrez Server Manager et cliquez sur Manage > Remove Roles and Features. Dans l’assistant Remove Roles and Features , allez à l’étape Server Roles et désélectionnez Hyper-V. Appuyez sur Next à chaque étape pour continuer. Un redémarrage est nécessaire pour terminer le retrait du rôle Hyper-V.
Méthode 2 : Utiliser PowerShell pour désactiver la fonctionnalité Hyper-V
Vous pouvez faire 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 en utilisant BCDedit
L’idée de cette méthode est de modifier les données de configuration de démarrage 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 à partir d’une invite de commande avec élévation de privilèges 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 utiliser occasionnellement des VM Hyper-V, créez deux entrées pour un chargeur de démarrage de Windows : une pour démarrer Windows avec Hyper-V et une autre pour démarrer Windows sans Hyper-V. Ensuite, sélectionnez l’option nécessaire avant de démarrer Windows. Cette approche vous évite d’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"
"The entry was successfully copied to {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 que votre ordinateur a redémarré, vous devriez voir deux options dans le gestionnaire de démarrage Windows.
Si vous voulez retirer l’entrée de démarrage No Hyper-V , utilisez l’option /delete pour bcdedit.
Obtenez une liste des entrées de démarrage actuelles :
bcdedit /v
Une liste de toutes les entrées avec leurs identificateurs s’affiche dans la sortie. Copiez l’identifiant de l’entrée que vous souhaitez retirer, et 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
L’idée de cette méthode est d’utiliser l’outil de gestion et de maintenance d’images de déploiement 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 Installer Hyper-V à nouveau, utilisez cette commande :
dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All
Méthode 5 : Éteindre la sécurité basées sur la virtualisation dans Windows
Cette méthode est utilisée pour désactiver Device Guard et Credential Guard, qui sont des fonctionnalités liées à Hyper-V. Ouvrez l’Éditeur de politique de groupe pour un ordinateur local. L’Éditeur de politique de groupe est disponible à l’adresse Windows 10 Pro, Enterpriseet Education. Dans l’invite de commande, exécutez gpedit.msc
Accédez à Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard
Double-cliquez sur Turn On Virtualization Based Security. Par défaut, le statut de ce paramètre est Not configured.
Dans la fenêtre qui s’ouvre, sélectionnez Disabled puis cliquez sur OK pour enregistrer les paramètres, puis fermez la fenêtre.
Modifier le Registre comme alternative
Sous Windows 10 Édition Familiale, où l’Éditeur de politique de groupe n’est pas présent, vous pouvez désactiver la sécurité basée sur la virtualisation dans le Registre Windows.
Effectuez une sauvegarde du registre Windows avant de modifier ses paramètres afin d’éviter toute erreur ou tout problème.
Ouvrez l’Éditeur du 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 n’existe pas. Pour créer une nouvelle entrée, cliquez avec le bouton droit de la souris sur un emplacement vide dans le répertoire DeviceGuard et, dans le menu contextuel, cliquez sur New > DWORD (32-bit) Value. Saisissez le nom EnableVirtualizationBasedSecurity pour cette entrée de registre. Par défaut, la valeur de cette entrée doit ê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 Registry Editor . Dans le menu contextuel, cliquez sur New > DWORD (32-bit) Value.
Saisissez le nom LsaCfgFlags pour cette valeur. Cette valeur doit être définie sur 0.
Fermez l’Éditeur du Registre, puis 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 to X:EFIMicrosoftBootSecConfig.efi en choisissant de le remplacer s’il existe déjà. Ce fichier est une image d’amorçage pour l’outil de configuration de la 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 nom DebugTool :
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 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 devienne l’entrée par défaut lors du prochain redémarrage. Après, redémarrez : Windows devrait revenir à un démarrage 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 lorsqu’il lance ce dernier.
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
Définissez la partition du disque démarré sur le disque X: :
bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
Démontez le disque X: du système :
mountvol X: /d
Méthode 6 : Mise à jour de VMware Workstation
Si votre ordinateur physique exécute Windows 10 version 2004 (20H1), build 19041 ou une version plus récente, vous pouvez mettre à niveau VMware Workstation vers la version 15.5.6 ou une version plus récente et exécuter des VMs VMware sur votre machine Windows sans avoir à désactiver ni désinstaller les fonctionnalités Hyper-V et de sécurité basée sur la virtualisation (VBS), notamment Device Guard et Credential Guard.
En raison des nombreuses plaintes formulées par les clients, Microsoft et VMware ont décidé de développer un projet commun qui adopte les API de la plateforme d’hyperviseur Microsoft Windows (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 et d’écrire des valeurs de registre, d’interrompre le fonctionnement du processeur et de générer des interruptions.
Les versions de VMware Workstation antérieures à la version 15.5.5 utilisent un moniteur de machine virtuelle (VMM) qui dispose d’un accès direct au processeur et aux 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 alors ajoutée entre le matériel et Windows. Hyper-V dispose d’un accès direct aux fonctionnalités du processeur utilisées pour la virtualisation matérielle, tandis que 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é. Le VMM peut désormais fonctionner 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 VBS hôte. Si vous désinstallez les fonctionnalités liées à Hyper-V de votre hôte Windows, VMware Workstation le détecte automatiquement et VMM bascule vers l’accès direct aux extensions de virtualisation du processeur (fonctionnant en mode privilégié).
La plateforme Windows Hypervisor Platform (WHP) doit être installée 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 Turn Windows features on or off.
Vous pouvez ainsi mettre à jour Windows 10 et VMware Workstation sur votre machine physique vers des versions offrant la prise en charge de 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 plateforme d’hyperviseur Windows n’est pas prise en charge sur Windows Server 2016 ni sur 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 fonctionnant sous 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 la version 6.0 de VirtualBox. VirtualBox 6 peut fonctionner avec les API Hyper-V de la même manière que VMware Workstation sous Windows 10 v1803 x64.
Ces fonctionnalités doivent être activées sur une machine hôte Windows pour permettre à VirtualBox de fonctionner avec les API Hyper-V :
- Hyper-V
- Plateforme d’hyperviseur Windows
Si la fonctionnalité Hyper-V est activée, mais que la fonctionnalité « Plateforme d’hyperviseur Windows » est désactivée, dans System > Acceleration dans le résumé de la configuration de la machine virtuelle, vous pouvez voir que le Paravirtualisation mode est activé. Si vous essayez de démarrer une machine virtuelle, VirtualBox vous rappelle que vous devez activer la plateforme d’hyperviseur Windows et affiche le message d’erreur suivant :
Le message d’erreur :
WHvCapabilityCodeHypervisorPresent is FALSE! Make sure you have enabled the 'Windows Hypervisor Platform' feature.
(VERR_NEM_NOT_AVAILABLE).
VT-x is not available (VERR_VMX_NO_VMX).
Si les fonctionnalités requises liées à Hyper-V sous Windows sont activées, les informations suivantes s’affichent pour la machine virtuelle dans la section Système :
Acceleration: VT-x/AMD-v, Nested Paging, Paravirtualization 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 s’exécute en mode de paravirtualisation Hyper-V plutôt qu’en mode natif, habituellement utilisé par VirtualBox lorsqu’il interagit directement avec les extensions de virtualisation du processeur. Les performances des VMs VirtualBox sont réduites sur les machines sur lesquelles Hyper-V et ses fonctionnalités associées sont activés. 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.
Consultez également la comparaison disponible à l’adresse VirtualBox contre Hyper-V et celle disponible à l’adresse VirtualBox contre 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 et 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 l’émulateur Android de Google 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 prenant 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 nuire aux performances des VMs non Hyper-V. La sauvegarde des données est essentielle 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.
