Étapes pour déployer des VM Hyper-V sur un serveur VMware ESXi
Il y a beaucoup de choses formidables que vous pouvez faire au-dessus des systèmes d’hyperviseurs modernes d’aujourd’hui qui fournissent un excellent moyen de résoudre les problèmes commerciaux et les défis techniques. L’une des choses vraiment intéressantes que vous pouvez faire avec les hyperviseurs d’aujourd’hui tels que VMware vSphere, c’est que vous pouvez configurer la virtualisation imbriquée. Cela ouvre de nombreuses possibilités différentes de tester et d’exécuter des hyperviseurs à l’intérieur de VMware vSphere.
Un cas d’utilisation commun que beaucoup ont trouvé pour exécuter la virtualisation imbriquée à l’intérieur de VMware vSphere est l’exécution de l’hyperviseur Hyper-V de Microsoft à des fins de test et d’apprentissage.
Dans ce post, nous allons jeter un coup d’œil à la configuration des VM Hyper-V imbriquées sur un serveur VMware ESXi et voir comment cela peut être configuré pour une utilisation dans un laboratoire ou un autre environnement.
Qu’est-ce que la virtualisation imbriquée
Avant de plonger dans la façon de configurer VMware vSphere pour activer la virtualisation imbriquée de Hyper-V à l’intérieur du serveur ESXi, jetons un coup d’œil à ce qu’est exactement la virtualisation imbriquée. Lorsque nous pensons à la virtualisation imbriquée, nous parlons d’exécuter un hyperviseur à l’intérieur d’un hyperviseur. Cela signifie que vous pouvez exécuter des hyperviseurs de type 1 comme VMware vSphere ESXi et Hyper-V à l’intérieur d’une VM par-dessus, dans ce cas, VMware vSphere ESXi.
L’hyperviseur exécuté dans la VM par-dessus le serveur VMware vSphere ESXi considère simplement le matériel de la VM comme son matériel hôte physique sur lequel il peut exécuter des machines virtuelles invitées. Cela permet des scénarios très intéressants lorsque vous utilisez votre environnement VMware vSphere pour héberger d’autres hyperviseurs comme Microsoft Hyper-V.
Un point important à faire en ce qui concerne VMware vSphere est la virtualisation imbriquée d’autres hyperviseurs comme Hyper-V à l’intérieur d’une VM vSphere n’est pas un scénario pris en charge. Il ne s’agit pas seulement d’autres hyperviseurs en dehors de VMware vSphere. Même l’exécution d’ESXi imbriqué dans un environnement hôte ESXi physique n’est pas prise en charge. Ceci est officiellement noté par VMware dans l’article KB Support for running ESXi/ESX as a nested virtualization solution (2009916).
Les configurations suivantes sont techniquement possibles lors de l’exécution de VMware ESXi à l’intérieur d’autres produits hyperviseurs VMware, mais ne sont pas prises en charge. Cela inclut ce qui suit .
- VMware ESXi/ESX s’exécutant dans VMware Workstation ou VMware Fusion
- VMware ESXi/ESX s’exécutant dans VMware ESXi/ESX
- VMware ESXi/ESX s’exécutant dans d’autres solutions d’hyperviseur tierces
Bien sûr, l’exécution d’Hyper-V relève de ce même type de déni de support. Il n’y a qu’une seule situation où la virtualisation imbriquée est prise en charge et c’est l’appliance vSAN Witness imbriquée.
En dehors de ce cas d’utilisation pris en charge avec l’appliance vSAN Witness, la virtualisation imbriquée n’est pas prise en charge pour l’environnement de production. En d’autres termes, si vous rencontrez des problèmes en utilisant la virtualisation imbriquée, vous êtes seul avec le support.
Dès lors que vous comprenez le scénario de support avec la virtualisation imbriquée, c’est une excellente fonctionnalité à exploiter à d’autres fins. Il peut être utilisé très efficacement pour les environnements de laboratoire, le dev, le test et d’autres types de scénarios similaires.
Pourquoi exécuter Hyper-V à l’intérieur de VMware
Pourquoi voudriez-vous exécuter un hyperviseur à l’intérieur d’un autre hyperviseur ? Plus précisément, pourquoi voudriez-vous exécuter Hyper-V à l’intérieur d’une VM ESXi de VMware ? Comme nous l’avons déjà mentionné, il ne s’agit pas d’une configuration prise en charge pour une utilisation en production. Exécuter Hyper-V à l’intérieur de VMware offre de nombreux avantages. Examinons les points suivants :
- Environnements de laboratoire
- Aucun matériel ou équipement réseau supplémentaire n’est requis
- Proviser et démonter facilement les hôtes Hyper-V
Environnements de laboratoire
C’est sans doute le cas d’utilisation le plus courant pour provisionner un hôte Hyper-V à l’intérieur d’une machine virtuelle VMware. La virtualisation imbriquée permet de provisionner très facilement des environnements de laboratoire, de dev, de test et d’autres cas d’utilisation possibles. Les laboratoires Hyper-V peuvent être utilisés pour :
- Apprendre
- Tester des logiciels
- POC’ing Hyper-V pour diverses parties de votre infrastructure ou comme remplacement
- Mimer un environnement Hyper-V dans une autre partie de votre infrastructure
- Tester des correctifs
Dans de nombreux environnements de petite à moyenne taille, il se peut qu’il n’y ait que la disponibilité d’un environnement VMware vSphere et aucun hôte Hyper-V. Si les administrateurs veulent mettre la main sur un hôte Hyper-V pour apprendre et développer leurs compétences en dehors de l’hyperviseur VMware ESXi, les capacités de virtualisation imbriquées trouvées dans VMware vSphere fournissent le moyen parfait de provisionner un hôte Hyper-V à l’intérieur d’un environnement VMware vSphere.
Aucun matériel ou équipement réseau supplémentaire n’est nécessaire
Avec cette capacité d’imbriquer Hyper-V à l’intérieur de VMware vSphere, il n’est pas nécessaire de trouver du matériel supplémentaire pour un environnement de laboratoire ou une sorte de POC. Tout cela peut être provisionné à l’intérieur de vSphere. Les capacités de réseau virtuel robustes de vSphere permettent également de provisionner tous les réseaux spécialisés dont vous aurez besoin si vous décidez de provisionner un cluster Hyper-V. Il peut s’agir de la migration en direct, du stockage, de la gestion des données, de la gestion de la sécurité et de la gestion de l’information. Il peut s’agir de réseaux de migration en direct, de stockage et de cluster, pour n’en citer que quelques-uns. En utilisant des groupes de ports de commutateurs virtuels, vous pouvez facilement simuler les configurations qui seraient accomplies avec du matériel réseau physique autrement.
Manipuler et démonter facilement les hôtes Hyper-V
Cet avantage n’est pas spécifique à la virtualisation imbriquée mais plutôt à la virtualisation VMware vSphere en général. VMware dispose de jeux d’outils d’automatisation très riches, notamment PowerCLI. Cela permet de faire tourner et de détruire facilement les VM en fonction de vos besoins. Des constructions de laboratoire entières peuvent être automatisées pour le provisionnement et le déprovisionnement. Cela sert à rendre la virtualisation imbriquée encore plus utile avec les capacités faciles d’automatisation de votre infrastructure.
Conditions requises pour les VM Hyper-V imbriquées sur un serveur VMware ESXi
Une fois que vous avez décidé de faire usage de la virtualisation imbriquée, pouvez-vous simplement créer une nouvelle VM dans vSphere ESXi et commencer à charger votre VM Hyper-V ? Eh bien, pas exactement, mais le processus reste très facile à utiliser lorsque vous pensez à l’énorme complexité requise sous le « capot » pour que la virtualisation imbriquée fonctionne réellement. Il y a vraiment deux domaines principaux à considérer avec les exigences pour exécuter des VM Hyper-V imbriquées sur un serveur VMware ESXi. Cela comprend :
- Exposer la virtualisation assistée par le matériel à l’OS invité
- Activer les transmissions forgées d’adresses MAC
Regardons chacun d’entre eux et leur importance pour exécuter des VM Hyper-V imbriquées sur un serveur VMware ESXi.
Exposer la virtualisation assistée par le matériel au système d’exploitation invité
Cette première exigence, vous la trouverez absolument nécessaire. Il s’agit d’un paramètre situé sous les paramètres de la VM individuelle que vous utilisez pour héberger votre installation Hyper-V. Modifiez les paramètres sur votre VM Hyper-V imbriquée, développez CPU et placez une case à cocher à côté de l’option Exposer la virtualisation assistée par le matériel à l’OS invité.
Que se passe-t-il si vous n’activez pas cet indicateur de virtualisation assistée par matériel dans VMware pour votre VM Hyper-V ? Vous ne verrez pas d’erreur en installant simplement votre système d’exploitation Windows Server, car cela fonctionnera comme l’installation de toute autre VM. Cependant, lorsque vous arriverez au moment d’installer le rôle Hyper-V, vous verrez une erreur si ce paramètre n’est pas activé pour la machine virtuelle. Remarquez l’erreur ci-dessous, « Hyper-V ne peut pas être installé : Le processeur n’a pas les capacités de virtualisation requises ».
En guise de remarque secondaire, cet indicateur doit être défini soit pour les installations Hyper-V Core, soit avec le rôle Hyper-V installé dans Windows Server avec l’expérience de bureau installée. Cette capacité est requise dans toute installation imbriquée du rôle Hyper-V à l’intérieur de VMware vSphere.
Vous pouvez également définir ce drapeau avec un peu de code PowerCLI qui permet de définir facilement le drapeau sur la VM spécifiée.
$vmName = ‘MyHyperVVM’
$vm = Get-VM -Name $vmName
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.nestedHVEnabled = $true
$vm.ExtensionData.ReconfigVM($spec)
Activation du mode promiscuous et des transmissions falsifiées d’adresses MAC
Plus probablement, si vous configurez une installation imbriquée Hyper-V à l’intérieur de VMware vSphere, vous voudrez être en mesure non seulement d’installer un serveur avec le rôle Hyper-V, mais aussi d’exécuter une VM Hyper-V imbriquée au-dessus du serveur Hyper-V imbriqué que vous exécutez.
Vous pouvez ne pas vous soucier d’avoir la capacité de connectivité réseau à la VM Hyper-V, cependant, vous pouvez vouloir être en mesure d’établir une connectivité réseau réelle à la machine virtuelle imbriquée fonctionnant au-dessus de l’hôte Hyper-V imbriqué dans la machine virtuelle VMware.
Si vous voulez avoir cette fonctionnalité, il y a quelques paramètres de configuration réseau que vous pouvez avoir besoin de faire sur votre VMware vSwitch auquel votre hôte Hyper-V imbriqué est connecté.
Vous pouvez avoir besoin de le faire car il y a une nouvelle avancée dans la technologie VMware vSwitch et la virtualisation imbriquée depuis la sortie de VMware vSphere 6.7. Avant la sortie de VMware vSphere ESXi 6.7, VMware n’implémentait pas l’apprentissage MAC sur un vSwitch comme on le trouve dans un vrai commutateur physique. Cela était vrai pour le commutateur standard vSphere ou le commutateur distribué vSphere.
Comme c’est le cas avec le VMware vSwitch avant vSphere 6.7, lorsqu’un commutateur virtuel reçoit des paquets qui n’ont pas une adresse MAC correspondant à l’adresse MAC pNIC des hôtes d’hyperviseur imbriqués (dans le cas d’un hôte ESXi imbriqué), les paquets seront abandonnés.
Pour contourner cette limitation, il y a deux paramètres qui doivent être activés sur le vSwitch, le mode promiscuous et les transmissions forgées.
Qu’en est-il de vSphere 6.7 et plus ? Avant la sortie de vSphere ESX 6.7, VMware a commencé à faire des travaux dans le domaine de la virtualisation imbriquée et de la fonctionnalité d’apprentissage MAC par rapport aux commutateurs virtuels. Un « MAC Learning Fling » a été publié qui a introduit la fonctionnalité d’apprentissage MAC afin que vous n’ayez pas à activer le mode promiscuous et à forger des paramètres de transmission.
Ce paramètre a été mis en œuvre avec la sortie de VMware vSphere 6.7 ESXi.
Quelles sont les exigences de la nouvelle fonctionnalité d’apprentissage MAC dans ESXi 6.7 ?
Il y a quelques exigences que vous devez avoir en place avant de pouvoir profiter de la nouvelle fonctionnalité d’apprentissage MAC dans vSphere 6.7. Elles sont les suivantes :
- Mettre à niveau vCenter Server et les serveurs ESXi vers vSphere 6.7
- Exécuter le commutateur distribué vSphere (vDS)
- Mettre à niveau le vDS vers la dernière version (6.6)
- Géré par base de groupe de ports de commutateur distribué vSphere
- Géré actuellement avec l’API vSphere
Une chose à noter, la nouvelle fonctionnalité d’apprentissage MAC avec vSphere 6.7 et un vSwitch vDS 6.6 n’est pas activée par défaut. Vous devrez définir les drapeaux de manière appropriée avec l’API.
Pour rendre ce processus beaucoup plus facile, William Lam, une architecture de solution du personnel a écrit un couple de fonctions PowerCLI qui rendent la vérification de l’état de l’apprentissage MAC et la définition de l’apprentissage MAC dans votre environnement vSphere extrêmement facile. Téléchargez le script PowerCLI de William depuis son dépôt Github ici :
https://github.com/lamw/vghetto-scripts/blob/master/powershell/MacLearn.ps1
Un exemple de sortie de la fonction Get-MacLearn vérifiant un groupe de ports de commutateurs distribués vSphere ressemble à ce qui suit. Notez les champs :
- MacLearning
- NewAllowPrimiscuous
- NewForged Transmits
- NewMacChanges
- Limit
- LimitPolicy
C’est ce à quoi ressemblera un groupe de ports de vDS 6.7 vSwitch avec les paramètres par défaut.
Pour les installations ESXi imbriquées, et par extension, les VM Hyper-V exécutées à l’intérieur de votre hyperviseur vSphere ESXi, vous voulez définir les paramètres suivants :
- MAC Learning : true
- Promiscuous mode : Faux
- Transmission forgée : Vrai
- Modifications du MAC : False
- Limite : 4096 (vous pouvez définir ceci ou laisser la valeur par défaut)
- Politique de limite : Drop (vous pouvez définir ceci ou laisser la valeur par défaut)
Les recommandations ci-dessus peuvent être définies avec le code PowerCLI suivant :
- Set-MacLearn -DVPortgroupName @(« DPG-Servers ») -EnableMacLearn $true -EnablePromiscuous $false -EnableForgedTransmit $true -EnableMacChange $false
Comme nous nous y attendons maintenant, comme vous le remarquez ci-dessus, le paramètre du mode Promiscuous est configuré sur False. Même avec l’apprentissage MAC activé, la transmission forgée est toujours configurée à True.
La fonctionnalité MAC Learning contenue dans vSphere 6.7 permet d’éviter certaines des implications de sécurité de l’exécution d’une VM imbriquée à l’intérieur de votre environnement vSphere 6.7 en empêchant la nécessité d’activer le mode promiscuous.
Pouvez-vous sauvegarder les environnements imbriqués ?
Même si l’exécution de la virtualisation imbriquée est uniquement prise en charge par VMware vSphere pour l’appliance vSAN Witness, si vous exécutez des VM Hyper-V imbriquées à l’intérieur de VMware vSphere ESXi, vous pouvez vouloir sauvegarder votre environnement imbriqué. Cela peut-il être fait ?
Oui, absolument.
L’utilisation d’une solution de sauvegarde moderne, comme Vembu BDR Suite, vous permet de sauvegarder non seulement votre environnement VMware vSphere ou Microsoft Hyper-V de production, mais aussi toutes les installations imbriquées d’ESXi ou Hyper-V que vous pouvez avoir dans l’environnement.
Wrapping Up
Les VM Hyper-V imbriquées sur un serveur VMware ESXi vous donne la possibilité de jouer avec Hyper-V, même si vous n’avez qu’un environnement VMware vSphere. Comme on peut le voir, il existe de nombreux cas d’utilisation de la virtualisation imbriquée. Cela inclut l’apprentissage, les tests logiciels, le POC’ing et la correction de vos hôtes Hyper-V.
Aussi puissante que soit la virtualisation imbriquée dans VMware vSphere, vous pourriez vous attendre à ce que le processus pour l’activer soit extrêmement difficile. Cependant, il ne nécessite que quelques considérations de votre part lors du provisionnement d’une VM VMware vSphere qui contiendra l’installation Hyper-V. Il s’agit notamment d’exposer le drapeau de virtualisation assistée par matériel sur le CPU virtuel de la VM Hyper-V et de mettre en œuvre le mode promiscuous ou l’apprentissage MAC pour connecter toute VM Hyper-V imbriquée au réseau.
En somme, les VM Hyper-V imbriquées sur un serveur VMware ESXi sont une capacité extrêmement puissante et vous permettent de tester et d’apprendre Hyper-V sans l’équipement physique pour exécuter l’hyperviseur Hyper-V.
Suivez nos flux Twitter et Facebook pour les nouvelles versions, les mises à jour, les posts perspicaces et plus encore.