Virtualisation matérielle imbriquée : exigences, utilisations et configuration

Informatec Digital » Ressources » Virtualisation matérielle imbriquée : exigences, utilisations et configuration

La virtualisation imbriquée sur les serveurs modernes est devenue un outil quasi indispensable pour les équipes informatiques, les développeurs et les formateurs qui doivent configurer des laboratoires complexes, des environnements de test ou des scénarios de sécurité sans encombrer le centre de données de serveurs physiques. En clair, elle permet d'exécuter des machines virtuelles à l'intérieur d'autres machines virtuelles, tout en maintenant des performances acceptables et en optimisant la gestion des ressources.

Au-delà de la simple imbrication de machines virtuelles, la virtualisation imbriquée ouvre la voie à des pipelines DevOps flexibles, des environnements de formation réalistes, des tests de sécurité isolés et des déploiements IoT Edge sur diverses plateformes, d'Hyper-V sur site aux machines virtuelles sur Azure ou VMware ESXi. Toutefois, pour un fonctionnement optimal, la configuration matérielle et celle de l'hyperviseur doivent répondre à des exigences très spécifiques.

Qu’est-ce que la virtualisation imbriquée exactement et pourquoi est-ce important ?

La virtualisation imbriquée désigne la capacité d'une machine virtuelle à servir d'hôte de virtualisation pour d'autres machines virtuelles internes. Autrement dit, un hyperviseur de niveau supérieur est installé sur le matériel physique (par exemple, Hyper-V dans Windows Server ou Azure Local), et Hyper-V, ou un autre hyperviseur compatible, est installé au sein de l'une de ses machines virtuelles afin de créer d'autres machines virtuelles.

Dans le cas d'Hyper-V, la virtualisation imbriquée permet d'installer le rôle Hyper-V au sein d'une machine virtuelle invitée qui, à son tour, s'exécute sur un hôte physique avec Hyper-V. Cette machine virtuelle « intermédiaire » expose les extensions de virtualisation du processeur aux machines virtuelles internes, qui se comportent comme si elles étaient plus proches du matériel, même si plusieurs couches sont en réalité présentes sous-jacentes.

Cette fonctionnalité est apparue initialement dans Windows Server 2016 et Windows 10 pour les processeurs Intel , et sa prise en charge a depuis été étendue aux versions plus récentes de Windows Server, à Windows 11 et aux processeurs AMD. Aujourd'hui, il s'agit d'une fonctionnalité éprouvée que Microsoft intègre à sa documentation officielle et qui est également utilisée par des solutions tierces.

L'intérêt pratique est évident : grâce à la virtualisation imbriquée, nous pouvons répliquer des environnements de production, créer des clusters complets, tester des configurations risquées ou simuler des réseaux multicouches sans investir dans de nouvelles baies ni réserver d'espace dans un centre de données. Pour de nombreuses entreprises, les économies réalisées et l'agilité qu'elle procure compensent largement la légère baisse de performance.

Cas d'utilisation courants de la virtualisation imbriquée

L'un des scénarios les plus courants consiste à mettre en place des environnements de test complexes . Les équipes de développement et d'assurance qualité peuvent ainsi construire des piles d'applications multi-niveaux (bases de données, services intermédiaires, interfaces utilisateur) entièrement au sein d'une seule machine virtuelle principale, et héberger dans celle-ci toutes les machines virtuelles internes nécessaires à la réplication d'un environnement de production.

Il est également très utile dans les environnements de formation et de développement techniques . Les formateurs peuvent configurer une machine virtuelle hôte où chaque étudiant crée sa propre machine virtuelle invitée, configure des réseaux, teste des rôles de serveur ou déploie des conteneurs, sans jamais toucher à l'infrastructure « réelle » de l'entreprise. Tout est contenu dans un environnement isolé et facilement jetable.

Une autre utilisation courante consiste à évaluer et à tester les nouvelles versions logicielles . Au lieu de modifier directement les configurations sensibles sur l'hôte physique, les administrateurs peuvent reproduire le scénario sur une machine virtuelle imbriquée et valider les correctifs, les nouvelles versions ou les modifications de sécurité avant leur déploiement en production.

La virtualisation imbriquée joue également un rôle clé dans l'activation de fonctionnalités de sécurité avancées telles que la sécurité basée sur la virtualisation (VBS) ou des isolations spécifiques qui s'appuient sur les fonctions de l'hyperviseur à différents niveaux. Cela permet de renforcer la sécurité de certains environnements sans nécessiter de matériel supplémentaire.

Dans le domaine de l'IoT, la virtualisation imbriquée est essentielle pour les scénarios Azure IoT Edge pour Linux sur Windows , où il est nécessaire de combiner les capacités de Windows, des conteneurs Linux et de l'hyperviseur sur différentes couches de virtualisation, à la fois localement et sur des plateformes tierces telles que VMware ESXi ou des machines virtuelles dans Azure.

Configuration matérielle et logicielle requise pour la virtualisation imbriquée

Pour que tout cela fonctionne correctement, le premier filtre concerne la compatibilité matérielle et les versions minimales du système d'exploitation . Dans les environnements Azure sur site, par exemple, la version 2411.3 ou ultérieure est requise, ainsi que des machines virtuelles dont la version de configuration est 10.0 ou supérieure, garantissant ainsi la prise en charge des extensions de virtualisation nécessaires.

Au niveau du processeur, si vous utilisez un processeur Intel, il est essentiel d' activer la technologie de virtualisation Intel VT-x dans le BIOS/UEFI. Pour les architectures AMD, la prise en charge d'AMD-V est requise, et pour les scénarios avancés, la technologie de virtualisation chiffrée sécurisée (SEV) doit être activée. Cette dernière ajoute le chiffrement aux machines virtuelles et améliore l'isolation et la sécurité de bas niveau.

Le système d'exploitation hôte doit être une version récente de Windows Server ou Windows 10/11 , correctement mise à jour avec les derniers correctifs. Hyper-V doit être installé sur la machine physique avant toute tentative d'imbrication ; cette fonctionnalité n'est pas prise en charge par défaut par un processeur compatible.

Un autre point essentiel concerne l'état des machines virtuelles. Pour modifier les paramètres du processeur et accéder aux extensions de virtualisation, la machine virtuelle faisant office d'hôte imbriqué doit être complètement arrêtée , et non suspendue ou en état enregistré. Ce n'est qu'à cette condition qu'Hyper-V permet de modifier les options avancées du processeur virtuel.

Enfin, la connectivité réseau doit être soigneusement planifiée. Les machines virtuelles imbriquées peuvent nécessiter un accès externe ou à d'autres couches ; il est donc conseillé de définir dès le départ si des commutateurs internes, la NAT, l'usurpation d'adresse MAC ou d'autres techniques de virtualisation réseau seront utilisées afin d'éviter les problèmes de communication et de filtrage.

Activer la virtualisation imbriquée dans Hyper-V à l'aide de PowerShell

La méthode la plus directe et la plus précise pour activer la virtualisation imbriquée dans Hyper-V consiste à utiliser les cmdlets PowerShell . Cette méthode fonctionne aussi bien sur Windows Server que sur les éditions client compatibles et permet d'automatiser la configuration de manière cohérente sur plusieurs hôtes ou machines virtuelles.

La première étape consiste à s'assurer que la machine virtuelle sur laquelle nous souhaitons installer Hyper-V en tant qu'invité est désactivé depuis le Gestionnaire Hyper-V (Option Arrêter) ou en utilisant la commande appropriée dans PowerShell, par exemple Stop-VM -Name 'NombreVM'Si le système reste suspendu ou en état enregistré, les modifications apportées au processeur ne seront pas appliquées correctement.

Une fois la machine virtuelle arrêtée, vous devez exposer les extensions de virtualisation du processeur au système d'exploitation invité à l'aide de l' applet de commande Set-VMProcessor , en définissant l'option ExposeVirtualizationExtensions sur true. Ce paramètre permet au système, depuis la machine virtuelle, d'accéder aux fonctions nécessaires à l'installation des rôles d'hyperviseur.

Pour vérifier que l'opération a été correctement appliquée, nous pouvons utiliser Get-VMProcessor combiné à Select sur le champ ExposeVirtualizationExtensions. Cela vérifie si la valeur est définie sur true dans la configuration du processeur virtuel de la machine virtuelle cible et empêche le démarrage d'un environnement partiellement configuré.

Si à un moment donné il devient nécessaire de rétablir la configuration initiale (par exemple, lors d'une tâche de diagnostic ou parce que les machines virtuelles imbriquées ne sont plus nécessaires), il suffit de répéter la même cmdlet de processeur , mais de modifier la valeur à false, ce qui désactive à nouveau l'exposition des extensions de virtualisation à la machine virtuelle invitée.

Une fois le processeur virtuel configuré, la machine virtuelle est mise sous tension à l'aide de la commande Start-VM ou du Gestionnaire Hyper-V . Depuis le système d'exploitation invité, le rôle Hyper-V complet est ensuite installé par les méthodes habituelles : Gestionnaire de serveur (Ajout de rôles et de fonctionnalités), DISM, PowerShell, etc. Dès lors, la machine virtuelle se comporte comme un hôte Hyper-V supplémentaire pour l'administrateur.

Configuration réseau et usurpation d'adresse MAC dans des environnements imbriqués

Une fois la partie processeur terminée, l'étape suivante consiste à configurer la connectivité réseau des machines virtuelles imbriquées . Si l'on souhaite que les machines virtuelles internes communiquent avec d'autres réseaux, Internet ou des ordinateurs de niveau supérieur, il est indispensable d'ajuster certains paramètres de l'adaptateur virtuel de la machine virtuelle intermédiaire.

Dans Hyper-V, il est courant d'activer l'usurpation d'adresse MAC sur la carte réseau de la machine virtuelle faisant office d'hôte imbriqué. Cette fonctionnalité permet aux machines virtuelles internes d'envoyer du trafic en utilisant leurs propres adresses MAC via la même carte réseau, contournant ainsi le blocage ou le filtrage du commutateur virtuel de l'hôte physique.

Ce réglage peut être effectué depuis PowerShell à l'aide de la cmdlet Set-VMNetworkAdapter avec le paramètre MacAddressSpoofing défini sur On, appliquée à la carte réseau correspondante de la machine virtuelle. Cela garantit que le trafic provenant de machines virtuelles plus profondes n'est pas bloqué par l'hyperviseur de niveau supérieur.

Pour les configurations plus avancées, il est conseillé de prédéfinir la topologie des commutateurs virtuels et des instances NAT à chaque niveau. Par exemple, on peut combiner des commutateurs internes pour isoler les environnements de test, des règles de routage ou des pare-feu entre les niveaux, et une NAT sur l'hôte intermédiaire pour fournir un accès Internet à plusieurs machines virtuelles imbriquées sans les exposer directement.

Lors de l'utilisation de plusieurs couches de virtualisation, les problèmes de connectivité sont souvent liés à la désactivation de l'usurpation d'adresse MAC, à des règles NAT mal chaînées ou à des pare-feu trop restrictifs . Vérifier ces points et redémarrer les cartes réseau ou les services à chaque niveau résout généralement la plupart des problèmes de connectivité dans les environnements imbriqués.

Utilisation de l'interface graphique pour les tâches connexes

Bien que l'activation stricte de la virtualisation imbriquée soit entièrement contrôlée depuis PowerShell, en pratique, de nombreuses tâches connexes sont plus pratiques via l' interface graphique du Gestionnaire Hyper-V , notamment si l'on gère plusieurs hôtes ou si l'on souhaite examiner la configuration visuellement.

La procédure habituelle consiste à ouvrir le Gestionnaire Hyper-V, à localiser la machine virtuelle cible et à s'assurer qu'elle est hors tension à l'aide de l'option « Arrêter ». Cette méthode complète l'utilisation de PowerShell et évite de démarrer accidentellement une machine virtuelle dont tous les paramètres ne sont pas encore correctement configurés.

Une fois les cmdlets nécessaires à l'exposition des extensions de virtualisation exécutées, nous pouvons revenir à l'environnement graphique et ouvrir la fenêtre de configuration de la machine virtuelle . De là, il est facile de consulter et de modifier les propriétés de la carte réseau, le nombre de processeurs virtuels alloués ou la mémoire disponible pour la machine virtuelle hôte imbriquée.

L'option permettant d'activer l'usurpation d'adresse MAC se trouve dans les paramètres avancés de la carte réseau . Son activation via l'interface graphique est rapide et simple pour les administrateurs qui privilégient une approche visuelle ou qui n'ont pas mémorisé tous les paramètres des cmdlets.

Une fois cette configuration terminée, la gestion quotidienne de l'environnement peut être effectuée indifféremment depuis la console Hyper-V sur l'hôte physique ou au sein de la VM imbriquée , en utilisant des outils standard pour créer de nouvelles VM, configurer des commutateurs, ajouter des rôles ou prendre des instantanés en fonction des besoins de chaque laboratoire.

Virtualisation imbriquée dans les scénarios Azure On-Premise et IoT Edge

Dans les environnements Azure sur site, la virtualisation imbriquée repose sur les mêmes principes, mais impose des exigences de version spécifiques et prend en charge des fonctionnalités avancées telles que AMD SEV ou les extensions de sécurité . Une version système minimale (2411.3 ou supérieure) est requise, et les machines virtuelles doivent utiliser une version de configuration compatible (10.0 ou ultérieure).

Lors de l'utilisation d'Azure IoT Edge pour Linux sous Windows, trois options de déploiement de virtualisation imbriquée sont prises en charge . Chacune répond à des besoins d'infrastructure différents et au niveau de contrôle que l'organisation souhaite conserver sur l'environnement sous-jacent et l'hyperviseur.

La première option consiste à déployer IoT Edge sur une machine virtuelle Windows hébergée localement avec Hyper-V . Il s'agit de l'approche la plus simple : la virtualisation imbriquée est activée sur cette machine virtuelle Windows, puis Azure IoT Edge pour Linux est installé et configuré sur Windows conformément à la documentation spécifique de Microsoft.

Dans ce cas, il est crucial de s'assurer que le rôle Hyper-V est correctement installé sur l'hôte local (Windows Server ou Azure Local) . Sans Hyper-V activé sur l'hôte, la machine virtuelle invitée ne pourra pas servir d'hyperviseur imbriqué ni exposer les fonctions nécessaires à IoT Edge dans une couche supplémentaire.

Ces types de déploiements sont très utiles lorsque vous devez intégrer des appareils IoT, des conteneurs Linux et des services Azure au sein d'infrastructures Windows existantes, en maintenant un équilibre raisonnable entre flexibilité, performance et facilité de gestion.

Virtualisation imbriquée avec VMware ESXi et Azure IoT Edge

Un autre scénario intéressant se présente lorsque l'on souhaite exécuter Azure IoT Edge pour Linux sur Windows au sein d'une machine virtuelle Windows hébergée sur VMware ESXi . Dans ce cas, la virtualisation imbriquée repose sur les capacités de l'hyperviseur VMware plutôt que sur Hyper-V directement sur le matériel.

Les versions 6.7 et 7.0 de VMware ESXi prennent explicitement en charge la virtualisation matérielle des machines virtuelles invitées , permettant ainsi l'imbrication nécessaire pour qu'une machine virtuelle Windows devienne un hôte Hyper-V. VMware documente cette fonctionnalité dans sa base de connaissances, en détaillant les exigences et les éventuelles conséquences sur les performances.

La procédure générale consiste d'abord à créer une machine virtuelle Windows sur l'hôte ESXi , en suivant les recommandations standard de VMware concernant les processeurs, la mémoire, le stockage et les cartes réseau. Une fois créée, la machine virtuelle est arrêtée afin de permettre la modification de ses paramètres avancés de processeur.

Depuis l'interface du client ESXi ou vSphere, sélectionnez la machine virtuelle Windows, accédez à Modifier les paramètres , puis, dans la section Paramètres du processeur, repérez la section Virtualisation matérielle. Activez ensuite l' option « Exposer la virtualisation matérielle au système d'exploitation invité » , ce qui permettra à Windows de détecter les extensions VT-x/AMD-V même s'il s'exécute dans ESXi.

Après avoir enregistré les modifications et redémarré la VM, procédez à l'installation de l'hyperviseur Hyper-V sur Windows , soit sur une édition client (Windows 10/11), soit sur Windows Server, en veillant à inclure les outils de gestion et tous les composants supplémentaires requis pour les conteneurs ou services qui seront utilisés avec IoT Edge.

Virtualisation imbriquée dans les machines virtuelles Azure

Lorsque nous passons à un niveau supérieur et travaillons directement avec des machines virtuelles dans Azure en tant qu'hôte de virtualisation imbriquée , les particularités de la plateforme entrent en jeu, notamment en ce qui concerne les commutateurs virtuels et le réseau par défaut utilisé par les machines virtuelles Azure.

Azure IoT Edge pour Linux sur Windows n'est pas pris en charge nativement sur les machines virtuelles Azure exécutant une référence serveur, sauf si un script spécifique est exécuté pour activer un commutateur virtuel approprié. Ce script ouvre un commutateur par défaut permettant à l'environnement IoT Edge de fonctionner correctement avec la couche de virtualisation supplémentaire.

La documentation officielle de Microsoft décrit les étapes de création et de configuration d'un commutateur virtuel pour Linux sur Windows dans le contexte d'Azure, alignant ainsi les exigences réseau des conteneurs et des services Edge sur les caractéristiques de l'infrastructure réseau du cloud.

Dans ce type de déploiement, il est particulièrement important d'examiner la référence de la machine virtuelle, le type de stockage et les quotas de processeur et de RAM , car la virtualisation imbriquée ajoute ses propres frais généraux et les machines virtuelles internes peuvent consommer des ressources de manière intensive si l'ensemble n'est pas correctement dimensionné.

Malgré ces complexités, l'avantage est considérable : une machine virtuelle Azure peut être utilisée comme plateforme de test, de développement ou de préproduction pour les solutions IoT Edge dans les mêmes conditions qui seront ultérieurement reproduites sur des dispositifs Edge physiques ou des passerelles industrielles déployées sur le terrain.

Sauvegarde des machines virtuelles Hyper-V imbriquées avec des solutions spécialisées

Un aspect souvent négligé lors de la conception d'environnements de virtualisation imbriqués est la stratégie de sauvegarde et de reprise après sinistre . C'est là qu'interviennent les solutions de sauvegarde d'entreprise, capables de gérer efficacement les environnements Hyper-V comportant plusieurs couches de virtualisation et plusieurs plateformes exécutées en parallèle.

Parmi ces solutions figurent des outils comme Vinchin Backup & Recovery , qui prend en charge plus de quinze plateformes de virtualisation différentes, dont VMware, Proxmox, oVirt, OLVM, RHV, XCP-ng, XenServer, OpenStack, ZStack et, bien sûr, Hyper-V. Ce type de logiciel est conçu pour les infrastructures hétérogènes où coexistent des hyperviseurs de différents fabricants.

Des fonctionnalités telles que la sauvegarde incrémentale perpétuelle, la déduplication et la compression des données , ainsi que les restaurations granulaires réduisent considérablement la consommation de stockage et le temps nécessaire pour récupérer des machines individuelles, des fichiers spécifiques, voire des objets spécifiques d'applications critiques.

De plus, les politiques de sauvegarde planifiées et les options d'archivage sur bande ou dans le cloud permettent d'adapter la stratégie de sauvegarde aux exigences réglementaires ou internes de chaque organisation, en maintenant de longues périodes de conservation sans faire grimper les coûts de stockage dans les baies hautes performances.

La console de gestion web simplifie considérablement la protection des environnements Hyper-V avec des machines virtuelles imbriquées : il suffit de sélectionner les machines virtuelles à protéger, de choisir le référentiel de sauvegarde, de définir la stratégie d’exécution (fenêtres horaires, type de sauvegarde, durée de conservation) et de lancer la tâche. Nombre de ces solutions proposent des périodes d’essai complètes de plusieurs semaines permettant d’évaluer leurs performances et leur intégration à l’infrastructure existante.

Limitations et bonnes pratiques dans les environnements imbriqués

Bien que les possibilités de la virtualisation imbriquée soient vastes, il existe également des limitations techniques imposées par la conception même des hyperviseurs qu'il convient de comprendre dès le départ afin d'éviter les surprises dans les scénarios de production ou de haute disponibilité.

Un exemple concret est la migration à chaud de machines virtuelles utilisant la virtualisation imbriquée . Actuellement, il est impossible de migrer à chaud un hôte principal lorsque ses machines virtuelles hébergent des invités qui dépendent d'une imbrication active. Microsoft documente cette restriction et recommande généralement de planifier les mises à jour ou les déplacements d'hôtes avec des arrêts contrôlés dans ces environnements.

La surveillance de la consommation des ressources à plusieurs niveaux exige une stratégie combinée. Il est conseillé d'utiliser le Gestionnaire Hyper-V, les compteurs de performances et des cmdlets comme Get-VM sur l'hôte de niveau supérieur, et simultanément des outils similaires sur l'hôte imbriqué afin d'obtenir une vue claire de la répartition de la charge entre le processeur, la mémoire, le réseau et le stockage.

Lorsqu'une machine virtuelle interne perd soudainement sa connectivité réseau, cela est généralement dû à des modifications des règles de pare-feu, à des problèmes de NAT ou à la désactivation de l'usurpation d'adresse MAC sur l'une des cartes réseau concernées. Vérifier la configuration à tous les niveaux et redémarrer les services réseau affectés permet généralement de résoudre la plupart de ces pannes.

Avant de déployer une virtualisation imbriquée, il est généralement conseillé de définir clairement l'objectif de l'environnement, le nombre de couches, les types de charges de travail à exécuter et la politique de sauvegarde. Cette conception initiale déterminera la viabilité à long terme de l'environnement de laboratoire ou de test et évitera qu'il ne devienne un système complexe et difficile à maintenir.

En bref, la virtualisation imbriquée d'Hyper-V et d'autres plateformes permet de tirer bien plus de profit du matériel existant et de configurer des scénarios de laboratoire, de test, de sécurité ou d'Edge IoT avec une flexibilité énorme, à condition que les exigences du processeur, la version du système et la configuration réseau soient respectées, et que tout cela s'accompagne d'une bonne stratégie de surveillance et de sauvegarde.

Article connexe:

Guide complet de Windows Server : qu'est-ce que c'est, à quoi ça sert et ses versions