Windows Server Virtualization

Parlez-nous de l’expérience de téléchargement de PDF.
Documentation sur la virtualisation

La virtualisation dans Windows Server est l’une des technologies fondamentales
nécessaires à la création de votre infrastructure à définition logicielle. Avec la mise en
réseau et le stockage, les fonctionnalités de virtualisation offrent la flexibilité dont vous
avez besoin pour les charges de travail de vos clients.
Conteneurs Windows
ｅ VUE D’ENSEMBLE
Conteneurs Windows
À propos des conteneurs Windows
Conteneurs ou machines virtuelles
Hyper-V sur Windows 10
Vue d’ensemble d’Hyper-V sur Windows 10
À propos d’Hyper-V sur Windows 10
ｂ BIEN DÉMARRER
Installer Hyper-V
Création d'une machine virtuelle
Hyper-V sur Windows Server
Vue d’ensemble de la technologie Hyper-V
ｉ RÉFÉRENCE
Microsoft Hyper-V Server 2016
Configuration requise pour Hyper-V sur Windows Server
Commutateur virtuel Hyper-V
ｃ GUIDE PRATIQUE
Gérer le commutateur virtuel Hyper-V
Utiliser une infrastructure protégée afin de fournir un environnement

sécurisé pour les ordinateurs virtuels
Structure protégée et machines virtuelles dotées d’une protection maximale

Structure protégée et machines
virtuelles dotées d’une protection
maximale
Article • 12/04/2023
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
L’un des objectifs les plus importants de la fourniture d’un environnement hébergé est
de garantir la sécurité des machines virtuelles exécutées dans l’environnement. En tant
que fournisseur de services cloud ou administrateur d’un cloud privé d’entreprise, vous
pouvez utiliser une structure protégée pour offrir un environnement plus sécurisé pour
les machines virtuelles. Une structure Service Guardian se compose d’un Service
Guardian hôte (HGS) généralement constitué d’un cluster de trois nœuds, d’un ou
plusieurs hôtes protégés et d’un ensemble de machines virtuelles dotées d’une
protection maximale.
） Important
Vérifiez que vous avez installé la dernière mise à jour cumulative avant de déployer
des machines virtuelles protégées en production.
Vidéos, blog et rubrique de vue d’ensemble sur

les infrastructures protégées et les machines
virtuelles protégées
Vidéo : Comment protéger votre infrastructure de virtualisation contre les menaces
internes avec Windows Server 2019
Vidéo : Présentation des machines virtuelle protégées dans Windows Server 2016
Vidéo : Plongez dans les machines virtuelles protégées avec Windows Server 2016
Hyper-V
Vidéo : Déploiement de machines virtuelles protégées et d’une infrastructure
protégée avec Windows Server 2016
Blog : Blog sur la sécurité des centres de données et du cloud privé
Vue d’ensemble : structure protégée et machines virtuelles protégées
Rubriques de planification
Guide de planification pour les hôtes
Guide de planification pour les locataires
Rubriques traitant du déploiement

Guide de déploiement
Démarrage rapide
Déployer SGH
Déployer des hôtes Service Guardian
Configuration de la structure DNS des hôtes qui vont devenir des hôtes
Service Guardian
Déployer un hôte protégé à l’aide du mode AD
Déployer un hôte protégé à l’aide du mode TPM
Confirmer que les hôtes protégés peuvent attester
VM dotées d’une protection maximale : Le fournisseur de services
d’hébergement déploie des hôtes Service Guardian dans VMM
Déployer des machines virtuelles protégées
Créer un modèle de machine virtuelle protégée
Préparer un disque dur virtuel d’assistance de protection des machines
virtuelles
Configurer Windows Azure Pack
Créer un fichier de données de protection
Déployez une machine virtuelle protégée à l’aide de Windows Azure Pack
Déploiement d’une machine virtuelle protégée à l’aide de Virtual Machine
Manager
Rubrique opérations et gestion

Gestion du service Guardian hôte
Article • 11/04/2023
Le rôle Hyper-V dans Windows Server vous permet de créer un environnement

informatique virtualisé dans lequel vous pouvez créer et gérer des machines virtuelles.
Vous pouvez exécuter plusieurs systèmes d’exploitation sur un ordinateur physique et
isoler les systèmes d’exploitation les uns des autres. Avec cette technologie, vous
pouvez améliorer l’efficacité de vos ressources informatiques et libérer vos ressources
matérielles.
Consultez les rubriques du tableau suivant pour en savoir plus sur Hyper-V sur Windows
Server.
Ressources Hyper-V pour les professionnels de

l’informatique
Tâche Ressources
Évaluer Hyper-V
- Présentation de la technologie Hyper-V

- Nouveautés de Hyper-V sur Windows Server
- Configuration requise pour Hyper-V sur Windows Server
- Systèmes d’exploitation invités Windows pris en charge pour Hyper-V
- Machines virtuelles Linux et FreeBSD prises en charge
- Compatibilité des fonctionnalités par génération et invité
Planifier pour Hyper-V
- Dois-je créer une machine virtuelle de génération 1 ou 2 dans Hyper-V ?

- Planifier l’extensibilité Hyper-V dans Windows Server
- Planifier la mise en réseau Hyper-V dans Windows Server
- Planifier la sécurité Hyper-V dans Windows Server
Tâche Ressources
Bien démarrer avec Hyper-V
- Télécharger et installer Windows Server 2019
Option d’installation minimale ou avec interface graphique de Windows Server 2019

en tant qu’hôte de machine virtuelle
- Installer le rôle Hyper-V sur Windows Server

- Créer un commutateur virtuel pour les ordinateurs virtuels Hyper-V
- Créer une machine virtuelle avec Hyper-V
Mettre à niveau des ordinateurs hôtes et des machines virtuelles Hyper-V
- Mettre à niveau des nœuds de cluster Windows Server

- Mettre à niveau la version de la machine virtuelle
Configurer et gérer Hyper-V
- Configurer des hôtes une migration dynamique sans clustering de basculement

- Gestion de Nano Server à distance
- Choisir entre des points de contrôle standard ou de production
- Activer ou désactiver des points de contrôle
- Gérer des machines virtuelles Windows avec PowerShell Direct
- Configurer le réplica Hyper-V
Blogs
Consultez les dernières publications des responsables de programme, des chefs de

produit, des développeurs et des testeurs des équipes de virtualisation Microsoft et
Hyper-V.
- Blog de virtualisation
- Blog Windows Server
- Blog sur la virtualisation de Ben Armstrong (archive)
Forum et groupes de discussion
Vous avez des questions ? Parlez à vos pairs, aux MVP et à l’équipe produit Hyper-V.
- Communauté Windows Server

- Forum TechNet pour Windows Server Hyper-V
Technologies associées
Le tableau suivant répertorie les technologies que vous pouvez utiliser dans votre
environnement informatique de virtualisation.
Technology Description
Technology Description
Client Technologie de virtualisation incluse avec Windows 8, Windows 8.1 et Windows 10

Hyper-V que vous pouvez installer via Programmes et fonctionnalités dans le Panneau de
configuration.
Clustering Fonctionnalité Windows Server qui fournit une haute disponibilité pour les
de machines virtuelles et les ordinateurs hôtes Hyper-V.
basculement
Virtual Composant System Center qui fournit une solution de gestion pour le centre de
Machine données virtualisé. Vous pouvez configurer et gérer vos hôtes de virtualisation, vos
Manager réseaux et vos ressources de stockage afin de pouvoir créer et déployer des
machines virtuelles et des services sur des clouds privés que vous avez créés.
Conteneurs Utilisez des conteneurs Windows Server et Hyper-V pour fournir des
Windows environnements normalisés pour les équipes de développement, de test et de
production.
Vue d’ensemble de la technologie
Hyper-V
Article • 11/04/2023
S’applique à : Windows Server 2022, Windows Server 2016, Microsoft Hyper-V

Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019
Hyper-V est le produit de virtualisation de matériel de Microsoft. Il vous permet de créer

et d’exécuter une version logicielle d’un ordinateur : une machine virtuelle. Chaque
machine virtuelle agit comme un ordinateur complet, exécutant un système
d’exploitation et des programmes. Lorsque vous avez besoin de ressources
informatiques, les machines virtuelles vous offrent plus de flexibilité, vous permettent de
gagner du temps et d’économiser de l’argent, et constituent un moyen plus efficace
d’utiliser du matériel que l’exécution d’un seul système d’exploitation sur du matériel
physique.
Hyper-V exécute chaque machine virtuelle dans son propre espace isolé, ce qui signifie
que vous pouvez exécuter plusieurs machines virtuelles sur le même matériel en même
temps. Vous pouvez faire cela pour éviter des problèmes comme un incident affectant
les autres charges de travail, ou pour permettre à différents ensembles de personnes,
groupes ou services d’accéder à différents systèmes.
Comment Hyper-V peut vous aider

Hyper-V peut vous aider à :
Établir ou développer un environnement de nuage privé. Fournir des services

informatiques à la demande plus flexibles en passant à ou en développant votre
utilisation des ressources partagées, et ajuster l’utilisation en fonction de
l’évolution de la demande.
Utiliser votre matériel plus efficacement. Regrouper les serveurs et les charges de
travail sur des ordinateurs physiques moins nombreux et plus puissants pour
utiliser moins d’énergie et d’espace physique.
Améliorer la continuité des activités. Minimisez l’impact des temps morts planifiés
et non planifiés au niveau de vos charges de travail.
Établir ou développer une infrastructure VDI (Virtual Desktop Infrastructure).

Utilisez une stratégie de bureau centralisée avec VDI pour vous aider à augmenter
la flexibilité de vos opérations et la sécurité des données, mais aussi à simplifier la
conformité aux normes et la gestion des systèmes d’exploitation et des
applications de bureau. Déployez Hyper-V et le serveur hôte de virtualisation des
services Bureau à distance (RD Virtualization Host) sur le même serveur pour
rendre les bureaux virtuels personnels ou les pools de bureaux virtuels accessibles
aux utilisateurs.
Rendre le développement et les tests plus efficaces. Reproduire différents

environnements informatiques sans avoir à acheter ou à gérer tout le matériel dont
vous auriez besoin si vous utilisiez uniquement des systèmes physiques.
Hyper-V et les autres produits de virtualisation

Hyper-V dans Windows et Windows Server remplace les produits de virtualisation
matérielle plus anciens, comme Microsoft Virtual PC, Microsoft Virtual Server et
Windows Virtual PC. Hyper-V offre des fonctionnalités de mise en réseau, de
performances, de stockage et de sécurité non disponibles dans ces produits plus
anciens.
Hyper-V et la plupart des applications de virtualisation tierces qui nécessitent les mêmes
fonctionnalités de processeur ne sont pas compatibles. En effet, les fonctionnalités de
processeur, appelées extensions de virtualisation matérielle, sont conçues pour ne pas
être partagées. Pour plus d’informations, consultez Les applications de virtualisation ne
fonctionnent pas avec Hyper-V, Device Guard et Credential Guard .
Quelles sont les fonctionnalités d’Hyper-V ?

Hyper-V offre de nombreuses fonctionnalités. Il s’agit d’une vue d’ensemble, regroupée
par ce que les fonctionnalités vous fournissent ou vous aident à faire.
Environnement informatique : une machine virtuelle Hyper-V comprend les mêmes

composants de base qu’un ordinateur physique, comme la mémoire, le processeur, le
stockage et la mise en réseau. Toutes ces parties ont des fonctionnalités et des options
qui vous permettent de configurer différentes façons de répondre à différents besoins.
Le stockage et la mise en réseau peuvent chacun être considérés comme des catégories
propres, en raison des nombreuses façons dont vous pouvez les configurer.
Récupération d’urgence et sauvegarde : pour la récupération d’urgence, le réplica

Hyper-V crée des copies des machines virtuelles, destinées à être stockées dans un autre
emplacement physique, afin que vous puissiez restaurer la machine virtuelle à partir de
la copie. Pour la sauvegarde, Hyper-V offre deux types. L’un utilise les états enregistrés
et l’autre utilise le service VSS (Volume Shadow Copy Service) pour vous permettre
d’effectuer des sauvegardes cohérentes avec les applications pour les programmes qui
prennent en charge VSS.
Optimisation : chaque système d’exploitation invité pris en charge dispose d’un

ensemble personnalisé de services et de pilotes, appelés services d’intégration, qui
facilitent l’utilisation du système d’exploitation dans une machine virtuelle Hyper-V.
Portabilité : des fonctionnalités comme la migration dynamique, la migration du

stockage et l’importation/exportation facilitent le déplacement ou la distribution d’une
machine virtuelle.
Connectivité à distance : Hyper-V inclut la connexion de machine virtuelle, un outil de

connexion à distance à utiliser avec Windows et Linux. Contrairement au Bureau à
distance, cet outil vous donne accès à la console, ce qui vous permet de voir ce qui se
passe dans l’invité même lorsque le système d’exploitation n’est pas encore démarré.
Sécurité : le démarrage sécurisé et les machines virtuelles protégées permettent de se

protéger contre les programmes malveillants et autres accès non autorisés à une
machine virtuelle et à ses données.
Pour obtenir un résumé des fonctionnalités introduites dans cette version, consultez
Nouveautés d’Hyper-V sur Windows Server. Certaines fonctionnalités ou parties ont une
limite quant au nombre de fonctionnalités pouvant être configurées. Pour plus
d’informations, consultez Planifier la scalabilité d’Hyper-V dans Windows Server 2016.
Comment obtenir Hyper-V

Hyper-V est disponible dans Windows Server et Windows, en tant que rôle serveur
disponible pour les versions x64 de Windows Server. Pour obtenir des instructions sur le
serveur, consultez Installer le rôle Hyper-V sur Windows Server. Sur Windows, il est
disponible en tant que fonctionnalité dans certaines versions 64 bits de Windows. Il est
également disponible en tant que produit serveur autonome téléchargeable, Microsoft
Hyper-V Server .
Systèmes d’exploitation pris en charge

De nombreux systèmes d’exploitation s’exécutent sur des machines virtuelles. En
général, un système d’exploitation qui utilise une architecture x86 s’exécute sur une
machine virtuelle Hyper-V. Toutefois, tous les systèmes d’exploitation qui peuvent être
exécutés ne sont pas testés et pris en charge par Microsoft. Pour obtenir la liste des
systèmes pris en charge, consultez :
Machines virtuelles Linux et FreeBSD prises en charge pour Hyper-V sur Windows
Systèmes d’exploitation invités Windows pris en charge pour Hyper-V sur Windows
Server
Fonctionnement d’Hyper-V
Hyper-V est une technologie de virtualisation basée sur un hyperviseur. Hyper-V utilise
l’hyperviseur Windows, qui nécessite un processeur physique avec des fonctionnalités
spécifiques. Pour plus d’informations sur le matériel, consultez Configuration système
pour Hyper-V sur Windows Server.
Dans la plupart des cas, l’hyperviseur gère les interactions entre le matériel et les
machines virtuelles. Cet accès contrôlé par l’hyperviseur au matériel donne aux
machines virtuelles l’environnement isolé dans lequel elles s’exécutent. Dans certaines
configurations, une machine virtuelle ou le système d’exploitation qui s’exécute sur la
machine virtuelle a un accès direct au matériel graphique, réseau ou de stockage.
En quoi consiste Hyper-V ?

Hyper-V a des composants requis qui fonctionnent ensemble afin que vous puissiez
créer et exécuter des machines virtuelles. Ensemble, ces parties sont appelées
plateforme de virtualisation. Elles sont installées en tant qu’ensemble lorsque vous
installez le rôle Hyper-V. Parmi les composants requis, citons l’hyperviseur Windows, le
service de gestion d’ordinateurs virtuels Hyper-V, le fournisseur WMI de virtualisation, le
fournisseur de services de virtualisation (VSP, Virtualization Service Provider) et le pilote
d’infrastructure virtuelle (VID).
Hyper-V dispose également d’outils pour la gestion et la connectivité. Vous pouvez les
installer sur l’ordinateur sur lequel le rôle Hyper-V est installé, et sur les ordinateurs sans
le rôle Hyper-V installé. Ces outils sont les suivants :
Gestionnaire Hyper-V
Module Hyper-V pour Windows PowerShell
Connexion de machine virtuelle (parfois appelée VMConnect)
Windows PowerShell Direct
Technologies associées
Voici quelques technologies de Microsoft qui sont souvent utilisées avec Hyper-V :
Clustering de basculement
Services Bureau à distance
System Center Virtual Machine Manager
Différentes technologies de stockage : volumes partagés de cluster, SMB 3.0, espaces de

stockage direct
Les conteneurs Windows offrent une autre approche de la virtualisation. Consultez la

bibliothèque Conteneurs Windows sur MSDN.
Nouveautés de Hyper-V sur Windows
Server
Article • 09/03/2023

Server 2016, Windows Server 2016
Cet article explique les nouveautés et les modifications apportées au fonctionnement

d’Hyper-V sur Windows Server 2019, Windows Server 2016 et Microsoft Hyper-V
Server 2016. Pour utiliser de nouvelles fonctionnalités sur les machines virtuelles créées
avec Windows Server 2012 R2 et déplacées ou importées vers un serveur qui exécute
Hyper-V sur Windows Server 2019 ou Windows Server 2016, vous avez besoin de mettre
à niveau manuellement la version de la configuration de la machine virtuelle. Pour
obtenir des instructions, consultez Mettre à niveau la version de la machine virtuelle.
Voici les points abordés dans cet article précisant si la fonctionnalité est nouvelle ou
mise à jour.
Windows Server, version 1903
Ajouter le Gestionnaire Hyper-V aux installations Server

Core (mise à jour)
Comme vous le savez peut-être, nous recommandons d’utiliser l’option d’installation
Server Core quand vous utilisez le canal semi-annuel de Windows Server en production.
Toutefois, Server Core omet par défaut un certain nombre d’outils de gestion utiles.
Vous pouvez ajouter un grand nombre des outils les plus couramment utilisés en
installant la fonctionnalité de compatibilité des applications, mais certains outils sont
toujours manquants.
Par conséquent, sur la base des commentaires des clients, nous avons ajouté un outil
supplémentaire à la fonctionnalité de compatibilité des applications dans cette version :
le Gestionnaire Hyper-V (virtmgmt.msc).
Pour plus d’informations, consultez Fonctionnalité à la demande de compatibilité des

applications Server Core.
Windows Server 2019

Sécurité : améliorations apportées aux machines
virtuelles dotées d’une protection maximale (nouveauté)
Améliorations pour les filiales
Vous pouvez maintenant exécuter des machines virtuelles dotées d’une protection
maximale sur des ordinateurs ayant une connectivité intermittente au Service
Guardian hôte en tirant parti du nouveau SGH de secours et des fonctionnalités du
mode hors connexion. Le SGH de secours vous permet de configurer un deuxième
ensemble d’URL qu’Hyper-V peut essayer s’il ne peut pas atteindre votre serveur
SGH principal.
Le mode hors connexion vous permet de continuer à démarrer vos machines

virtuelles protégés même si le SGH n’est pas accessible, tant que la machine
virtuelle a démarré avec succès une fois et que la configuration de sécurité de
l’hôte n’a pas changé.
Améliorations de la résolution des problèmes
Nous avons également simplifié le dépannage de vos machines virtuelles en

autorisant la prise en charge du Mode de Session étendu VMConnect et de
PowerShell Direct. Ces outils sont particulièrement utiles si vous avez perdu la
connectivité réseau à votre machine virtuelle et que vous devez mettre à jour sa
configuration pour restaurer l’accès.
Ces fonctionnalités n’ont pas besoin d’être configurées et deviennent

automatiquement disponibles quand une machine virtuelle protégé est placée sur
un ordinateur hôte Hyper-V exécutant Windows Server version 1803 ou ultérieur.
Prise en charge de Linux
Si vous exécutez des environnements à systèmes d’exploitation mixtes, Windows

Server 2019 prend désormais en charge l’exécution d’Ubuntu, Red Hat Enterprise
Linux et SUSE Linux Enterprise Server dans les machines virtuelles.
Windows Server 2016
Compatible avec la veille connectée (nouveauté)

Quand le rôle Hyper-V est installé sur un ordinateur qui utilise le mode d’alimentation
AOAC (Always On/Always Connected), l’état de veille connectée est à présent
disponible.
Attribution d’appareils en mode discret (nouveauté)
Cette fonctionnalité vous permet d’accorder à une machine virtuelle un accès direct et
exclusif à certains appareils matériels PCIe. L’utilisation d’un appareil de cette façon
contourne la pile de virtualisation Hyper-V, ce qui accélère l’accès. Pour plus
d’informations sur le matériel pris en charge, consultez « Attribution d’appareils en
mode discret » dans Configuration système pour Hyper-V sur Windows Server 2016.
Pour plus d’informations, notamment sur l’utilisation de cette fonctionnalité et les points
à prendre en compte, consultez le billet « Attribution d’appareils en mode discret —
Description et contexte » dans le blog Virtualisation.
Prise en charge du chiffrement pour le disque du système

d’exploitation dans les machines virtuelles de
génération 1 (nouveauté)
Vous pouvez à présent protéger le disque du système d’exploitation à l’aide du
chiffrement de lecteur BitLocker sur les machines virtuelles de 1re génération. Une
nouvelle fonctionnalité, le stockage de clés, crée un petit lecteur dédié pour stocker la
clé BitLocker du lecteur système. Cette opération remplace l’utilisation d’un module de
plateforme sécurisée (TPM) virtuel, disponible uniquement dans les machines virtuelles
de 2e génération. Pour déchiffrer le disque et démarrer la machine virtuelle, l’hôte
Hyper-V doit soit faire partie d’une structure fabric gardée autorisée, soit disposer de la
clé privée de l’un des gardiens de la machine virtuelle. Le stockage de clé nécessite une
machine virtuelle de version 8. Pour plus d’informations sur la version de la machine
virtuelle, consultez Mettre à niveau la version de la machine virtuelle dans Hyper-V sur
Windows 10 ou Windows Server 2016.
Protection des ressources de l’hôte (nouveauté)

Cette fonctionnalité permet d’empêcher une machine virtuelle d’utiliser plus que sa part
de ressources système en recherchant les niveaux d’activité excessifs. Elle peut aider à
empêcher toute activité excessive d’une machine virtuelle de dégrader les performances
de l’hôte ou d’autres machines virtuelles. Lorsque le monitoring détecte une machine
virtuelle dont l’activité est excessive, la machine virtuelle reçoit moins de ressources. Ce
monitoring et l’opération qui en découle sont désactivés par défaut. Utilisez Windows
PowerShell pour activer cette fonctionnalité ou la désactiver. Pour l’activer, exécutez
cette commande :
Set-VMProcessor TestVM -EnableHostResourceProtection $true

Pour plus d’informations sur cette applet de commande, consultez Set-VMProcessor.
Ajouter et supprimer à chaud de la mémoire et des cartes

réseau (nouveauté)
Vous pouvez à présent ajouter ou supprimer une carte réseau quand la machine virtuelle
est en cours d’exécution, ce qui permet ainsi d’éviter des temps d’arrêt. Cette
fonctionnalité s’applique aux machines virtuelles de 2e génération qui exécutent soit
Windows, soit Linux.
Vous pouvez aussi ajuster la quantité de mémoire allouée à une machine virtuelle en
cours d’exécution, même si vous n’avez pas activé la mémoire dynamique. Cela
fonctionne pour les machines virtuelles de 1re et de 2e génération, qui exécutent
Windows Server 2016 ou Windows 10.
Améliorations apportées au Gestionnaire Hyper-V (mise à

jour)
Prise en charge d’autres informations d’identification : Vous pouvez désormais
utiliser un jeu différent d’informations d’identification dans le Gestionnaire Hyper-
V quand vous vous connectez à un autre hôte distant Windows Server 2016 ou
Windows 10. Vous pouvez également enregistrer ces informations d’identification
pour faciliter la prochaine connexion.
Gestion des versions antérieures : Grâce au Gestionnaire Hyper-V dans Windows

Server 2019, Windows Server 2016 et Windows 10, vous pouvez gérer des
ordinateurs exécutant Hyper-V sur Windows Server 2012, Windows 8, Windows
Server 2012 R2 et Windows 8.1.
Protocole de gestion mis à jour : Le Gestionnaire Hyper-V communique à présent

avec les hôtes Hyper-V distants à l’aide du protocole WS-MAN, qui autorise une
authentification CredSSP, Kerberos ou NTLM. Quand vous utilisez CredSSP pour
vous connecter à un hôte Hyper-V distant, vous pouvez effectuer une migration
dynamique sans activer la délégation contrainte dans Active Directory.
L’infrastructure WS-MAN facilite également l’activation d’un hôte à des fins de
gestion à distance. WS-MAN se connecte par le biais du port 80 qui est ouvert par
défaut.
Services d’intégration fournis par le biais de Windows
Update (mise à jour)
Les mises à jour des services d’intégration pour les invités Windows sont distribuées par
le biais de Windows Update. Pour les fournisseurs de services et les hébergeurs de cloud
privé, le contrôle de l’application des mises à jour est ainsi mis entre les mains des
locataires propriétaires des machines virtuelles. Les locataires peuvent désormais mettre
à jour leurs machines virtuelles Windows avec toutes les mises à jour, y compris celles
des services d’intégration, à l’aide d’une seule méthode. Pour plus d’informations sur les
services d’intégration pour les invités Linux, consultez Machines Virtuelles Linux et
FreeBSD sur Hyper-V.
） Important
Le fichier image vmguest.iso n’étant plus nécessaire, il n’est plus inclus dans Hyper-
V sur Windows Server 2016.
Démarrage sécurisé de Linux (nouveauté)

Vous pouvez désormais démarrer des systèmes d’exploitation Linux, exécutés sur des
machines virtuelles de 2e génération, avec l’option Démarrage sécurisé activée.
Ubuntu 14.04, SUSE Linux Enterprise Server 12, Red Hat Enterprise Linux 7.0 et
CentOS 7.0 ainsi que leurs versions ultérieures sont compatibles avec le démarrage
sécurisé sur les hôtes qui exécutent Windows Server 2016. Avant de démarrer la
machine virtuelle pour la première fois, vous devez la configurer pour utiliser l’autorité
de certification Microsoft UEFI. Pour cela, vous pouvez utiliser le Gestionnaire Hyper-V,
Virtual Machine Manager ou une session Windows PowerShell avec élévation de
privilèges. Pour Windows PowerShell, exécutez cette commande :
Set-VMFirmware TestVM -SecureBootTemplate MicrosoftUEFICertificateAuthority
Pour plus d’informations sur les machines virtuelles Linux sur Hyper-V, consultez
Machines virtuelles Linux et FreeBSD sur Hyper-V. Pour plus d’informations sur l’applet
de commande, consultez Set-VMFirmware.
Davantage de mémoire et de processeurs pour les hôtes

Hyper-V et les machines virtuelles de 2e génération (mise
à jour)
À compter de la version 8, les machines virtuelles de 2e génération peuvent utiliser
beaucoup plus de mémoire et de processeurs virtuels. Les hôtes peuvent également être
configurés avec beaucoup plus de mémoire et de processeurs virtuels que ce qui était
auparavant pris en charge. Ces changements permettent de prendre en charge de
nouveaux scénarios comme l’exécution de bases de données en mémoire volumineuses
d’e-commerce pour le traitement transactionnel en ligne (OLTP) et l’entreposage de
données. Le blog Windows Server a récemment publié les résultats des performances
d’une machine virtuelle avec 5,5 téraoctets de mémoire et 128 processeurs virtuels
exécutant une base de données en mémoire de 4 To. Les performances étaient
supérieures à 95 % des performances d’un serveur physique. Pour plus d’informations,
consultez Performances de traitement transactionnel en mémoire d’une machine
virtuelle Hyper-V à grande échelle Windows Server 2016 . Pour plus d’informations sur
les versions de machine virtuelle, consultez Mettre à niveau la version de la machine
virtuelle dans Hyper-V sur Windows 10 ou Windows Server 2016. Pour obtenir la liste
complète des configurations maximales prises en charge, consultez Planifier la scalabilité
d’Hyper-V dans Windows Server 2016.
Virtualisation imbriquée (nouveauté)

Cette fonctionnalité vous permet d’utiliser une machine virtuelle en tant qu’hôte Hyper-
V et de créer des machines virtuelles au sein de cet hôte virtualisé. Elle s’avère
particulièrement utile aux environnements de développement et de test. Pour utiliser la
virtualisation imbriquée, vous avez besoin de ceci :
Exécuter au moins Windows Server 2019, Windows Server 2016 ou Windows 10 sur
l’hôte Hyper-V physique et l’hôte virtualisé.
Un processeur avec Intel VT-x (la virtualisation imbriquée est disponible

uniquement pour les processeurs Intel pour le moment).
Pour plus d’informations et pour obtenir des instructions, consultez Exécuter Hyper-V
dans une machine virtuelle avec la virtualisation imbriquée.
Fonctionnalités réseau (nouveauté)

Les nouvelles fonctionnalités réseau incluent :
RDMA (Remote Direct Memory Access) et SET (Switch Embedded Teaming). Vous
pouvez configurer RDMA sur les cartes réseau liées à un commutateur virtuel
Hyper-V, que SET soit également utilisé ou non. SET fournit un commutateur
virtuel avec certaines des mêmes fonctionnalités que l’association de cartes réseau.
Pour plus d’informations, consultez RDMA (Remote Direct Memory Access) et SET
(Switch Embedded Teaming).
VMMQ (Virtual Machine Multi-Queue). Améliore le débit de file d’attente

d’ordinateurs virtuels en allouant plusieurs files d’attente matérielles par machine
virtuelle. La file d’attente par défaut devient un ensemble de files d’attente pour
une machine virtuelle, et le trafic est réparti entre les files d’attente.
Qualité de service (QoS) pour les réseaux à définition logicielle. Gère la classe par
défaut du trafic par le biais du commutateur virtuel au sein de la bande passante
de la classe par défaut.
Pour plus d’informations sur les nouvelles fonctionnalités réseau, consultez Nouveautés
réseau.
Points de contrôle de production (nouveauté)

Les points de contrôle de production sont des images « à un point dans le temps »
d’une machine virtuelle. Celles-ci vous permettent d’appliquer un point de contrôle
conforme aux stratégies de support lorsqu’une machine virtuelle exécute une charge de
travail de production. Les points de contrôle de production sont basés sur la
technologie de sauvegarde à l’intérieur de l’invité au lieu d’un état enregistré. Pour les
machines virtuelles Windows, le service VSS (Volume Snapshot Service) est utilisé. Pour
les machines virtuelles Linux, les tampons du système de fichiers sont vidées pour créer
un point de contrôle cohérent avec le système de fichiers. Si vous préférez utiliser des
points de contrôle basés sur des états enregistrés, choisissez plutôt des points de
contrôle standard. Pour plus d’informations, consultez Choisir entre des points de
contrôle standard ou de production dans Hyper-V.
） Important
Les nouvelles machines virtuelles utilisent des points de contrôle de production par
défaut.
Mise à niveau propagée du cluster Hyper-V (nouveauté)

Vous pouvez maintenant ajouter un nœud exécutant Windows Server 2019 ou Windows
Server 2016 à un cluster Hyper-V avec des nœuds exécutant Windows Server 2012 R2.
Cela vous permet de mettre à niveau le cluster sans temps d’arrêt. Le cluster s’exécute
au niveau de la fonctionnalité Windows Server 2012 R2 jusqu’à ce que vous mettiez à
niveau tous les nœuds du cluster et mettiez à jour le niveau fonctionnel du cluster avec
l’applet de commande Windows PowerShell Update-ClusterFunctionalLevel.
） Important
Une fois que vous avez mis à jour le niveau fonctionnel du cluster, vous ne pouvez
pas revenir à Windows Server 2012 R2.
Pour un cluster Hyper-V avec un niveau fonctionnel Windows Server 2012 R2 avec des
nœuds exécutant Windows Server 2012 R2, Windows Server 2019 et Windows
Server 2016, notez les points suivants :
Gérez le cluster, Hyper-V et les machines virtuelles à partir d’un nœud exécutant
Windows Server 2016 ou Windows 10.
Vous pouvez déplacer des machines virtuelles entre tous les nœuds du cluster
Hyper-V.
Pour utiliser les nouvelles fonctionnalités Hyper-V, tous les nœuds doivent
exécuter Windows Server 2016 et le niveau fonctionnel du cluster doit être mis à
jour.
La version de la configuration des machines virtuelles existantes n’est pas mise à

niveau. Vous pouvez mettre à niveau la version de la configuration uniquement
après avoir mis à niveau le niveau fonctionnel du cluster.
Les machines virtuelles que vous créez sont compatibles avec Windows
Server 2012 R2, au niveau de configuration de machine virtuelle 5.
Après avoir mis à jour le niveau fonctionnel du cluster :
Vous pouvez activer les nouvelles fonctionnalités Hyper-V.
Pour rendre les nouvelles fonctionnalités de machine virtuelle disponibles, utilisez

l’applet de commande Update-vmVersion pour mettre à jour manuellement le
niveau de configuration de la machine virtuelle. Pour obtenir des instructions,
consultez Mettre à niveau la version de la machine virtuelle.
Vous ne pouvez pas ajouter de nœud au cluster Hyper-V qui exécute Windows
Server 2012 R2.
７ Notes
Hyper-V sur Windows 10 ne prend pas en charge le clustering de basculement.

Pour plus d’informations et pour obtenir des instructions, consultez Mise à niveau
propagée de système d’exploitation du cluster.
Disques durs virtuels partagés (mise à jour)

Vous pouvez maintenant redimensionner des disques durs virtuels partagés (fichiers
.vhdx) utilisés pour le clustering invité, sans temps d’arrêt. Les disques durs virtuels
partagés peuvent grossir ou se réduire quand la machine virtuelle est en ligne. Les
clusters invités peuvent désormais également protéger les disques durs virtuels partagés
à l’aide du réplica Hyper-V pour la reprise d’activité.
Activez la réplication sur la collection. L’activation de la réplication sur une collection est
exposée uniquement par le biais de l’interface WMI. Pour plus d’informations,
consultez la documentation relative à la classe Msvm_CollectionReplicationService. Vous
ne pouvez pas gérer la réplication d’une collection par le biais de l’applet de
commande PowerShell ou de l’interface utilisateur. Les machines virtuelles doivent se
trouver sur des hôtes qui font partie d’un cluster Hyper-V pour accéder aux
fonctionnalités propres à une collection. Cela inclut les disques durs virtuels partagés.
Sur des hôtes autonomes, ces derniers ne sont pas pris en charge par le réplica Hyper-V.
Suivez les instructions relatives aux disques durs virtuels partagés dans Vue d’ensemble
du partage de disque dur virtuel et vérifiez que vos disques durs virtuels partagés font
partie d’un cluster invité.
Une collection qui comporte un disque dur virtuel partagé mais aucun cluster invité
associé ne peut pas créer de points de référence pour la collection (que le disque dur
virtuel partagé soit inclus ou non dans la création du point de référence).
Sauvegarde de machines virtuelles (nouveauté)

Si vous sauvegardez une seule machine virtuelle (que l’hôte soit en cluster ou non), vous
ne devez pas utiliser un groupe de machines virtuelles. Vous ne devez pas non plus
utiliser une collection d’instantanés. Les groupes de machines virtuelles et la collection
d’instantanés sont destinés à être utilisés uniquement pour la sauvegarde de clusters
invités qui utilisent un vhdx partagé. Vous avez plutôt intérêt à prendre un instantané à
l’aide du fournisseur Hyper-V WMI v2. De même, n’utilisez pas le fournisseur WMI de
cluster de basculement.
Machines virtuelles dotées d’une protection maximale

(nouveauté)
Les machines virtuelles dotées d’une protection maximale utilisent plusieurs
fonctionnalités pour qu’il soit plus difficile pour les administrateurs Hyper-V et les
programmes malveillants sur l’hôte d’inspecter, de falsifier ou de voler des données à
partir de l’état d’une machine virtuelle protégée. Les données et l’état sont chiffrés, les
administrateurs Hyper-V ne peuvent pas voir la sortie vidéo et les disques, et les
machines virtuelles peuvent être limitées à une exécution sur des hôtes connus et sains
uniquement, comme déterminé par un serveur Guardian hôte. Pour plus d’informations,
consultez Structure fabric gardée et machines virtuelles dotées d’une protection
maximale.
７ Notes
Les machines virtuelles dotées d’une protection maximale sont compatibles avec le
réplica Hyper-V. Pour répliquer une machine virtuelle dotée d’une protection
maximale, l’hôte sur lequel vous souhaitez la répliquer doit être autorisé à exécuter
cette machine virtuelle protégée.
Ordre de priorité du démarrage des machines virtuelles

en cluster (nouveauté)
Cette fonctionnalité vous donne plus de contrôle sur les machines virtuelles en cluster
qui sont démarrées ou redémarrées en premier. Elle facilite ainsi le démarrage des
machines virtuelles qui fournissent des services avant celles qui les utilisent. Définissez
des ensembles, placez des machines virtuelles dans des ensembles et spécifiez des
dépendances. Utilisez des applets de commande Windows PowerShell pour gérer les
ensembles, comme New-ClusterGroupSet, Get-ClusterGroupSet et Add-
ClusterGroupSetDependency. .
Qualité de service (QoS) de stockage (mise à jour)

Vous pouvez maintenant créer des stratégies QoS de stockage sur un serveur de fichiers
avec montée en puissance parallèle et les affecter à un ou plusieurs disques virtuels sur
des machines virtuelles Hyper-V. Les performances de stockage sont automatiquement
réajustées pour répondre aux stratégies quand la charge de stockage varie. Pour plus
d’informations, consultez Qualité de service de stockage.
Format de fichier de configuration de machine virtuelle

(mise à jour)
Les fichiers de configuration de machine virtuelle utilisent un nouveau format qui rend
la lecture et l’écriture des données de configuration plus efficaces. Ce format rend
également l’altération des données moins probable en cas de défaillance du stockage.
Les fichiers de données de configuration de machine virtuelle portent une extension
.vmcx et les fichiers de données d’état d’exécution portent une extension .vmrs.
） Important
L’extension de nom de fichier .vmcx indique un fichier binaire. La modification des

fichiers .vmcx ou .vmrs n’est pas prise en charge.
Version de configuration de la machine virtuelle (mise à

jour)
La version représente la compatibilité des fichiers de configuration, d’état enregistré et
d’instantané de la machine virtuelle avec la version d’Hyper-V. Les machines virtuelles
avec la version 5 sont compatibles avec Windows Server 2012 R2 et peuvent s’exécuter à
la fois sur Windows Server 2012 R2 et Windows Server 2016. Les machines virtuelles
avec des versions introduites dans Windows Server 2016 et Windows Server 2019 ne
s’exécutent pas dans Hyper-V sur Windows Server 2012 R2.
Si vous déplacez ou importez une machine virtuelle dans un serveur qui exécute Hyper-
V sur Windows Server 2016 ou Windows Server 2019 à partir de Windows
Server 2012 R2, la configuration de la machine virtuelle n’est pas automatiquement mise
à jour. Cela signifie que vous pouvez déplacer la machine virtuelle vers un serveur qui
exécute Windows Server 2012 R2. Toutefois, cela signifie également que vous ne pouvez
pas utiliser les nouvelles fonctionnalités de machine virtuelle tant que vous n’avez pas
mis à jour manuellement la version de configuration de la machine virtuelle.
Pour obtenir des instructions sur la vérification et la mise à niveau de la version,

consultez Mettre à niveau la version de la machine virtuelle. Cet article liste également la
version dans laquelle certaines fonctionnalités ont été introduites.
） Important
Après avoir mis à jour la version, vous ne pouvez pas déplacer la machine
virtuelle vers un serveur qui exécute Windows Server 2012 R2.
Vous ne pouvez pas passer la configuration à une version antérieure.
L’applet de commande Update-VMVersion est bloquée sur un cluster Hyper-
V lorsque le niveau fonctionnel du cluster est Windows Server 2012 R2.
Sécurité basée sur la virtualisation pour les machines
virtuelles de 2e génération (nouveauté)
La sécurité basée sur la virtualisation alimente des fonctionnalités comme Device Guard
et Credential Guard, offrant une protection accrue du système d’exploitation contre les
attaques des programmes malveillants. La sécurité basée sur la virtualisation est
disponible sur les machines virtuelles invitées de 2e génération à partir de la version 8.
Pour plus d’informations sur la version de la machine virtuelle, consultez Mettre à niveau
la version de la machine virtuelle dans Hyper-V sur Windows 10 ou Windows
Server 2016.
Conteneurs Windows (nouveauté)

Les conteneurs Windows permettent à de nombreuses applications isolées de s’exécuter
sur un seul système informatique. Ils sont rapides à créer et hautement évolutifs et
portables. Deux types de runtime de conteneur sont disponibles, chacun avec un degré
différent d’isolation des applications. Les conteneurs Windows Server utilisent une
isolation des espaces de noms et des processus. Les conteneurs Hyper-V utilisent une
machine virtuelle légère pour chaque conteneur.
Ses caractéristiques principales sont les suivantes :
Prise en charge des sites web et des applications utilisant HTTPS
Nano Server peut héberger des conteneurs Windows Server et Hyper-V
Possibilité de gérer des données par le biais de dossiers partagés de conteneur
Possibilité de restreindre les ressources de conteneur
Pour plus d’informations, notamment pour accéder aux guides de démarrage rapide,
consultez la documentation sur les conteneurs Windows.
Windows PowerShell Direct (nouveauté)

Cette fonctionnalité vous permet d’exécuter des commandes Windows PowerShell dans
une machine virtuelle à partir de l’hôte. Windows PowerShell Direct s’exécute entre
l’hôte et la machine virtuelle. Cela signifie qu’il ne nécessite pas de mise en réseau ni de
pare-feu et qu’il fonctionne quelle que soit votre configuration de gestion à distance.
Windows PowerShell Direct est une alternative aux outils existants que les
administrateurs Hyper-V utilisent pour se connecter à une machine virtuelle sur un hôte
Hyper-V :
Outils de gestion à distance tels que PowerShell ou Bureau à distance
Connection à une machine virtuelle Hyper-V (VMConnect)
Ces outils fonctionnent bien, mais présentent des contreparties : VMConnect est fiable,
mais peut s’avérer difficile à automatiser. Remote PowerShell est un outil puissant, mais
son installation et sa maintenance peuvent se révéler difficiles. Ces contreparties
peuvent prendre de l’importance à mesure que votre déploiement Hyper-V prend de
l’ampleur. Windows PowerShell Direct résout ce problème en fournissant une expérience
puissante de création de scripts et d’automatisation, aussi simple que l’utilisation de
VMConnect.
Pour connaître la configuration requise et obtenir des instructions, consultez Gérer des
machines virtuelles Windows avec PowerShell Direct.
Configuration système requise pour
Article • 14/04/2023

Hyper-V a des exigences matérielles spécifiques, et certaines fonctionnalités Hyper-V

ont des exigences supplémentaires. Utilisez les détails de cet article pour déterminer les
exigences que votre système doit respecter afin de pouvoir utiliser Hyper-V comme
vous le souhaitez. Ensuite, passez en revue le catalogue Windows Server . Gardez à
l’esprit que la configuration requise pour Hyper-V dépasse la configuration minimale
générale requise pour Windows Server 2016, car un environnement de virtualisation
nécessite davantage de ressources informatiques.
Si vous utilisez déjà Hyper-V, il est probable que vous puissiez utiliser votre matériel
existant. La configuration matérielle générale requise n’a pas changé de manière
significative depuis Windows Server 2012 R2. Toutefois, vous aurez besoin d’un matériel
plus récent pour utiliser des ordinateurs virtuels dotés d’une protection maximale ou
l’attribution discrète de périphérique. Ces fonctionnalités s’appuient sur une prise en
charge matérielle spécifique, comme décrit ci-dessous. En dehors de cela, la principale
différence dans le matériel est que la traduction d’adresse de deuxième niveau (SLAT)
est désormais requise plutôt que recommandée.
Pour plus d’informations sur les configurations maximales prises en charge pour Hyper-
V, telles que le nombre d’ordinateurs virtuels en cours d’exécution, consultez Planifier la
scalabilité d’Hyper-V dans Windows Server 2016. La liste des systèmes d’exploitation
que vous pouvez exécuter sur vos ordinateurs virtuels est abordée dans Systèmes
d’exploitation invités Windows pris en charge pour Hyper-V sur Windows Server.
Conditions générales
Quelles que soient les fonctionnalités Hyper-V que vous souhaitez utiliser, vous aurez
besoin de ce qui suit :
Un processeur 64 bits avec traduction d’adresses de deuxième niveau (SLAT). Pour

installer les composants de virtualisation Hyper-V tels que l’hyperviseur Windows,
le processeur doit disposer de SLAT. Toutefois, il n’est pas nécessaire d’installer des
outils de gestion Hyper-V tels que Connexion à un ordinateur virtuel (VMConnect),
Gestionnaire Hyper-V et les applets de commande Hyper-V pour Windows
PowerShell. Consultez « Comment vérifier la configuration requise pour Hyper-V »
ci-dessous pour savoir si votre processeur dispose de SLAT
Extensions de mode du moniteur d’ordinateur virtuel
Mémoire suffisante : prévoyez au moins 4 Go de RAM. Une quantité supérieure de

mémoire est préférable. Vous aurez besoin de suffisamment de mémoire pour
l’hôte et tous les ordinateurs virtuels que vous souhaitez exécuter en même temps
Prise en charge de la virtualisation activée dans le BIOS ou l’UEFI :
Assistance matérielle à la virtualisation. Elle est disponible dans les processeurs

dotés d’une option de virtualisation, et plus précisément les processeurs dotés
de la technologie Intel VT (Intel Virtualization Technology) ou AMD-V (AMD
Virtualization)
La prévention de l’exécution des données (DEP) appliquée par le matériel doit

être disponible et activée. Pour les systèmes Intel, il s’agit du composant XD Bit
(Execute Disable Bit). Pour les systèmes AMD, il s’agit du composant NX Bit (No
Execute Bit).
Comment vérifier la configuration requise pour

Hyper-V
Ouvrez Windows PowerShell ou une invite de commandes et tapez :
Invite de commandes Windows
Systeminfo.exe
Faites défiler jusqu’à la section sur la configuration requise pour Hyper-V afin de passer
en revue le rapport.
Configuration requise pour des fonctionnalités

spécifiques
Voici les conditions requises pour l’attribution discrète de périphérique et les
ordinateurs virtuels dotés d’une protection maximale. Pour obtenir une description de
ces fonctionnalités, consultez Nouveautés d’Hyper-V sur Windows Server.
Attribution discrète de périphérique
Les exigences de l’hôte sont similaires aux exigences existantes pour la fonctionnalité
SR-IOV dans Hyper-V.
Le processeur doit disposer d’EPT (Extended Page Table) d’Intel ou de NPT (Nested
Page Table) d’AMD.
Le jeu de puces doit avoir ce qui suit :
Remappage d’interruption : VT-d d’Intel avec la fonctionnalité de remappage

d’interruption (VT-d2) ou toute version d’I/O MMU (I/O Memory Management
Unit) AMD
Remappage DMA : VT-d d’Intel avec invalidations en file d’attente ou toute

version d’I/O MMU AMD
Services de contrôle d’accès (ACS) sur les ports racines PCI Express
Les tables de microprogramme doivent exposer l’I/O MMU à l’hyperviseur

Windows. Notez que cette fonctionnalité peut être désactivée dans l’UEFI ou le
BIOS. Pour obtenir des instructions, consultez la documentation matérielle ou
contactez le fabricant de votre matériel
Les périphériques ont besoin d’un GPU ou d’une mémoire express non volatile (NVMe).
Pour le GPU, seuls certains périphériques prennent en charge l’attribution discrète de
périphérique. Pour vérifier, consultez la documentation du matériel ou contactez le
fabricant de votre matériel. Pour plus d’informations sur cette fonctionnalité,
notamment sur son utilisation et les points à prendre en compte, consultez le billet
« Discrete Device Assignment -- Description and background » dans le blog
Virtualisation.
Machines virtuelles dotées d’une protection maximale

Ces ordinateurs virtuels s’appuient sur la sécurité basée sur la virtualisation, et sont
disponibles à partir de Windows Server 2016.
Les conditions requises pour l’hôte sont les suivantes :
UEFI 2.3.1c : prend en charge le démarrage sécurisé et mesuré
Les deux éléments suivants sont facultatifs pour la sécurité basée sur la
virtualisation en général, mais requis pour l’hôte si vous souhaitez bénéficier de la
protection offerte par ces fonctionnalités :
TPM v2.0 : protège les ressources de sécurité de la plateforme
IOMMU (Intel VT-D) : l’hyperviseur peut ainsi fournir une protection d’accès direct
à la mémoire (DMA)
Les conditions requises pour les ordinateurs virtuels sont les suivantes :
Génération 2
Windows Server 2012 ou version ultérieure comme système d’exploitation invité
Systèmes d’exploitation invités Windows
pris en charge pour Hyper-V sur
Windows Server
Article • 07/10/2023
S’applique à : Windows Server 2022, Windows Server 2016, Windows Server 2019,
Azure Stack HCI, version 20H2
Hyper-V prend en charge plusieurs versions des distributions Windows Server, Windows
et Linux pour s’exécuter sur des machines virtuelles, en tant que systèmes d’exploitation
invités. Cet article traite des systèmes d’exploitation invités Windows Server et Windows
pris en charge. Pour les distributions Linux et FreeBSD, consultez Machines virtuelles
Linux et FreeBSD prises en charge pour Hyper-V sur Windows.
Certains systèmes d’exploitation ont les services d’intégration intégrés. D’autres

nécessitent que vous installiez ou mettez à niveau les services d’intégration en une
étape distincte après avoir configuré le système d’exploitation dans la machine virtuelle.
Pour plus d’informations, consultez les sections ci-dessous et Integration Services.
Systèmes d’exploitation invités Windows Server

pris en charge
Voici les versions de Windows Server prises en charge en tant que systèmes
d’exploitation invités pour Hyper-V sur Windows Server.
Système Nombre maximal Integration Services Notes

d’exploitation de processeurs
invité (serveur) virtuels
Windows 240 pour la Intégré Hébergé sur Windows

Server 2022 génération 2 ; Server 2019 ou version
64 pour la ultérieure, Azure Stack
génération 1 ; HCI, version 20H2 ou
1024 disponibles ultérieure.
pour le système
d’exploitation hôte
(partition racine)
Windows Server, 240 pour la Intégré

version 1909 génération 2 ;
64 pour la
génération 1

64 pour la
génération 1

64 pour la
génération 1
Windows 240 pour la Intégré

Server 2019 génération 2 ;
64 pour la
génération 1 ;
320 disponibles pour
le système
(partition racine)

64 pour la
génération 1
Windows 240 pour la Intégré

Server 2016 génération 2 ;
64 pour la
génération 1 ;
320 disponibles pour
le système
(partition racine)
Windows 64 Intégré
Server 2012 R2
Windows 64 Intégré
Server 2012
Windows 64 Installez toutes les mises Éditions Datacenter,

Server 2008 R2 avec à jour Windows critiques Entreprise, Standard et
Service Pack 1 (SP1) après avoir configuré le Web.
système d’exploitation
invité.
Windows 8 Installez toutes les mises Éditions Datacenter,

Server 2008 avec à jour Windows critiques Entreprise, Standard et
Service Pack 2 (SP2) après avoir configuré le Web (32 bits et
système d’exploitation 64 bits).
invité.
Systèmes d’exploitation invités Windows pris

en charge
Voici les versions de Windows client prises en charge en tant que systèmes
d’exploitation invités pour Hyper-V sur Windows Server.
Système Nombre Integration Services Notes

d’exploitation maximal de
client (client) processeurs
virtuels
Windows 11 32 Intégré Machine virtuelle de

génération 2 hébergée sur
Windows Server 2019 ou
version ultérieure, Azure
Stack HCI, version 20H2 ou
ultérieure.
Windows 10 32 Intégré
Windows 8.1 32 Intégré
Windows 7 4 Effectue la mise à niveau Édition Intégrale, Édition

Service Pack 1 des services d’intégration Entreprise et Édition
(SP1) une fois la configuration Professionnel (32 bits et
du système d’exploitation 64 bits).
invité.
Prise en charge du système d’exploitation invité

sur d’autres versions de Windows
Le tableau suivant fournit des liens vers des informations sur les systèmes d’exploitation
invités pris en charge pour Hyper-V sur d’autres versions de Windows.
Système d'exploitation de Rubrique
l'ordinateur hôte
Windows 10 Systèmes d’exploitation invités pris en charge pour Hyper-V

client dans Windows 10
Windows Server 2012 R2 et - Systèmes d'exploitation invités Windows pour Hyper-V pris en
Windows 8.1 charge dans Windows Server 2012 R2 et Windows 8.1
- Machines virtuelles Linux et FreeBSD sur Hyper-V
Windows Server 2012 et Systèmes d'exploitation invités Windows pour Hyper-V pris en
Windows 8 charge dans Windows Server 2012 et Windows 8
Windows Server 2008 et À propos des ordinateurs virtuels et des systèmes d'exploitation
Windows Server 2008 R2 invités
Comment Microsoft assure la prise en charge

des systèmes d’exploitation invités
Microsoft assure la prise en charge des systèmes d’exploitation invités de la façon
suivante :
Les problèmes détectés dans les services d’intégration et systèmes d’exploitation

Microsoft sont pris en charge par le support technique Microsoft.
En ce qui concerne les problèmes dans d’autres systèmes d’exploitation ayant été
certifiés par le fournisseur de système d’exploitation comme fonctionnant sur
Hyper-V, la prise en charge est assurée par le fournisseur.
En ce qui concerne les problèmes détectés dans d’autres systèmes d’exploitation,

Microsoft soumet le problème à la communauté de support multifournisseur,
TSANet .
Références supplémentaires
Machines virtuelles Linux et FreeBSD sur Hyper-V
Systèmes d’exploitation invités pris en charge pour Hyper-V client dans Windows
10
Machines virtuelles Linux et FreeBSD
prises en charge pour Hyper-V sur
Windows Server et Windows
Article • 12/04/2023
S’applique à : Windows Server 2022, Azure Stack HCI, version 20H2 ; Windows
Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2,
Hyper-V Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows
Server 2008 R2, Windows 10 , Windows 8.1, Windows 8, Windows 7.1, Windows 7
Hyper-V prend en charge les appareils spécifiques à Hyper-V et émulés pour les
machines virtuelles Linux et FreeBSD. Lors de l’exécution avec des appareils émulés,
aucun logiciel supplémentaire n’est nécessaire pour être installé. Toutefois, les appareils
émulés ne fournissent pas de performances élevées et ne peuvent pas tirer parti de
l’infrastructure de gestion des machines virtuelles enrichie que la technologie Hyper-V
offre. Pour tirer pleinement parti de tous les avantages offerts par Hyper-V, il est
préférable d’utiliser des appareils spécifiques à Hyper-V pour Linux et FreeBSD. La
collection de pilotes requis pour exécuter des appareils spécifiques à Hyper-V est
appelée Linux Integration Services (LIS) ou FreeBSD Integration Services (BIS).
LIS a été ajouté au noyau Linux et est mis à jour pour les nouvelles versions. Toutefois,
les distributions Linux basées sur des noyaux plus anciens peuvent ne pas avoir les
dernières améliorations ou correctifs. Microsoft fournit un téléchargement contenant
des pilotes LIS installables pour certaines installations Linux basées sur ces noyaux plus
anciens. Étant donné que les fournisseurs de distribution incluent des versions de Linux
Integration Services, il est préférable d’installer la dernière version téléchargeable de LIS,
le cas échéant, pour votre installation.
Pour d’autres distributions Linux, les modifications LIS sont régulièrement intégrées au
noyau et aux applications du système d’exploitation. Par conséquent, aucun
téléchargement ou installation distinct n’est nécessaire.
Pour les versions antérieures de FreeBSD (avant la version 10.0), Microsoft fournit des
ports qui contiennent les pilotes BIS installables et les démons correspondants pour les
machines virtuelles FreeBSD. Pour les versions plus récentes de FreeBSD, BIS est intégré
au système d’exploitation FreeBSD et aucun téléchargement ou installation distinct n’est
requis, à l’exception d’un téléchargement de ports KVP nécessaire pour FreeBSD 10.0.
 Conseil
Télécharger Windows Server dans le Centre d'évaluation.
L’objectif de ce contenu est de fournir des informations qui facilitent votre déploiement
Linux ou FreeBSD sur Hyper-V. Les détails spécifiques sont les suivants :
Distributions Linux ou versions FreeBSD qui nécessitent le téléchargement et

l’installation des pilotes LIS ou BIS.
Distributions Linux ou versions FreeBSD qui contiennent des pilotes LIS ou BIS
intégrés.
Mappages de distribution de caractéristiques qui indiquent les fonctionnalités

dans les principales distributions Linux ou les versions FreeBSD.
Problèmes connus et solutions de contournement pour chaque distribution ou

mise en production.
Description des caractéristiques pour chaque fonctionnalité LIS ou BIS.
Contenu de cette section

Machines virtuelles CentOS et Red Hat Enterprise Linux prises en charge sur Hyper-
V
Machines virtuelles Debian prises en charge sur Hyper-V
Machines virtuelles Oracle Linux prises en charge sur Hyper-V
Machines virtuelles SUSE prises en charge sur Hyper-V
Machines virtuelles Ubuntu prises en charge sur Hyper-V
Machines virtuelles FreeBSD prises en charge sur Hyper-V
Descriptions des fonctionnalités pour les machines virtuelles Linux et FreeBSD sur
Hyper-V
Meilleures pratiques pour l’exécution de Linux sur Hyper-V
Bonnes pratiques pour l’exécution de FreeBSD sur Hyper-V

Machines virtuelles CentOS et Red Hat Enterprise Linux
prises en charge sur Hyper-V
Article • 14/04/2023
S’applique à : Azure Stack HCI; Windows Server 2022, Windows Server Windows Server 2019, Hyper-V Server Windows
Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-V Server 2012 R2,
Windows 11, Windows 10, Windows 8.1
Les tableaux de distribution de fonctionnalités suivants indiquent quelles fonctionnalités sont présentes dans les versions
intégrées et téléchargeables des services d’intégration Linux. Les problèmes connus et les solutions de contournement pour
chaque distribution sont répertoriés après les tableaux.
Les pilotes intégrés Red Hat Enterprise Linux Integration Services pour Hyper-V (disponibles à compter de Red Hat
Enterprise Linux 6.4) suffisent pour permettre aux invités Red Hat Enterprise Linux de s’exécuter à l’aide des appareils
synthétiques hautes performances sur les hôtes Hyper-V. Ces pilotes intégrés sont certifiés par Red Hat pour cette
utilisation. Les configurations certifiées sont indiquées sur cette page web Red Hat : Catalogue de certification Red Hat . Il
n’est pas nécessaire de télécharger ni d’installer des packages des services d’intégration Linux à partir du Centre de
téléchargement Microsoft. Cela pourrait limiter la prise en charge de Red Hat, comme décrit dans l’article 1067 de la base de
connaissances de Red Hat : Base de connaissances Red Hat 1067 .
En raison de conflits potentiels entre la prise en charge LIS intégrée et la prise en charge LIS téléchargeable quand vous
mettez à niveau le noyau, désactivez les mises à jour automatiques, désinstallez les packages téléchargeables LIS, mettez à
jour le noyau, redémarrez, puis installez la dernière version des services LIS, puis redémarrez à nouveau.
７ Notes
Les informations de certification Red Hat Enterprise Linux officielles sont disponibles via le portail des clients Red
Hat .
Dans cette section :
Série 9.x de RHEL/CentOS
Remarques
Légende du tableau
Intégré : les services d’intégration Linux (LIS) sont inclus dans cette distribution Linux. Les numéros de version du
module noyau pour les services LIS intégrés (comme indiqué par lsmod par exemple) différent des numéros de version
indiqués sur le package de téléchargement LIS fourni par Microsoft. Cette différence ne signifie pas que les services LIS
intégrés sont obsolètes.
✔ : fonctionnalité disponible
(vide) : fonctionnalité non disponible

Fonctionnalité Système d’exploitation hôte 9.x
Disponibilité LIS Intégré
Base Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Heure exacte Windows Server 2016 Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
>256 processeurs virtuels ✔
Mise en réseau
Trames Jumbo Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Marquage et jonction de réseaux locaux virtuels Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Migration dynamique Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Injection d’adresses IP statiques Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 2
vRSS Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Segmentation TCP et déchargements de somme de contrôle Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
SR-IOV Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
Stockage
Redimensionnement de VHDX Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Fibre Channel virtuel Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 3
Sauvegarde dynamique de machine virtuelle Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 5
Prise en charge de TRIM Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
WWN SCSI Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Mémoire
Prise en charge du noyau PAE Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI
Configuration de l’écart MMIO Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Mémoire dynamique – Ajout à chaud Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 9, 10
Mémoire dynamique – Ballooning Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 9, 10
Redimensionnement de la mémoire d’exécution Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
Vidéo
Appareil vidéo spécifique à Hyper-V Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Divers
Paire clé-valeur Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Interruption non masquable Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Copie de fichiers de l’hôte vers l’invité Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Commande lsvmbus Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔
Sockets Hyper-V Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
Pass-through PCI/DDA Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
Ordinateurs virtuels de génération 2
Démarrage en mode UEFI Windows Server 2022, 2019, 2016, 2012 R2 Azure Stack HCI ✔ Note 14, 17
Démarrage sécurisé Windows Server 2022, 2019, 2016 Azure Stack HCI ✔
Fonctionnalité Système d’exploitation hôte 8.1-8.6 8.0
Disponibilité LIS Intégré Intégré
Base Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Heure exacte Windows Server 2016 Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔
>256 processeurs virtuels ✔
Mise en réseau
Trames Jumbo Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Marquage et jonction de réseaux locaux virtuels Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
Migration dynamique Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Injection d’adresses IP statiques Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 2 ✔ Note 2
Stack HCI
vRSS Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Segmentation TCP et déchargements de somme de Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
contrôle Stack HCI
SR-IOV Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔
Stockage
Redimensionnement de VHDX Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Fibre Channel virtuel Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 3 ✔ Note 3
Stack HCI
Sauvegarde dynamique de machine virtuelle Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 5 ✔ Note 5
Stack HCI
Prise en charge de TRIM Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
WWN SCSI Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Mémoire
Prise en charge du noyau PAE Windows Server 2022, 2019, 2016, 2012 R2 Azure N/A N/A
Stack HCI
Configuration de l’écart MMIO Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
Mémoire dynamique – Ajout à chaud Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 9, ✔ Note 9,
Stack HCI 10 10
Mémoire dynamique – Ballooning Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 9, ✔ Note 9,
Stack HCI 10 10
Redimensionnement de la mémoire d’exécution Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔
Vidéo
Fonctionnalité Système d’exploitation hôte 8.1-8.6 8.0
Appareil vidéo spécifique à Hyper-V Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
Divers
Paire clé-valeur Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Interruption non masquable Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
Copie de fichiers de l’hôte vers l’invité Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔
Stack HCI
Commande lsvmbus Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ ✔

Stack HCI
Sockets Hyper-V Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔
Pass-through PCI/DDA Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔
Démarrage en mode UEFI Windows Server 2022, 2019, 2016, 2012 R2 Azure ✔ Note 14, ✔ Note 14
Stack HCI 17
Démarrage sécurisé Windows Server 2022, 2019, 2016 Azure Stack HCI ✔ ✔

Cette série comprend uniquement des noyaux 64 bits.
Fonctionnalité Système 7.5-7.7 7.3-7.4 7.0-7.2 7.6-7.9 7.5 7.4 7.3 7.2 7.1 7.0
d’exploitation
hôte
Disponibilité LIS LIS 4.3 LIS 4.3 LIS 4.3 Intégré Intégré Intégré Intégré Intégré Intégré Intégré
Base Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Heure exacte Windows ✔ ✔ ✔ ✔ ✔

Windows Server 2022,
Server 2016 2019, 2016
Azure Stack
HCI
>256 processeurs ✔
virtuels Note 16
Mise en réseau
Trames Jumbo Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
d’exploitation
hôte
Marquage et Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
jonction de réseaux Server 2022,
locaux virtuels 2019, 2016,
2012 R2
Azure Stack
HCI
Migration Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Injection Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
d’adresses IP Server 2022, Note 2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2
statiques 2019, 2016,
2012 R2
Azure Stack
HCI
vRSS Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Segmentation TCP Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

et déchargements Server 2022,
de somme de 2019, 2016,
contrôle 2012 R2
Azure Stack
HCI
SR-IOV Windows ✔ ✔ ✔ ✔ ✔
Server 2022,
2019, 2016
Azure Stack
HCI
Stockage
Redimensionnement Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
de VHDX Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Fibre Channel virtuel Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022, Note 3 Note 3 Note 3 Note 3 Note 3 Note 3 Note 3 Note 3 Note 3 Note 3
2019, 2016,
2012 R2
Azure Stack
HCI
Sauvegarde Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique de Server 2022, Note 5 Note 5 Note 5 Note 4, Note 4, Note 4, Note 4, Note 4, Note 4, Note 4,
machine virtuelle 2019, 2016, 5 5 5 5 5 5 5
2012 R2
Azure Stack
HCI
d’exploitation
hôte
Prise en charge de Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

TRIM Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
WWN SCSI Windows ✔ ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Mémoire
Prise en charge du Windows N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A
noyau PAE Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Configuration de Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
l’écart MMIO Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Mémoire Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique – Ajout Server 2022, Note 8, Note 8, Note 8, Note 8, Note 9, Note 9, Note 9, Note 9, Note 9, Note 8,
à chaud 2019, 2016, 9, 10 9, 10 9, 10 9, 10 10 10 10 10 10 9, 10
2012 R2
Azure Stack
HCI
Mémoire Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique – Server 2022, Note 9, Note 9, Note 9, Note 9, Note 9, Note 9, Note 9, Note 9, Note 9, Note 9,
Ballooning 2019, 2016, 10 10 10 10 10 10 10 10 10 10
2012 R2
Azure Stack
HCI
Redimensionnement Windows ✔ ✔ ✔
de la mémoire Server 2022,
d’exécution 2019, 2016
Azure Stack
HCI
Vidéo
Appareil vidéo Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

spécifique à Hyper- Server 2022,
V 2019, 2016,
2012 R2
Azure Stack
HCI
Divers
d’exploitation
hôte
Paire clé-valeur Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022, Note 4 Note 4 Note 4 Note 4 Note 4 Note 4 Note 4
2019, 2016,
2012 R2
Azure Stack
HCI
Interruption non Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

masquable Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Copie de fichiers de Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

l’hôte vers l’invité Server 2022, Note 4 Note 4 Note 4 Note 4 Note 4 Note 4
2019, 2016,
2012 R2
Azure Stack
HCI
Commande lsvmbus Windows ✔ ✔ ✔

Server 2022,
2019, 2016,
2012 R2
Azure Stack
HCI
Sockets Hyper-V Windows ✔ ✔ ✔

Server 2022,
2019, 2016
Pass-through Windows ✔ ✔ ✔ ✔ ✔ ✔
PCI/DDA Server 2022,
2019, 2016
Azure Stack
HCI
Ordinateurs virtuels
de génération 2
Démarrage en Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
mode UEFI Server 2022, Note 14 Note 14 Note 14 Note 14 Note 14 Note 14 Note 14 Note 14 Note 14 Note 14
2019, 2016,
2012 R2
Azure Stack
HCI
Démarrage sécurisé Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔

Server 2022,
2019, 2016
Azure Stack
HCI

Le noyau 32 bits de cette série est activé pour l’extension d’adresse physique (PAE). Il n’existe pas de prise en charge LIS
intégrée pour RHEL/CentOS 6.0-6.3.
Fonctionnalité Système d’exploitation 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.6, 6.7 6.5 6.4
hôte 6.9, 6.8
hôte 6.9, 6.8
Disponibilité LIS LIS 4.3 LIS 4.3 LIS 4.3 Intégré Intégré Intégré Intégré
Base Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Heure exacte Windows Windows Server 2022,

Server 2016 2019, 2016
Azure Stack HCI
>256 processeurs virtuels
Mise en réseau
Trames Jumbo Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Marquage et jonction de réseaux Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

locaux virtuels 2019, 2016, 2012 R2 Note 1 Note 1 Note 1 Note 1 Note 1 Note 1 Note 1
Azure Stack HCI
Migration dynamique Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Injection d’adresses IP statiques Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2 Note 2
Azure Stack HCI
vRSS Windows Server 2022, ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Segmentation TCP et Windows Server 2022, ✔ ✔ ✔ ✔ ✔

déchargements de somme de 2019, 2016, 2012 R2
contrôle Azure Stack HCI
SR-IOV Windows Server 2022,

2019, 2016
Azure Stack HCI
Stockage
Redimensionnement de VHDX Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Fibre Channel virtuel Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2 Note 3 Note 3 Note 3 Note 3 Note 3 Note 3
Azure Stack HCI
Sauvegarde dynamique de Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

machine virtuelle 2019, 2016, 2012 R2 Note 5 Note 5 Note 5 Note 4, Note 4, Note 4, Note 4,
Azure Stack HCI 5 5 5, 6 5, 6
Prise en charge de TRIM Windows Server 2022, ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
WWN SCSI Windows Server 2022, ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Mémoire
hôte 6.9, 6.8
Prise en charge du noyau PAE Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Configuration de l’écart MMIO Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Mémoire dynamique – Ajout à Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔

chaud 2019, 2016, 2012 R2 Note 7, Note 7, Note 7, Note 7, Note 7, Note 7,
Azure Stack HCI 9, 10 9, 10 9, 10 9, 10 8, 9, 10 8, 9, 10
Mémoire dynamique – Ballooning Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2 Note 7, Note 7, Note 7, Note 7, Note 7, Note 7, Note 7,
Azure Stack HCI 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10 9, 10, 11
Redimensionnement de la Windows Server 2022,

mémoire d’exécution 2019, 2016
Azure Stack HCI
Vidéo
Appareil vidéo spécifique à Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔

Hyper-V 2019, 2016, 2012 R2
Azure Stack HCI
Divers
Paire clé-valeur Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2 Note 12 Note 12 Note 12, Note 12,
Azure Stack HCI 13 13
Interruption non masquable Windows Server 2022, ✔ ✔ ✔ ✔ ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Copie de fichiers de l’hôte vers Windows Server 2022, ✔ ✔ ✔ ✔ ✔

l’invité 2019, 2016, 2012 R2 Note 12 Note 12
Azure Stack HCI
Commande lsvmbus Windows Server 2022, ✔ ✔ ✔

2019, 2016, 2012 R2
Azure Stack HCI
Sockets Hyper-V Windows Server 2022, ✔ ✔ ✔

2019, 2016
Azure Stack HCI
Pass-through PCI/DDA Windows Server 2022, ✔

2019, 2016
Azure Stack HCI
Ordinateurs virtuels de
génération 2
Démarrage en mode UEFI Windows Server 2022, ✔ ✔ ✔ ✔

2019, 2016, 2012 R2 Note 14 Note 14 Note 14 Note 14
Azure Stack HCI
Démarrage sécurisé Windows Server 2022,

2019, 2016
Azure Stack HCI

Cette série dispose d’un noyau PAE 32 bits pris en charge. Il n’existe pas de prise en charge LIS intégrée pour RHEL/CentOS
avant la version 5.9.
Fonctionnalité Système d’exploitation hôte 5.2-5.11 5.2-5.11 5.9-5.11
Disponibilité LIS LIS 4.3 LIS 4.1 Intégré
Base Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Heure exacte Windows Server 2016 Windows Server 2022, 2019, 2016
Azure Stack HCI
>256 processeurs virtuels
Mise en réseau
Trames Jumbo Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Marquage et jonction de réseaux locaux virtuels Windows Server 2022, 2019, 2016, ✔ Note 1 ✔ Note 1 ✔ Note 1
2012 R2
Azure Stack HCI
Migration dynamique Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Injection d’adresses IP statiques Windows Server 2022, 2019, 2016, ✔ Note 2 ✔ Note 2 ✔ Note 2
2012 R2
Azure Stack HCI
vRSS Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Segmentation TCP et déchargements de somme Windows Server 2022, 2019, 2016, ✔ ✔

de contrôle 2012 R2
Azure Stack HCI
SR-IOV Windows Server 2022, 2019, 2016

Azure Stack HCI
Stockage
Redimensionnement de VHDX Windows Server 2022, 2019, 2016, ✔ ✔

2012 R2
Azure Stack HCI
Fibre Channel virtuel Windows Server 2022, 2019, 2016, ✔ Note 3 ✔ Note 3
2012 R2
Azure Stack HCI
Sauvegarde dynamique de machine virtuelle Windows Server 2022, 2019, 2016, ✔ Note 5, 15 ✔ Note 5 ✔ Note 4,
2012 R2 5, 6
Azure Stack HCI
Prise en charge de TRIM Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
WWN SCSI Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Mémoire
Fonctionnalité Système d’exploitation hôte 5.2-5.11 5.2-5.11 5.9-5.11
Prise en charge du noyau PAE Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Configuration de l’écart MMIO Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Mémoire dynamique – Ajout à chaud Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Mémoire dynamique – Ballooning Windows Server 2022, 2019, 2016, ✔ Note 7, 9, ✔ Note 7, 9,
2012 R2 10, 11 10, 11
Azure Stack HCI
Redimensionnement de la mémoire d’exécution Windows Server 2022, 2019, 2016

Azure Stack HCI
Vidéo
Appareil vidéo spécifique à Hyper-V Windows Server 2022, 2019, 2016, ✔ ✔

2012 R2
Azure Stack HCI
Divers
Paire clé-valeur Windows Server 2022, 2019, 2016, ✔ ✔

2012 R2
Azure Stack HCI
Interruption non masquable Windows Server 2022, 2019, 2016, ✔ ✔ ✔

2012 R2
Azure Stack HCI
Copie de fichiers de l’hôte vers l’invité Windows Server 2022, 2019, 2016, ✔ ✔
2012 R2
Azure Stack HCI
Commande lsvmbus Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Sockets Hyper-V Windows Server 2022, 2019, 2016

Azure Stack HCI
Pass-through PCI/DDA Windows Server 2022, 2019, 2016

Azure Stack HCI
Démarrage en mode UEFI Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Démarrage sécurisé Windows Server 2022, 2019, 2016

Azure Stack HCI
Notes
1. Pour cette version RHEL/CentOS, le marquage VLAN fonctionne, mais pas la jonction VLAN.
2. L’injection d’adresses IP statiques peut ne pas fonctionner si le Gestionnaire de réseau a été configuré pour une carte
réseau synthétique donnée sur la machine virtuelle. Pour un bon fonctionnement de l’injection d’adresses IP statiques,
assurez-vous que le Gestionnaire de réseau est soit complètement désactivé, soit qu’il a été désactivé pour une carte
réseau spécifique via le fichier ifcfg-ethX.
3. Sur Windows Server 2012 R2, en cas d’utilisation d’appareils Fibre Channel virtuel, assurez-vous que le numéro d’unité
logique 0 (LUN 0) a été rempli. Si le numéro d’unité logique 0 n’a pas été rempli, il est possible qu’une machine
virtuelle Linux ne soit pas en mesure de monter des appareils Fibre Channel en mode natif.
4. Pour les services d’intégration Linux (LIS) intégrés, le package « hyperv-daemons » doit être installé pour cette
fonctionnalité.
5. Si des descripteurs de fichiers sont ouverts pendant une opération de sauvegarde de machine virtuelle dynamique, il
peut être nécessaire, dans certains cas particuliers, de soumettre les disques VHD sauvegardés à une vérification de
cohérence du système de fichiers (fsck) lors de la restauration. Les opérations de sauvegarde dynamique peuvent
échouer en mode silencieux si un périphérique iSCSI est attaché à la machine virtuelle ou qu’elle dispose d’un
stockage en attachement direct (également appelé disque pass-through).
6. Bien que le téléchargement des services d’intégration Linux soit recommandé, la prise en charge de la sauvegarde
dynamique pour RHEL/CentOS 5.9 – 5.11/6.4/6.5 est également disponible via Essentiels de sauvegarde Hyper-V pour
Linux .
7. La prise en charge de la mémoire dynamique est disponible uniquement sur les machines virtuelles 64 bits.
8. La prise en charge de l’ajout à chaud n’est pas activée par défaut dans cette distribution. Pour activer le support de
l’ajout à chaud, vous devez ajouter une règle udev sous /etc/udev/rules.d/ comme suit :
a. Créez un fichier /etc/udev/rules.d/100-balloon.rules. Vous pouvez utiliser le nom de votre choix pour le fichier.
b. Ajoutez le contenu suivant au fichier : SUBSYSTEM=="memory", ACTION=="add", ATTR{state}="online"
c. Redémarrez le système pour activer le support de l’ajout à chaud.
Bien que le téléchargement des services d’intégration Linux crée cette règle lors de l’installation, celle-ci est supprimée
quand les services LIS sont désinstallés. La règle doit donc être recréée si la mémoire dynamique reste nécessaire après
la désinstallation.
9. Les opérations de mémoire dynamique peuvent échouer si la mémoire du système d’exploitation invité est
insuffisante. Voici quelques meilleures pratiques :
La mémoire de démarrage et la mémoire minimale doivent être égales ou supérieures à la quantité de mémoire
recommandée par le fournisseur de la distribution.
Les applications qui ont tendance à consommer toute la mémoire disponible sur un système sont limitées à une
consommation jusqu’à 80 % de la RAM disponible.
10. Si vous utilisez la mémoire dynamique sur un système d’exploitation Windows Server 2016 ou Windows Server
2012 R2, spécifiez les paramètres Mémoire de démarrage, Mémoire minimale et Mémoire maximale en choisissant
des valeurs multiples de 128 mégaoctets (Mo). Dans le cas contraire, cela peut entraîner des défaillances d’ajout à
chaud et la mémoire risque de ne pas être augmentée sur un système d’exploitation invité.
11. Certaines distributions, notamment celles qui utilisent les versions LIS 4.0 et 4.1, prennent en charge le ballooning
uniquement, et non l’ajout à chaud. Dans ce type de scénario, la fonctionnalité de mémoire dynamique peut être
utilisée en définissant le paramètre Mémoire de démarrage sur une valeur égale au paramètre Mémoire maximale.
Cela signifie que toute la mémoire requise fait l’objet d’un ajout à chaud à la machine virtuelle au moment du
démarrage. Selon la mémoire requise par l’hôte, Hyper-V peut ensuite allouer ou libérer librement la mémoire de
l’invité à l’aide du ballooning. Configurez les paramètres Mémoire de démarrage et Mémoire minimale à la valeur
recommandée pour la distribution ou à une valeur supérieure.
12. Pour activer l’infrastructure de paire clé/valeur (KVP), installez le package rpm hypervkvpd ou hyperv-daemons à partir
de votre ISO RHEL. Vous pouvez également installer le package directement à partir de référentiels RHEL.
13. Il est possible que l’infrastructure de paire clé/valeur (KVP) ne fonctionne correctement qu’après une mise à jour
logicielle Linux. Contactez le fournisseur de votre distribution pour obtenir la mise à jour logicielle en cas de problème
avec cette fonctionnalité.
14. Sous Windows Server 2012 R2, le démarrage sécurisé est activé par défaut sur les machines virtuelles de génération 2.
Certaines machines virtuelles Linux ne démarrent pas tant que l’option de démarrage sécurisé n’est pas désactivée.
Vous pouvez désactiver le démarrage sécurisé dans la section Microprogramme des paramètres de la machine
virtuelle dans le Gestionnaire Hyper-V ou à l’aide de PowerShell :
Powershell
Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off
Le téléchargement des services d’intégration Linux peut s’appliquer aux machines virtuelles de génération 2 existantes.
Toutefois, cela ne leur confère aucune capacité de génération 2.
15. Dans Red Hat Enterprise Linux ou CentOS 5.2, 5.3 et 5.4, la fonctionnalité de blocage du système de fichiers n’est pas
disponible. La sauvegarde dynamique de machine virtuelle active n’est donc pas disponible non plus.
16. Pour RHEL 7.6, la prise en charge de >256 processeurs virtuels est disponible dans le noyau 3.10.0-957.38.1 ou
ultérieur. Pour RHEL 7.7, le noyau 3.10.0-1062.4.1 ou version ultérieure est requis.
17. RHEL 8.5 nécessite Windows Server 2019 ou version ultérieure, ou Azure Stack HCI 20H2 ou version ultérieure.
Voir aussi
Set-VMFirmware
Descriptions des fonctionnalités pour les machines virtuelles Linux et FreeBSD sur Hyper-V
Certification matérielle Red Hat

Machines virtuelles Debian prises en
charge sur Hyper-V
Article • 21/06/2023
Server 2019, Hyper-V Server 2019, Windows Server 2016, Hyper-V Server 2016,
Windows Server 2012 R2, Hyper-V Server 2012 R2, Windows 10, Windows 8.1
Cet article décrit la prise en charge des machines virtuelles (VM) Debian sur Hyper-V.
Légende du tableau
Le mappage de distribution des fonctionnalités suivant indique les fonctionnalités
présentes dans chaque version de Windows Server. Les problèmes connus et les
solutions de contournement pour chaque distribution sont répertoriés après le tableau.
Intégré : Linux Integration Services (LIS) est inclus dans le cadre de cette
distribution Linux. Le package de téléchargement LIS fourni par Microsoft ne
fonctionne pas pour cette distribution. N’installez pas le package Microsoft. Les
numéros de version du module noyau pour les services LIS intégrés (comme
indiqué par lsmod par exemple) différent des numéros de version indiqués sur le
package de téléchargement LIS fourni par Microsoft. Cette différence ne signifie
pas que le LIS intégré est obsolète.
Fonctionnalité Version de 11 10.0-10.3

Windows Server (Bullseye) (Buster)
Disponibilité Intégré Intégré
Core 2019, 2016, 2012 R2 ✔ ✔
Heure exacte Windows Server 2016 2019, 2016 ✔ Note 4 ✔ Note 4
Mise en réseau
Trames Jumbo 2019, 2016, 2012 R2 ✔ ✔
Marquage et jonction de réseaux locaux 2019, 2016, 2012 R2 ✔ ✔

virtuels
Migration dynamique 2019, 2016, 2012 R2 ✔ ✔
Injection d’adresses IP statiques 2019, 2016, 2012 R2
vRSS 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4
Segmentation TCP et déchargements de 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4

somme de contrôle
SR-IOV 2019, 2016 ✔ Note 4 ✔ Note 4
Stockage
Redimensionnement de VHDX 2019, 2016, 2012 R2 ✔ Note 1 ✔ Note 1
Fibre Channel virtuel 2019, 2016, 2012 R2
Sauvegarde dynamique de machine virtuelle 2019, 2016, 2012 R2 ✔ Note 2 ✔ Note 2
Prise en charge de TRIM 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4
WWN SCSI 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4
Mémoire
Prise en charge du noyau PAE 2019, 2016, 2012 R2 ✔ ✔
Configuration de l’écart MMIO 2019, 2016, 2012 R2 ✔ ✔
Mémoire dynamique – Ajout à chaud 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4
Mémoire dynamique - Ballooning 2019, 2016, 2012 R2 ✔ Note 4 ✔ Note 4
Redimensionnement de la mémoire de 2019, 2016 ✔ Note 4 ✔ Note 4

runtime
Vidéo
Appareil vidéo spécifique à Hyper-V 2019, 2016, 2012 R2 ✔ ✔
Divers
Paire clé-valeur 2019, 2016, 2012 R2 ✔ Note 2 ✔ Note 2
Interruption non masquable 2019, 2016, 2012 R2 ✔ ✔
Copie de fichiers de l’hôte vers l’invité 2019, 2016, 2012 R2 ✔ Note 2 ✔ Note 2
Commande lsvmbus 2019, 2016, 2012 R2

Sockets Hyper-V 2019, 2016 ✔ Note 4 ✔ Note 4
Pass-through PCI/DDA 2019, 2016 ✔ Note 4 ✔ Note 4
Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 3 ✔ Note 3
Démarrage sécurisé 2019, 2016 ✔ ✔
Notes
1. La création de systèmes de fichiers sur des disques durs virtuels de plus de 2 To
n’est pas prise en charge.
2. À compter de Debian 8.3, le package Debian « hyperv-daemons » installé

manuellement contient la paire clé-valeur, fcopy et les démons VSS. Sur Debian 7.x
et 8.0-8.2, le package hyperv-daemons doit provenir des rétroportages Debian .
3. Sous Windows Server 2012 R2, le démarrage sécurisé est activé par défaut sur les
machines virtuelles de génération 2, et certaines machines virtuelles Linux ne
démarrent que si l’option de démarrage sécurisé est désactivée. Vous pouvez
désactiver le démarrage sécurisé dans la section Microprogramme des paramètres
de l'ordinateur virtuel dans le Gestionnaire Hyper-V ou à l'aide de PowerShell :
PowerShell
4. Les dernières fonctionnalités de noyau en amont sont disponibles uniquement à

l’aide des noyaux disponibles dans le référentiel de rétroportages Debian .
5. Bien que Debian 7.x ne soit plus pris en charge et utilise un noyau plus ancien, le
noyau inclus dans les backports Debian pour Debian 7.x a amélioré les
fonctionnalités Hyper-V.
Voir aussi
V
Machines virtuelles SUSE Linux Enterprise Server (SLES) prises en charge sur Hyper-
V
Hyper-V

Machines virtuelles Oracle Linux prises
en charge sur Hyper-V
Article • 09/03/2023
Hyper-V Server 2012 R2, Windows 10, Windows 8.1

présentes dans chaque version. Les problèmes connus et les solutions de
contournement pour chaque distribution sont répertoriés après le tableau.
Dans cette section :
Série 9.x d’Oracle Linux

Légende du tableau
Intégré : les services d’intégration Linux (LIS) sont inclus dans cette distribution
Linux. Les numéros de version du module noyau pour les LIS intégrés (comme
indiqué par lsmod, par exemple) sont différents des numéros de version sur le
package de téléchargement LIS fourni par Microsoft. Cette différence ne signifie
pas que le LIS intégré est obsolète.
RHCK : noyau compatible Red Hat
UEK : Unbreakable Enterprise Kernel (UEK)

UEK4 - basé sur la version 4.1.12 du noyau Linux en amont
UEK5 - basé sur la version 4.14 du noyau Linux en amont
UEK6 - basé sur la version 5.4 du noyau Linux en amont

Fonctionnalité Version de 9.0 (RHCK)
Windows Server
Disponibilité
Core 2019, 2016, 2012 R2 ✔
Heure exacte Windows Server 2016 2019, 2016 ✔
Mise en réseau
Trames Jumbo 2019, 2016, 2012 R2 ✔
Marquage et jonction de réseaux locaux virtuels 2019, 2016, 2012 R2 ✔
Migration dynamique 2019, 2016, 2012 R2 ✔
Injection d’adresses IP statiques 2019, 2016, 2012 R2 ✔ Note 2
vRSS 2019, 2016, 2012 R2 ✔
Segmentation TCP et déchargements de somme de 2019, 2016, 2012 R2 ✔

contrôle
SR-IOV 2019, 2016 ✔
Stockage
Redimensionnement de VHDX 2019, 2016, 2012 R2 ✔
Fibre Channel virtuel 2019, 2016, 2012 R2 ✔ Note 3
Sauvegarde dynamique de machine virtuelle 2019, 2016, 2012 R2 ✔ Note 5
Prise en charge de TRIM 2019, 2016, 2012 R2 ✔
WWN SCSI 2019, 2016, 2012 R2 ✔
Mémoire
Prise en charge du noyau PAE 2019, 2016, 2012 R2 N/A
Configuration de l’écart MMIO 2019, 2016, 2012 R2 ✔
Mémoire dynamique - Ajout à chaud 2019, 2016, 2012 R2 ✔ Note 7, 8,

9
Mémoire dynamique - Ballooning 2019, 2016, 2012 R2 ✔ Note 7, 8,

9
Redimensionnement de la mémoire de runtime 2019, 2016 ✔
Vidéo
Fonctionnalité Version de 9.0 (RHCK)
Windows Server
Appareil vidéo spécifique à Hyper-V 2019, 2016, 2012 R2 ✔
Divers
Paire clé-valeur 2019, 2016, 2012 R2 ✔
Interruption non masquable 2019, 2016, 2012 R2 ✔
Copie de fichiers de l’hôte vers l’invité 2019, 2016, 2012 R2 ✔
Commande lsvmbus 2019, 2016, 2012 R2 ✔
Sockets Hyper-V 2019, 2016 ✔
Pass-through PCI/DDA 2019, 2016 ✔
Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 12
Démarrage sécurisé 2019, 2016 ✔

Fonctionnalité Version de 8.0-8.5
Windows Server (RHCK)
Disponibilité
Core 2019, 2016, 2012 R2 ✔
Heure exacte Windows Server 2016 2019, 2016 ✔
Mise en réseau
Trames Jumbo 2019, 2016, 2012 R2 ✔
Marquage et jonction de réseaux locaux virtuels 2019, 2016, 2012 R2 ✔
Migration dynamique 2019, 2016, 2012 R2 ✔
Injection d’adresses IP statiques 2019, 2016, 2012 R2 ✔ Note 2
vRSS 2019, 2016, 2012 R2 ✔
Segmentation TCP et déchargements de somme de 2019, 2016, 2012 R2 ✔

contrôle
SR-IOV 2019, 2016 ✔
Stockage
Redimensionnement de VHDX 2019, 2016, 2012 R2 ✔
Fibre Channel virtuel 2019, 2016, 2012 R2 ✔ Note 3
Sauvegarde dynamique de machine virtuelle 2019, 2016, 2012 R2 ✔ Note 5
Prise en charge de TRIM 2019, 2016, 2012 R2 ✔
WWN SCSI 2019, 2016, 2012 R2 ✔
Mémoire
Prise en charge du noyau PAE 2019, 2016, 2012 R2 N/A
Configuration de l’écart MMIO 2019, 2016, 2012 R2 ✔
Mémoire dynamique - Ajout à chaud 2019, 2016, 2012 R2 ✔ Note 7, 8,

9
Mémoire dynamique - Ballooning 2019, 2016, 2012 R2 ✔ Note 7, 8,

9
Redimensionnement de la mémoire de runtime 2019, 2016 ✔
Vidéo
Appareil vidéo spécifique à Hyper-V 2019, 2016, 2012 R2 ✔
Divers
Paire clé-valeur 2019, 2016, 2012 R2 ✔
Interruption non masquable 2019, 2016, 2012 R2 ✔
Copie de fichiers de l’hôte vers l’invité 2019, 2016, 2012 R2 ✔
Commande lsvmbus 2019, 2016, 2012 R2 ✔
Sockets Hyper-V 2019, 2016 ✔
Pass-through PCI/DDA 2019, 2016 ✔
Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 12

Démarrage sécurisé 2019, 2016 ✔

Fonctionnalité Version 7.5-7.8 7.3-7.4

de
Windows
RHCK UEK5 RHCK UEK4
Server
Disponibilité LIS 4.3 Intégré Intégré LIS 4.3 Intégré Intégré
Core 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016,
2012 R2
Heure exacte 2019, ✔ ✔

Windows Server 2016 2016
Mise en réseau
Trames Jumbo 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2
Marquage et jonction 2019, ✔ ✔ ✔ ✔ ✔ ✔

de réseaux locaux 2016,
virtuels 2012 R2
Migration dynamique 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2
Injection d’adresses IP 2019, ✔ ✔ ✔ ✔ ✔ ✔

statiques 2016, Note 2 Note 2 Note 2 Note 2 Note 2 Note 2
2012 R2
vRSS 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016,
2012 R2
Segmentation TCP et 2019, ✔ ✔ ✔ ✔ ✔ ✔

déchargements de 2016,
somme de contrôle 2012 R2
SR-IOV 2019, ✔ ✔ ✔ ✔ ✔ ✔
2016
Stockage
Redimensionnement 2019, ✔ ✔ ✔ ✔ ✔ ✔
de VHDX 2016,
2012 R2
Fibre Channel virtuel 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016, Note 3 Note 3 Note 3 Note 3 Note 3 Note 3
2012 R2
Sauvegarde 2019, ✔ ✔ ✔ ✔ ✔ ✔
dynamique de 2016, Note 5 Note 4, Note 5 Note 5 Note 4, Note 5
machine virtuelle 2012 R2 5 5
Prise en charge de 2019, ✔ ✔ ✔ ✔ ✔ ✔

TRIM 2016,
2012 R2
WWN SCSI 2019, ✔ ✔ ✔ ✔ ✔

2016,
2012 R2
Mémoire
Prise en charge du 2019, N/A N/A N/A N/A N/A N/A

noyau PAE 2016,
2012 R2
Configuration de 2019, ✔ ✔ ✔ ✔ ✔ ✔
l’écart MMIO 2016,
2012 R2
Mémoire dynamique - 2019, ✔ ✔ ✔ ✔ ✔ ✔

Ajout à chaud 2016, Note 7, Note 8, Note 8, Note 8, Note 8, Note 8,
2012 R2 8, 9 9 9 9 9 9
Mémoire 2019, ✔ ✔ ✔ ✔ ✔ ✔
dynamique Ballooning 2016, Note 7, Note 8, Note 8, Note 8, Note 8, Note 8,
2012 R2 8, 9 9 9 9 9 9
Redimensionnement 2019, ✔ ✔ ✔
de la mémoire de 2016
runtime
Vidéo
Vidéo spécifique à 2019, ✔ ✔ ✔ ✔ ✔ ✔

Hyper-V 2016,
2012 R2
Divers
Paire clé-valeur 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2
Interruption non 2019, ✔ ✔ ✔ ✔ ✔ ✔

masquable 2016,
2012 R2
Copie de fichiers de 2019, ✔ ✔ ✔ ✔ ✔ ✔

l’hôte vers l’invité 2016,
2012 R2
Commande lsvmbus 2019, ✔ ✔ ✔ ✔

2016,
2012 R2
Sockets Hyper-V 2019, ✔ ✔ ✔ ✔

2016
Pass-through 2019, ✔ ✔ ✔ ✔ ✔ ✔
PCI/DDA 2016
de génération 2
Démarrage en mode 2019, ✔ ✔ ✔ ✔ ✔ ✔

UEFI 2016, Note 12 Note 12 Note 12 Note 12 Note 12 Note 12
2012 R2
Démarrage sécurisé 2019, ✔ ✔ ✔ ✔ ✔ ✔

2016,
2012 R2

Fonctionnalité Version de 6.8-6.10 6.8-6.10

Windows Server (RHCK) (UEK4)
Disponibilité LIS 4.3 Intégré
Core 2019, 2016, 2012 R2 ✔ ✔

Heure exacte Windows Server 2016 2019, 2016
Mise en réseau
Trames Jumbo 2019, 2016, 2012 R2 ✔ ✔
Marquage et jonction de réseaux locaux 2019, 2016, 2012 R2 ✔ Note 1 ✔ Note 1

virtuels
Migration dynamique 2019, 2016, 2012 R2 ✔ ✔
Injection d’adresses IP statiques 2019, 2016, 2012 R2 ✔ Note 2 ✔
vRSS 2019, 2016, 2012 R2 ✔ ✔
Segmentation TCP et déchargements de 2019, 2016, 2012 R2 ✔ ✔

somme de contrôle
SR-IOV 2019, 2016
Stockage
Redimensionnement de VHDX 2019, 2016, 2012 R2 ✔ ✔
Fibre Channel virtuel 2019, 2016, 2012 R2 ✔ Note 3 ✔ Note 3
Sauvegarde dynamique de machine virtuelle 2019, 2016, 2012 R2 ✔ Note 5 ✔ Note 5
Prise en charge de TRIM 2019, 2016, 2012 R2 ✔ ✔
WWN SCSI 2019, 2016, 2012 R2 ✔ ✔
Mémoire
Prise en charge du noyau PAE 2019, 2016, 2012 R2 N/A N/A
Configuration de l’écart MMIO 2019, 2016, 2012 R2 ✔ ✔
Mémoire dynamique - Ajout à chaud 2019, 2016, 2012 R2 ✔ Note 6, ✔ Note 6,

8, 9 8, 9
Mémoire dynamique - Ballooning 2019, 2016, 2012 R2 ✔ Note 6, ✔ Note 6,

8, 9 8, 9
Redimensionnement de la mémoire de 2019, 2016

runtime
Vidéo
Appareil vidéo spécifique à Hyper-V 2019, 2016, 2012 R2 ✔ ✔

Divers
Paire clé-valeur 2019, 2016, 2012 R2 ✔ Note ✔ Note

10,11 10,11
Interruption non masquable 2019, 2016, 2012 R2 ✔ ✔
Copie de fichiers de l’hôte vers l’invité 2019, 2016, 2012 R2 ✔ ✔
Commande lsvmbus 2019, 2016, 2012 R2 ✔ ✔
Sockets Hyper-V 2019, 2016 ✔ ✔
Pass-through PCI/DDA 2019, 2016 ✔ ✔
Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 12 ✔ Note 12
Démarrage sécurisé 2019, 2016
Notes
1. Pour cette version Oracle Linux, l’étiquetage VLAN fonctionne, mais pas la jonction
VLAN.
2. L’injection d’adresses IP statiques peut ne pas fonctionner si le Gestionnaire de

réseau a été configuré pour une carte réseau synthétique donnée sur la machine
virtuelle. Pour un bon fonctionnement de l’injection d’adresses IP statiques,
assurez-vous que le Gestionnaire de réseau est soit complètement désactivé, soit
qu’il a été désactivé pour une carte réseau spécifique via le fichier ifcfg-ethX.
3. Sur Windows Server 2012 R2, en cas d’utilisation d’appareils Fibre Channel virtuel,
assurez-vous que le numéro d’unité logique 0 (LUN 0) a été rempli. Si le numéro
d’unité logique 0 n’a pas été rempli, il est possible qu’une machine virtuelle Linux
ne soit pas en mesure de monter des appareils Fibre Channel en mode natif.
4. Pour les services d’intégration Linux (LIS) intégrés, le package « hyperv-daemons »

doit être installé pour cette fonctionnalité.
5. Si des descripteurs de fichiers sont ouverts pendant une opération de sauvegarde

de machine virtuelle dynamique, il peut être nécessaire, dans certains cas
particuliers, de soumettre les disques VHD sauvegardés à une vérification de
cohérence du système de fichiers (fsck) lors de la restauration. Les opérations de
sauvegarde dynamique peuvent échouer en mode silencieux si un périphérique
iSCSI est attaché à la machine virtuelle ou s’il dispose d’un stockage en
attachement direct (également appelé disque pass-through).
6. La prise en charge de la mémoire dynamique est disponible uniquement sur les

machines virtuelles 64 bits.
7. La prise en charge de l’ajout à chaud n’est pas activée par défaut dans cette
distribution. Pour activer le support de l’ajout à chaud, vous devez ajouter une
règle udev sous /etc/udev/rules.d/ comme suit :
a. Créez un fichier /etc/udev/rules.d/100-balloon.rules. Vous pouvez utiliser le

nom de votre choix pour le fichier.
b. Ajoutez le contenu suivant au fichier : SUBSYSTEM=="memory", ACTION=="add",

ATTR{state}="online"
c. Redémarrez le système pour activer le support de l’ajout à chaud.
Bien que le téléchargement des services d’intégration Linux crée cette règle lors de
l’installation, celle-ci est supprimée quand les services LIS sont désinstallés. La
règle doit donc être recréée si la mémoire dynamique reste nécessaire après la
désinstallation.
8. Les opérations de mémoire dynamique peuvent échouer si la mémoire du système

d’exploitation invité est insuffisante. Voici quelques meilleures pratiques :
La mémoire de démarrage et la mémoire minimale doivent être égales ou

supérieures à la quantité de mémoire recommandée par le fournisseur de la
distribution.
Les applications qui ont tendance à consommer toute la mémoire disponible

sur un système sont limitées à une consommation jusqu’à 80 % de la RAM
disponible.
9. Si vous utilisez la mémoire dynamique sur un système d’exploitation Windows

Server 2016 ou Windows Server 2012 R2, spécifiez les paramètres Mémoire de
démarrage, Mémoire minimale et Mémoire maximale en choisissant des valeurs
multiples de 128 mégaoctets (Mo). Dans le cas contraire, cela peut entraîner des
défaillances d’ajout à chaud et la mémoire risque de ne pas être augmentée sur un
système d’exploitation invité.
10. Pour activer l’infrastructure de paire clé/valeur (KVP), installez le package rpm
hypervkvpd ou hyperv-daemons à partir de votre ISO Oracle Linux. Vous pouvez
également installer le package directement à partir de référentiels Oracle Linux
Yum.
11. Il est possible que l’infrastructure de paire clé/valeur (KVP) ne fonctionne

correctement qu’après une mise à jour logicielle Linux. Contactez le fournisseur de
votre distribution pour obtenir la mise à jour logicielle en cas de problème avec
cette fonctionnalité.
12. Sous Windows Server 2012 R2, le démarrage sécurisé est activé par défaut sur les
machines virtuelles de génération 2. Certaines machines virtuelles Linux ne
démarrent pas tant que l’option de démarrage sécurisé n’est pas désactivée. Vous
pouvez désactiver le démarrage sécurisé dans la section Microprogramme des
paramètres de la machine virtuelle dans le Gestionnaire Hyper-V ou à l'aide de
Powershell :
Powershell
Le téléchargement des services d’intégration Linux peut s’appliquer aux machines

virtuelles de génération 2 existantes. Toutefois, cela ne leur confère aucune
capacité de génération 2.
Voir aussi
Set-VMFirmware
V
Hyper-V

Machines virtuelles SUSE Linux Enterprise
Server (SLES) prises en charge sur Hyper-V
Article • 27/09/2023
S’applique à : Windows Server 2022, Azure Stack HCI, version 20H2 ; Windows Server 2019,
Hyper-V Server 2019, Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2,
Hyper-V Server 2012 R2, Windows 10, Windows 8.1
Le mappage de distribution des fonctionnalités suivant indique les fonctionnalités de chaque

version. Les problèmes connus et les solutions de contournement pour chaque distribution sont
répertoriés après le tableau.
Les pilotes SUSE Linux Enterprise Service intégrés pour Hyper-V sont certifiés par SUSE. Vous
pouvez consulter un exemple de configuration dans ce bulletin : SUSE YES Certification Bulletin .
Légende du tableau
Intégré : les services d’intégration Linux (LIS) sont inclus dans cette distribution Linux. Le
package de téléchargement LIS fourni par Microsoft ne fonctionne pas pour cette
distribution, donc ne l’installez pas. Les numéros de version du module noyau pour les LIS
intégrés (comme indiqué par lsmod par exemple) sont différents des numéros de version sur
le package de téléchargement LIS fourni par Microsoft. Cette différence ne signifie pas que
les services LIS intégrés sont obsolètes.
SLES12+ est disponible pour les systèmes 64 bits uniquement.
Fonctionnalité Version du système SLES SLES 15 SLES SLES SLES 12 SLES 11 SLES 11
d’exploitation 15 SP1- 12 12 SP2 SP1 SP4 SP3
Windows Server SP4 SP3-
SP5
Disponibilité Intégré Intégré Intégré Intégré Intégré Intégré Intégré
Core WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
2022,2019,2016,2012,AS
HCI
Heure exacte WS/Hyper-V ✔ ✔ ✔ ✔

Windows 2022,2019,2016
Server 2016
Mise en réseau
SP5
Trames Jumbo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012,AS
HCI
Marquage et WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
jonction de réseaux 2022,2019,2016,2012,AS
locaux virtuels HCI
Migration WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique 2022,2019,2016,2012,AS
HCI
Injection WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
d’adresses IP 2022,2019,2016,2012,AS Note 1 Note 1 Note 1 Note 1 Note 1 Note 1 Note 1
statiques HCI
vRSS WS/Hyper-V ✔ ✔ ✔ ✔ ✔
2022,2019,2016,2012,AS
HCI
Segmentation TCP WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

et déchargements 2022,2019,2016,2012,AS
de somme de HCI
contrôle
SR-IOV WS/Hyper-V ✔ ✔ ✔ ✔
2022,2019,2016,2012,AS
HCI
Stockage
Redimensionnement WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
de VHDX 2022,2019,2016,2012,AS
HCI
Fibre Channel virtuel WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012,AS
HCI
Sauvegarde WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique de 2022,2019,2016,2012,AS Note 2, Note 2, Note 2, Note 2, Note 2, Note 2, Note 2,
machine virtuelle HCI 3, 8 3, 8 3, 8 3, 8 3, 8 3, 8 3, 8
Prise en charge de WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

TRIM 2022,2019,2016,2012,
AS HCI
WWN SCSI WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012,
AS HCI
SP5
Mémoire
Prise en charge du WS/Hyper-V N/A N/A N/A N/A N/A ✔ ✔

noyau PAE 2022,2019,2016,2012,
AS HCI
Configuration de WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
l’écart MMIO 2022,2019,2016,2012,
AS HCI
Mémoire WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique - Ajout à 2022,2019,2016,2012, Note 6 Note 6 Note 6 Note 6 Note 6 Note 4, Note 4,
chaud AS HCI 5, 6 5, 6
Mémoire WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique – 2022,2019,2016,2012, Note 6 Note 6 Note 6 Note 6 Note 6 Note 4, Note 4,
Ballooning AS HCI 5, 6 5, 6
Redimensionnement WS/Hyper-V ✔ ✔ ✔ ✔
de la mémoire 2022,2019,2016 Note 6 Note 6 Note 6 Note 6
d’exécution
Vidéo
Appareil vidéo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

spécifique à Hyper- 2022,2019,2016,2012,
V AS HCI
Divers
Paire clé/valeur WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012, Note 7 Note 7
AS HCI
Interruption non WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

masquable 2022,2019,2016,2012,
AS HCI
Copie de fichiers de WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

l’hôte vers l’invité 2022,2019,2016,2012,
AS HCI
Commande lsvmbus WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012,
AS HCI
Sockets Hyper-V WS/Hyper-V ✔ ✔ ✔

2022,2019,2016
Pass-through WS/Hyper-V ✔ ✔ ✔ ✔ ✔
PCI/DDA 2022,2019,2016
SP5
de génération 2
Démarrage en WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔
mode UEFI 2022,2019,2016,2012, Note 9 Note 9 Note 9 Note 9 Note 9 Note 9
AS HCI
Démarrage sécurisé WS/Hyper-V ✔ ✔ ✔ ✔ ✔

2022,2019,2016
Notes
1. L’injection d’adresses IP statiques peut ne pas fonctionner si NetworkManager a été
configuré pour une carte réseau spécifique à Hyper-V donnée sur la machine virtuelle, car
elle peut remplacer les paramètres IP statiques qui ont été configurés manuellement. Pour
garantir le bon fonctionnement de l’injection d’adresses IP statiques, assurez-vous que le
Gestionnaire de réseau est complètement désactivé ou qu’il a été désactivé pour une carte
réseau spécifique via le fichier ifcfg-ethX.
2. Si des descripteurs de fichiers sont ouverts pendant une opération de sauvegarde de

machine virtuelle dynamique, il peut être nécessaire dans certains cas particuliers de
soumettre les disques VHD sauvegardés à une vérification de cohérence du système de
fichiers (fsck) lors de la restauration.
3. Les opérations de sauvegarde dynamique peuvent échouer en mode silencieux si un

périphérique iSCSI est attaché à la machine virtuelle ou qu’elle dispose d’un stockage en
attachement direct (également appelé disque pass-through).

d’exploitation invité est insuffisante. Voici quelques bonnes pratiques :
La mémoire de démarrage et la mémoire minimale doivent être égales ou supérieures

à la quantité de mémoire recommandée par le fournisseur de la distribution.
Les applications qui ont tendance à consommer toute la mémoire disponible sur un
système sont limitées à une consommation jusqu’à 80 % de la RAM disponible.
5. La prise en charge de la mémoire dynamique est disponible uniquement sur les machines
virtuelles 64 bits.
6. Si vous utilisez la mémoire dynamique sur un système d’exploitation Windows Server 2016
ou Windows Server 2012, spécifiez les paramètres Mémoire de démarrage, Mémoire
minimale et Mémoire maximale en choisissant des valeurs multiples de 128 mégaoctets
(Mo). Dans le cas contraire, cela peut entraîner des défaillances d’ajout à chaud et la
mémoire risque de ne pas être augmentée sur un système d’exploitation invité.
7. Dans Windows Server 2016 ou Windows Server 2012 R2, il est possible que l’infrastructure
de paire clé/valeur (KVP) ne fonctionne correctement qu’après une mise à jour logicielle
Linux. Contactez le fournisseur de votre distribution pour obtenir la mise à jour logicielle en
cas de problème avec cette fonctionnalité.
8. La sauvegarde VSS échoue si une partition unique est montée plusieurs fois.
9. Sous Windows Server 2012 R2, le démarrage sécurisé est activé par défaut sur les machines
virtuelles de génération 2. Les machines virtuelles Linux génération 2 ne démarrent pas tant
que l’option de démarrage sécurisé n’est pas désactivée. Vous pouvez désactiver le
démarrage sécurisé dans la section Microprogramme des paramètres de l'ordinateur virtuel
dans le Gestionnaire Hyper-V ou à l'aide de PowerShell :
Powershell
Voir aussi
Set-VMFirmware
Machines virtuelles CentOS et Red Hat Enterprise Linux prises en charge sur Hyper-V
Descriptions des fonctionnalités pour les machines virtuelles Linux et FreeBSD sur Hyper-V

Machines virtuelles Ubuntu prises en
charge sur Hyper-V
Article • 07/10/2023

disponibles dans chaque version. Les problèmes connus et les solutions de
Légende du tableau
Intégré - Linux Integration Services (LIS) est inclus dans le cadre de cette
distribution Linux. Le package de téléchargement LIS fourni par Microsoft ne
fonctionne pas pour cette distribution. Il est donc inutile de l’installer. Les numéros
de version du module noyau pour les LIS intégrés (comme indiqué par lsmod, par
exemple) sont différents des numéros de version sur le package de téléchargement
LIS fourni par Microsoft. Cette différence ne signifie pas que le LIS intégré est
obsolète.
Fonctionnalité Version du système 22.04 20.04 18.04 LTS LTS 16.04

d’exploitation LTS LTS
Windows Server
Disponibilité Intégré Intégré Intégré Intégré
Core 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Heure exacte Windows 2019, 2016 ✔ ✔ ✔ ✔

Server 2016
Mise en réseau
Trames Jumbo 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Marquage et jonction de 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

réseaux locaux virtuels
Windows Server
Migration dynamique 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Injection d’adresses IP 2019, 2016, 2012 R2 ✔ ✔ Note 1 ✔ Note 1 ✔ Note 1

statiques Note 1
vRSS 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Segmentation TCP et 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

déchargements de somme
de contrôle
SR-IOV 2019, 2016 ✔ ✔ ✔ ✔
Stockage
Redimensionnement de 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

VHDX
Fibre Channel virtuel 2019, 2016, 2012 R2 ✔ ✔ Note 2 ✔ Note 2 ✔ Note 2

Note 2
Sauvegarde dynamique de 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

machine virtuelle Note 3, Note 3, Note 3, Note 3,
4, 5 4, 5 4, 5 4, 5
Prise en charge de TRIM 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
WWN SCSI 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Mémoire
Prise en charge du noyau 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

PAE
Configuration de l’écart 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

MMIO
Mémoire dynamique – 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

Ajout à chaud Note 6, Note 6, Note 6, Note 6,
7, 8 7, 8 7, 8 7, 8
Mémoire dynamique - 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

Gonflage Note 6, Note 6, Note 6, Note 6,
7, 8 7, 8 7, 8 7, 8
Redimensionnement de la 2019, 2016 ✔ ✔ ✔ ✔

mémoire d’exécution
Windows Server
Vidéo
Appareil vidéo Hyper-V 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Divers
Paire clé/valeur 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

Note 5, Note 5, 9 Note 5, 9 Note 5, 9
9
Interruption non 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

masquable
Copie de fichiers de l’hôte 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

vers l’invité
Commande lsvmbus 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔
Sockets Hyper-V 2019, 2016 ✔ ✔ ✔ ✔
Pass-through PCI/DDA 2019, 2016 ✔ ✔ ✔ ✔
génération 2
Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ ✔ ✔ ✔

Note 10, Note 10, Note 10,
11 11 11
Démarrage sécurisé 2019, 2016 ✔ ✔ ✔ ✔
Notes
1. L’injection d’adresses IP statiques peut ne pas fonctionner si NetworkManager a
été configuré pour une carte réseau propre à Hyper-V donnée sur la machine
virtuelle, car elle peut remplacer les paramètres IP statiques qui ont été configurés
manuellement. Pour garantir le bon fonctionnement de l’injection d’adresses IP
statiques, assurez-vous que le Gestionnaire de réseau est complètement désactivé
ou qu’il a été désactivé pour une carte réseau spécifique via le fichier ifcfg-ethX.
2. Lors de l’utilisation d’appareils fiber channel virtuels, assurez-vous que le numéro

d’unité logique 0 (LUN 0) a été rempli. Si le numéro d’unité logique 0 n’a pas été
rempli, une machine virtuelle Linux risque de ne pas pouvoir monter des appareils
fiber channel en mode natif.
3. S’il existe des descripteurs de fichiers ouverts pendant une opération de
sauvegarde de machine virtuelle active, dans certains cas particuliers, les VHD
sauvegardés peuvent être soumis à une vérification de cohérence du système de
fichiers ( fsck ) lors de la restauration.
4. Les opérations de sauvegarde dynamique peuvent échouer en silence si la machine

virtuelle dispose d’un périphérique iSCSI attaché ou d’un stockage en attachement
direct (également appelé disque pass-through).
5. Sur les versions de support à long terme (LTS), utilisez le dernier noyau HWE
(Virtual Hardware Enablement) pour profiter des services d’intégration Linux à jour.
Pour installer le noyau réglé pour Azure sur les versions 16.04, 18.04 et 20.04,
exécutez les commandes suivantes en tant qu’utilisateur racine (ou sudo) :
Bash
# apt-get update
# apt-get install linux-azure
6. La prise en charge de la mémoire dynamique n’est disponible que sur les machines
virtuelles 64 bits.

d’exploitation invité vient à manquer. Voici quelques bonnes pratiques :
La mémoire de démarrage et la mémoire minimale doivent être égales ou

supérieures à la quantité de mémoire recommandée par le fournisseur de la
distribution.
Les applications qui ont tendance à consommer toute la mémoire disponible

sur un système sont limitées à une consommation jusqu’à 80 % de la RAM
disponible.
8. Si vous utilisez la Mémoire dynamique sur un système d’exploitation Windows

Server 2019, Windows Server 2016 ou Windows Server 2012/2012 R2, spécifiez les
paramètres Mémoire de démarrage, Mémoire minimale et Mémoire maximale en
choisissant des valeurs multiples de 128 mégaoctets (Mo). Si vous ne le faites pas,
vous risquez d’entraîner des défaillances d’ajout à chaud et vous risquez de ne pas
voir d’augmentation de la mémoire sur un système d’exploitation invité.
9. Dans Windows Server 2019, Windows Server 2016 ou Windows Server 2012 R2,
l’infrastructure de paire clé/valeur peut ne pas fonctionner correctement sans une
mise à jour logicielle Linux. Contactez le fournisseur de votre distribution pour
obtenir la mise à jour logicielle en cas de problème avec cette fonctionnalité.
10. Sur Windows Server 2012 R2, le démarrage sécurisé est activé par défaut sur les
machines virtuelles de génération 2, et certaines machines virtuelles Linux ne
démarrent que si l’option de démarrage sécurisé est désactivée. Vous pouvez
désactiver le démarrage sécurisé dans la section Microprogramme des paramètres
de la machine virtuelle dans le Gestionnaire Hyper-V ou à l’aide de PowerShell :
Powershell
11. Avant d’essayer de copier le VHD d’une machine virtuelle de génération 2 existante
afin de créer de nouvelles machines virtuelles de génération 2, procédez comme
suit :
a. Connectez-vous à la machine virtuelle de génération 2 existante.
b. Remplacez le répertoire par le répertoire EFI de démarrage :
Bash
# cd /boot/efi/EFI
c. Copiez le répertoire d’Ubuntu dans un nouveau répertoire nommé boot :
Bash
# sudo cp -r ubuntu/ boot
d. Remplacez le répertoire par le répertoire de démarrage nouvellement créé :
Bash
# cd boot
e. Renommez le fichier shimx64.efi :
Bash
# sudo mv shimx64.efi bootx64.efi

12. Pour effectuer des migrations dynamiques pour les machines virtuelles configurées
de génération 2, vous devez activer l’option Migrer vers un ordinateur ayant une
autre version de processeur sous Processeur>Compatibilité dans les paramètres de
votre machine virtuelle. Pour en savoir plus, consultez Mode de compatibilité du
processeur dans Hyper-V.
Voir aussi
V
Hyper-V
Bonnes pratiques pour l’exécution de Linux sur Hyper-V
Set-VMFirmware
Ubuntu 14.04 dans une machine virtuelle de génération 2 - Blog de Ben Armstrong
sur la virtualisation
Machines virtuelles FreeBSD prises en
charge sur Hyper-V
Article • 09/03/2023

disponibles dans chaque version. Les problèmes connus et les solutions de
Légende du tableau
Intégré : BIS (FreeBSD Integration Service) est inclus dans cette version de
FreeBSD.
Fonctionnalité Version du 13.0-13.1 12.0-12.3 11.2-11.4 10.4

système
d’exploitation
Windows Server
Disponibilité Intégré Intégré Intégré Intégré
Core 2019, 2016, 2012 ✔ ✔ ✔ ✔

R2
Heure exacte Windows 2019, 2016 ✔ ✔ ✔

Server 2016
Mise en réseau
Trames Jumbo 2019, 2016, 2012 ✔ Note 3 ✔ Note 3 ✔ Note 3 ✔ Note 3

R2
Identification et liaison 2019, 2016, 2012 ✔ ✔ ✔ ✔

VLAN R2
Migration dynamique 2019, 2016, 2012 ✔ ✔ ✔ ✔

R2
système
d’exploitation
Windows Server
Injection d’adresses IP 2019, 2016, 2012 ✔ Note 4 ✔ Note 4 ✔ Note 4 ✔ Note 4

statiques R2
vRSS 2019, 2016, 2012 ✔ ✔ ✔ ✔

R2
Segmentation TCP et 2019, 2016, 2012 ✔ ✔ ✔ ✔

déchargements de R2
somme de contrôle
Déchargement 2019, 2016, 2012 ✔ ✔ ✔ ✔

important à la réception R2
(LRO)
SR-IOV 2019, 2016 ✔ ✔ ✔ ✔
Stockage Remarque Remarque1 Remarque Remarque

1 1 1
Redimensionnement de 2019, 2016, 2012 ✔ Note 6 ✔ Note 6 ✔ Note 6 ✔ Note 6

VHDX R2
Fibre Channel virtuel 2019, 2016, 2012

R2
Sauvegarde dynamique 2019, 2016, 2012 ✔ ✔ ✔

de machine virtuelle R2
Prise en charge de TRIM 2019, 2016, 2012 ✔ ✔ ✔

R2
WWN SCSI 2019, 2016, 2012

R2
Mémoire
Prise en charge du 2019, 2016, 2012

noyau PAE R2
Configuration de 2019, 2016, 2012 ✔ ✔ ✔ ✔

l’espace MMIO R2
Mémoire dynamique - 2019, 2016, 2012

Ajout à chaud R2
Mémoire dynamique - 2019, 2016, 2012

Ballooning R2
système
d’exploitation
Windows Server
Redimensionnement de 2019, 2016

la mémoire de runtime
Vidéo
Appareil vidéo Hyper-V 2019, 2016, 2012

R2
Divers
Paire clé/valeur 2019, 2016, 2012 ✔ ✔ ✔ ✔

R2
Interruption non 2019, 2016, 2012 ✔ ✔ ✔ ✔

masquable R2
Copie de fichiers de 2019, 2016, 2012

l’hôte vers l’invité R2
Commande lsvmbus 2019, 2016, 2012

R2
Sockets Hyper-V 2019, 2016
Pass-through PCI/DDA 2019, 2016 ✔ ✔ ✔
génération 2
Démarrage en mode 2019, 2016, 2012 ✔ ✔ ✔

UEFI R2
Démarrage sécurisé 2019, 2016
Notes
1. Suggérez d’étiqueter les lecteurs de disque pour éviter une erreur de montage
de racine (ROOT MOUNT ERROR) au démarrage.
2. Le lecteur de DVD virtuel peut ne pas être reconnu lorsque les pilotes BIS sont
chargés sur FreeBSD 8.x ou 9.x, sauf si vous activez le pilote ATA hérité via la
commande suivante.
sh
# echo ‘hw.ata.disk_enable=1' >> /boot/loader.conf
# shutdown -r now
3. La taille MTU maximale prise en charge est de 9126.
4. Dans un scénario de basculement, vous ne pouvez pas définir une adresse IPv6
statique dans le serveur réplica. Utilisez une adresse IPv4 à la place.
5. Le KVP est fourni par les ports sur FreeBSD 10.0. Pour plus d’informations,
consultez Ports FreeBSD 10.0 sur FreeBSD.org.
6. Pour que le redimensionnement en ligne de VHDX fonctionne correctement dans

FreeBSD 11.0, vous devez faire manuellement une étape spéciale pour contourner
un bogue GEOM, qui a été résolu dans la version 11.0+ : après que l’hôte a
redimensionné le disque VHDX, ouvrez le disque en écriture et exécutez la
commande « gpart recover » comme suit.
sh
# dd if=/dev/da1 of=/dev/da1 count=0

# gpart recover da1
Autres remarques : La matrice des fonctionnalités de la version 10 stable et de la

version 11 stable est identique à celle de la version 11.1 de FreeBSD. Notez aussi que
FreeBSD 10.2 et les versions antérieures (10.1, 10.0, 9.x, 8.x) sont en fin de vie. Consultez
cette page pour obtenir la liste à jour des versions prises en charge et des derniers
conseils de sécurité.
Voir aussi
Hyper-V
Descriptions des fonctionnalités pour
les machines virtuelles Linux et FreeBSD
sur Hyper-V
Article • 12/04/2023
S’applique à : Windows Server 2022, Windows Server 2019, Azure Stack HCI, version
20H2 ; Windows Server 2016, Hyper-V Server 2016, Windows Server 2012 R2, Hyper-
V Server 2012 R2, Windows Server 2012, Hyper-V Server 2012, Windows Server 2008
R2, Windows 10, Windows 8.1, Windows 8, Windows 7.1, Windows 7
Cet article décrit les fonctionnalités disponibles dans les composants tels que le cœur, la
mise en réseau, le stockage et la mémoire lors de l’utilisation de Linux et de FreeBSD sur
une machine virtuelle.
Core
Fonctionnalité Description
Arrêt intégré Avec cette fonctionnalité, un administrateur peut arrêter les machines virtuelles
à partir du Gestionnaire Hyper-V. Pour plus d’informations, consultez Arrêt du
système d’exploitation.
Synchronisation Cette fonctionnalité garantit que l’heure conservée à l’intérieur d’une machine
de l’heure virtuelle est synchronisée avec l’heure conservée sur l’hôte. Pour plus
d'informations, consultez Synchronisation de l’heure.
Heure exacte Cette fonctionnalité permet à l’invité d’utiliser la fonctionnalité d’heure exacte
Windows Windows Server 2016 précision, qui améliore la synchronisation de l’heure avec
Server 2016 l’hôte à une précision de 1 ms. Pour plus d’informations, consultez Heure
exacte Windows Server 2016
Prise en charge Avec cette fonctionnalité, une machine virtuelle peut utiliser plusieurs
multiprocesseur processeurs sur l’hôte en configurant plusieurs processeurs virtuels.
Heartbeat Avec cette fonctionnalité, l’hôte peut suivre l’état de la machine virtuelle. Pour
plus d’informations, consultez Pulsations.
Prise en charge Avec cette fonctionnalité, vous pouvez utiliser une souris sur le bureau d’une
intégrée de la machine virtuelle et l’utiliser en toute facilité entre le bureau Windows Server et
souris la console Hyper-V pour la machine virtuelle.
Périphérique de Cette fonctionnalité accorde un accès hautes performances aux périphériques

stockage de stockage attachés à une machine virtuelle.
spécifique
Hyper-V
Périphérique Cette fonctionnalité accorde un accès hautes performances aux cartes réseau
réseau attachées à une machine virtuelle.
spécifique
Hyper-V
Mise en réseau
Trames Jumbo Avec cette fonctionnalité, un administrateur peut augmenter la taille des trames
réseau au-delà de 1500 octets, ce qui entraîne une augmentation significative
des performances réseau.
Marquage et Cette fonctionnalité vous permet de configurer le trafic de réseau local virtuel
jonction de (VLAN) pour les machines virtuelles.
réseaux locaux
virtuels
Migration Avec cette fonctionnalité, vous pouvez migrer une machine virtuelle d’un hôte
dynamique vers un autre hôte. Pour plus d’informations, voir Vue d’ensemble de la
migration dynamique de la machine virtuelle.
Injection Avec cette fonctionnalité, vous pouvez répliquer l’adresse IP statique d’une
d’adresses IP machine virtuelle après son basculement vers son réplica sur un autre hôte.
statiques Cette réplication IP garantit que les charges de travail réseau continuent de
fonctionner en toute facilité après un événement de basculement.
vRSS (Mise à Répartit la charge à partir d’une carte réseau virtuelle sur plusieurs processeurs
l’échelle côté virtuels d’une machine virtuelle. Pour plus d’informations, consultez Mise à
réception l’échelle côté réception virtuelle dans Windows Server 2012 R2.
virtuelle)
Segmentation Transfère la segmentation et la somme de contrôle du processeur invité vers le

TCP et commutateur virtuel hôte ou la carte réseau pendant les transferts de données
déchargements réseau.
de somme de
contrôle
Déchargement Augmente le débit entrant des connexions à bande passante élevée en

important à la agrégeant plusieurs paquets dans une mémoire tampon plus importante, ce qui
réception réduit la surcharge du processeur.
(LRO)
SR-IOV Les périphériques d’E/S racines uniques utilisent DDA pour permettre aux
invités d’accéder à des parties de cartes de carte réseau spécifiques, ce qui
permet une latence réduite et un débit accru. SR-IOV nécessite des pilotes de
fonction physique (PF) à jour sur les pilotes de fonction hôte et de fonction
virtuelle (VF) sur l’invité.
Stockage
Redimensionnement Avec cette fonctionnalité, un administrateur peut redimensionner un fichier

de VHDX .vhdx à taille fixe attaché à une machine virtuelle. Pour plus d’informations,
voir Vue d’ensemble du redimensionnement de disque dur virtuel en ligne.
Fibre Channel virtuel Avec cette fonctionnalité, les machines virtuelles peuvent reconnaître un
périphérique de canal fibre et le monter en mode natif. Pour plus
d’informations, voir Vue d’ensemble de Fibre Channel virtuel Hyper-V.
Sauvegarde Cette fonctionnalité facilite la sauvegarde sans temps d’arrêt des machines
dynamique de virtuelles actives.
machine virtuelle Notez que l’opération de sauvegarde ne réussit pas si la machine virtuelle
possède des disques durs virtuels (VHD) hébergés sur un stockage distant,
tel qu’un partage SMB (Server Message Block) ou un volume iSCSI. En
outre, vérifiez que la cible de sauvegarde ne réside pas sur le même
volume que le volume que vous sauvegardez.
Prise en charge de Les indicateurs TRIM informent le lecteur que certains secteurs
TRIM précédemment alloués ne sont plus requis par l’application et peuvent être
vidés. Ce processus est généralement utilisé lorsqu’une application
effectue des allocations d’espace volumineuses via un fichier, puis gère
automatiquement les allocations au fichier, par exemple, aux fichiers de
disque dur virtuel.
WWN SCSI Le pilote storvsc extrait les informations WWN (World Wide Name) du port
et du nœud des appareils attachés à la machine virtuelle et crée les fichiers
sysfs appropriés.
Mémoire
Prise en charge du La technologie PAE (Physical Address Extension) permet à un noyau 32 bits
noyau PAE d’accéder à un espace d’adressage physique supérieur à 4 Go. Les
anciennes distributions Linux, telles que RHEL 5.x, utilisaient un noyau
distinct qui était activé pour la PAE. Les distributions plus récentes, telles
que RHEL 6.x, prennent en charge l’environnement PAE prédéfini.
Configuration de Avec cette fonctionnalité, les fabricants d’appliances peuvent configurer

l’écart MMIO l’emplacement de l’espace d’E/S mappées en mémoire (MMIO). L’écart
MMIO est généralement utilisé pour diviser la mémoire physique
disponible entre les systèmes d’exploitation JeOS (Just Enough Operating
Systems) d’une appliance et l’infrastructure logicielle réelle qui alimente
l’appliance.
Mémoire L’hôte peut augmenter ou diminuer de manière dynamique la quantité de

dynamique - Ajout à mémoire disponible pour une machine virtuelle pendant son
chaud fonctionnement. Avant l’approvisionnement, l’administrateur active la
mémoire dynamique dans le panneau Paramètres de la machine virtuelle
et spécifie la mémoire de démarrage, la mémoire minimale et la mémoire
maximale pour la machine virtuelle. Lorsque la machine virtuelle est en
cours d’opération, la mémoire dynamique ne peut pas être désactivée et
seuls les paramètres Minimum et Maximum peuvent être modifiés. (Il est
recommandé de spécifier ces tailles de mémoire sous forme de multiples
de 128 Mo.)
Lorsque la machine virtuelle est démarrée pour la première fois, la
mémoire disponible est égale à la Mémoire de démarrage. À mesure que
la demande de mémoire augmente en raison des charges de travail
d’application, Hyper-V peut allouer de manière dynamique plus de
mémoire à la machine virtuelle via le mécanisme de Hot-Add, s’il est pris
en charge par cette version du noyau. La quantité maximale de mémoire
allouée est limitée par la valeur du paramètre Mémoire maximale.
L’onglet Mémoire du gestionnaire Hyper-V affiche la quantité de mémoire

affectée à la machine virtuelle, mais les statistiques de mémoire au sein de
la machine virtuelle affichent la plus grande quantité de mémoire allouée.
Pour plus d’informations, consultez Vue d’ensemble de la mémoire

dynamique Hyper-V.
Mémoire L’hôte peut augmenter ou diminuer de manière dynamique la quantité de

dynamique - mémoire disponible pour une machine virtuelle pendant son
Ballooning fonctionnement. Avant l’approvisionnement, l’administrateur active la
mémoire dynamique dans le panneau Paramètres de la machine virtuelle
et spécifie la mémoire de démarrage, la mémoire minimale et la mémoire
maximale pour la machine virtuelle. Lorsque la machine virtuelle est en
cours d’opération, la mémoire dynamique ne peut pas être désactivée et
seuls les paramètres Minimum et Maximum peuvent être modifiés. (Il est
recommandé de spécifier ces tailles de mémoire sous forme de multiples
de 128 Mo.)
Lorsque la machine virtuelle est démarrée pour la première fois, la
mémoire disponible est égale à la Mémoire de démarrage. À mesure que
la demande de mémoire augmente en raison des charges de travail
d’application, Hyper-V peut allouer de manière dynamique plus de
mémoire à la machine virtuelle via le mécanisme de Hot-Add (voir ci-
dessus). À mesure que la demande de mémoire diminue, Hyper-V peut
automatiquement déprovisionner la mémoire de la machine virtuelle via le
mécanisme Balloon. Hyper-V ne déprovisionne pas la mémoire en dessous
du paramètre Mémoire minimale.
L’onglet Mémoire du gestionnaire Hyper-V affiche la quantité de mémoire

affectée à la machine virtuelle, mais les statistiques de mémoire au sein de
la machine virtuelle affichent la plus grande quantité de mémoire allouée.
Pour plus d’informations, consultez Vue d’ensemble de la mémoire

dynamique Hyper-V.
Redimensionnement Un administrateur peut définir la quantité de mémoire disponible sur une

de la mémoire de machine virtuelle pendant son fonctionnement, soit en augmentant la
runtime mémoire (« Ajout à chaud ») soit en la réduisant (« Suppression à chaud »).
La mémoire est retournée à Hyper-V via le pilote de bulle (consultez «
Mémoire dynamique - Création de bulle »). Le pilote de bulle conserve une
quantité minimale de mémoire libre après la création de bulle, appelée «
plancher », de sorte que la mémoire affectée ne peut pas être réduite en
dessous de la demande actuelle plus ce plancher. L’onglet Mémoire du
gestionnaire Hyper-V affiche la quantité de mémoire affectée à la machine
virtuelle, mais les statistiques de mémoire au sein de la machine virtuelle
affichent la plus grande quantité de mémoire allouée. (Il est recommandé
de spécifier ces tailles de mémoire sous forme de multiples de 128 Mo.)
Vidéo
Appareil vidéo Cette fonctionnalité fournit des graphiques hautes performances et une
spécifique à résolution supérieure pour les machines virtuelles. Cet appareil ne fournit pas de
Hyper-V fonctionnalités de mode de session amélioré ou RemoteFX.
Divers
Échange KVP Cette fonctionnalité fournit un service d’échange clé/valeur (KVP) pour les
(paire clé- machines virtuelles. En règle générale, les administrateurs utilisent le mécanisme
valeur) KVP pour effectuer des opérations de lecture et d’écriture de données
personnalisées sur une machine virtuelle. Pour plus d’informations sur KVP,
consultez Échange de données : utilisation de paires clé/valeur pour partager
des informations entre l’hôte et l’invité sur Hyper-V.
Interruption Avec cette fonctionnalité, un administrateur peut émettre des interruptions non
non masquables (NMI) sur une machine virtuelle. Les MN sont utiles pour obtenir des
masquable vidages sur incident des systèmes d’exploitation qui ne répondent plus en raison
de bogues d’application. Ces images mémoire après incident peuvent être
diagnostiquées après le redémarrage.
Copie de Cette fonctionnalité permet de copier des fichiers de l’ordinateur physique hôte
fichiers de vers les machines virtuelles invitées sans utiliser la carte réseau. Pour plus
l’hôte vers d’informations, voir Services invités.
l’invité
Commande Cette commande obtient des informations sur les appareils du bus de machines
lsvmbus virtuelles Hyper-V (VMBus) similaires aux commandes d’informations telles que
lspci.
Sockets Il s’agit d’un canal de communication supplémentaire entre le système

Hyper-V d’exploitation hôte et le système d’exploitation invité. Pour charger et utiliser le
module noyau des sockets Hyper-V, consultez Créer vos propres services
d’intégration.
Pass-through Avec Windows Server 2016, les administrateurs peuvent passer par des
PCI/DDA périphériques PCI Express via le mécanisme d’attribution d’appareil discrète. Les
appareils courants sont les cartes réseau, les cartes graphiques et les
périphériques de stockage spéciaux. La machine virtuelle nécessite le pilote
approprié pour utiliser le matériel exposé. Le matériel doit être affecté à la
machine virtuelle pour pouvoir être utilisé.
Pour plus d’informations, consultez Affectation d’appareil discrète - Description
et arrière-plan .
DDA est un prérequis pour la mise en réseau SR-IOV. Les ports virtuels doivent
être affectés à la machine virtuelle et celle-ci doit utiliser les pilotes VF (Virtual
Function) appropriés pour le multiplexage d’appareils.

Démarrage en Cette fonctionnalité permet aux machines virtuelles de démarrer à l’aide de

mode UEFI l’interface UEFI (Unified Extensible Firmware Interface).
Pour plus d’informations, voir Vue d’ensemble d’un ordinateur virtuel de
génération 2.
Démarrage Cette fonctionnalité permet aux machines virtuelles d’utiliser le mode de

sécurisé démarrage sécurisé basé sur UEFI. Lorsqu’une machine virtuelle est démarrée en
mode sécurisé, différents composants du système d’exploitation sont vérifiés à
l’aide de signatures présentes dans le magasin de données UEFI.
Pour plus d'informations, voir Démarrage sécurisé.
Voir aussi
V

Meilleures pratiques pour l’exécution de
Linux sur Hyper-V
Article • 14/04/2023
Server 2008 R2, Windows 10 , Windows 8.1, Windows 8, Windows 7.1, Windows 7
Cette rubrique contient une liste de recommandations pour l’exécution d’un ordinateur
virtuel Linux sur Hyper-V.
Paramétrage des systèmes de fichiers Linux sur

des fichiers VHDX dynamiques
Certains systèmes de fichiers Linux peuvent consommer des quantités importantes
d’espace disque réel, même lorsque le système de fichiers est principalement vide. Pour
réduire la quantité d’espace disque réel utilisé par les fichiers VHDX dynamiques, tenez
compte des recommandations suivantes :
Lors de la création du VHDX, utilisez une valeur BlockSizeBytes de 1 Mo (plutôt

que les 32 Mo par défaut) dans PowerShell, par exemple :
Powershell
PS > New-VHD -Path C:\MyVHDs\test.vhdx -SizeBytes 127GB -Dynamic -

BlockSizeBytes 1MB
Le format ext4 est préférable à ext3, car ext4 est plus efficace en terme d’espace
qu’ext3 en cas d’utilisation avec des fichiers VHDX dynamiques.
Lors de la création du système de fichiers, spécifiez 4096 comme nombre de

groupes, par exemple :
Bash
# mkfs.ext4 -G 4096 /dev/sdX1

Délai d’expiration du menu de Grub sur les
ordinateurs virtuels de génération 2
En raison de la suppression du matériel hérité de l’émulation dans les ordinateurs
virtuels de génération 2, le compte à rebours du menu de Grub est trop rapide pour que
le menu de Grub soit affiché, chargeant immédiatement l’entrée par défaut. Jusqu’à ce
que Grub soit corrigé de façon à utiliser le minuteur pris en charge par EFI, modifiez
/boot/grub/grub.conf, /etc/default/grub, ou équivalent de façon à avoir
« timeout=100000 » au lieu de la valeur par défaut « timeout=5 ».
Démarrage PxE sur les ordinateurs virtuels de

génération 2
Étant donné que le minuteur PIT n’est pas présent dans les ordinateurs virtuels de
génération 2, les connexions réseau au serveur TFTP PxE peuvent être interrompues
prématurément, et empêcher le chargeur de démarrage de lire la configuration Grub et
de charger un noyau à partir du serveur.
Sur RHEL 6.x, le chargeur de démarrage EFI v0.97 hérité Grub peut être utilisé au lieu de
grub2, comme décrit ici :
https://access.redhat.com/documentation/Red_Hat_Enterprise_Linux/6/html/Installation_
Guide/s1-netboot-pxe-config-efi.html
Sur les distributions Linux autres que RHEL 6.x, des étapes similaires peuvent être suivies
pour configurer Grub v0.97 afin de charger des noyaux Linux à partir d’un serveur PxE.
En outre, sur RHEL/CentOS 6.6, l’entrée clavier et souris ne fonctionnera pas avec le
noyau préinstallé, ce qui empêche de spécifier des options d’installation dans le menu.
Une console série doit être configurée pour permettre le choix des options d’installation.
Dans le fichier efidefault sur le serveur PxE, ajoutez le paramètre de noyau suivant
« console=ttyS1 »
Sur l’ordinateur virtuel dans Hyper-V, configurez un port COM à l’aide de cette
applet de commande PowerShell :
Powershell
Set-VMComPort -VMName <Name> -Number 2 -Path \\.\pipe\dbg1

La spécification d’un fichier kickstart sur le noyau préinstallé éviterait également de
devoir recourir à l’entrée clavier et souris lors de l’installation.
Utiliser des adresses MAC statiques avec le

clustering de basculement
Les ordinateurs virtuels Linux qui seront déployés à l’aide du clustering de basculement
doivent être configurées avec une adresse MAC (Media Access Control) statique pour
chaque carte réseau virtuelle. Dans certaines versions de Linux, la configuration réseau
peut être perdue après le basculement, car une nouvelle adresse MAC est affectée à la
carte réseau virtuelle. Pour éviter de perdre la configuration réseau, assurez-vous que
chaque carte réseau virtuelle a une adresse MAC statique. Vous pouvez configurer
l’adresse MAC en modifiant les paramètres de l’ordinateur virtuel dans le Gestionnaire
Hyper-V ou le Gestionnaire du cluster de basculement.
Utiliser des cartes réseau propres à Hyper-V, et

non la carte réseau héritée
Configurez et utilisez l’adaptateur Ethernet virtuel, qui est une carte réseau propre à
Hyper-V avec des performances améliorées. Si des cartes réseau héritées et propres à
Hyper-V sont attachées à un ordinateur virtuel, les noms de réseau dans la sortie de
ifconfig -a peuvent afficher des valeurs aléatoires telles que _tmp12000801310. Pour
éviter ce problème, supprimez toutes les cartes réseau héritées lors de l’utilisation de
cartes réseau propres à Hyper-V dans un ordinateur virtuel Linux.
Utiliser le planificateur d’E/S noop/none pour

de meilleures performances d’E/S disque
Le noyau Linux offre deux ensembles de planificateurs d’E/S de disque pour réorganiser
les requêtes. L’un des ensembles concerne l’ancien sous-système « blk », et l’autre le
sous-système « blk-mq » plus récent. Dans les deux cas, avec les disques SSD
d’aujourd’hui, il est recommandé d’utiliser un planificateur qui transmet les décisions de
planification à l’hyperviseur Hyper-V sous-jacent. Pour les noyaux Linux qui utilisent le
sous-système « blk », il s’agit du planificateur « noop ». Pour les noyaux Linux qui
utilisent le sous-système « blk-mq », il s’agit du planificateur « none ».
Pour un disque particulier, les planificateurs disponibles sont visibles à l’emplacement

du système de fichiers suivant : /sys/class/block/ <diskname> /queue/scheduler, avec le
planificateur actuellement sélectionné entre crochets. Vous pouvez modifier le
planificateur en écrivant dans cet emplacement du système de fichiers. La modification
doit être ajoutée à un script d’initialisation afin de persister entre les redémarrages. Pour
plus d’informations, consultez la documentation de la distribution Linux.
NUMA
Les versions du noyau Linux antérieures à la version 2.6.37 ne prennent pas en charge
NUMA sur Hyper-V avec des machines virtuelles de taille supérieure. Ce problème
concerne principalement les distributions antérieures utilisant le noyau Red Hat 2.6.32
en amont ; il a été corrigé dans Red Hat Enterprise Linux (RHEL) 6.6 (kernel-2.6.32-504).
Pour les systèmes exécutant des noyaux personnalisés dont la version est antérieure à la
version 2.6.37 ou des noyaux basés sur RHEL antérieurs à la version 2.6.32-504, le
paramètre de démarrage numa=off doit être défini sur la ligne de commande du noyau
dans grub.conf. Pour plus d’informations, consultez l’article KB 436883 sur Red Hat.
Réserver davantage de mémoire pour kdump

Si le noyau de capture de vidage se retrouve avec une panique au démarrage, réservez
davantage de mémoire pour le noyau. Par exemple, remplacez le paramètre
crashkernel=384M-:128M par crashkernel=384M-:256M dans le fichier de
configuration Grub Ubuntu.
La réduction de VHDX ou l’extension des

fichiers VHD et VHDX peuvent entraîner la
présence de tables de partition GPT erronées
Hyper-V permet de réduire les fichiers de disque virtuel (VHDX) sans tenir compte des
structures de données de partition, de volume ou de système de fichiers qui peuvent
exister sur le disque. Si le VHDX est réduit à l’emplacement où la fin du VHDX arrive
avant la fin d’une partition, des données peuvent être perdues, cette partition peut être
endommagée ou des données non valides peuvent être retournées lorsque la partition
est lue.
Après le redimensionnement d’un VHD ou d’un VHDX, les administrateurs doivent

utiliser un utilitaire comme fdisk ou parted pour mettre à jour les structures de la
partition, du volume et du système de fichiers afin de refléter la modification de la taille
du disque. La réduction ou l’augmentation de la taille d’un VHD ou d’un VHDX doté
d’une table de partition GUID (GPT) entraîne l’affichage d’un avertissement lorsqu’un
outil de gestion de partition est utilisé pour vérifier la disposition de la partition, et
l’administrateur est informé qu’il doit corriger les en-têtes GPT premier et secondaire.
Cette étape manuelle peut être effectuée sans perte de données.
Ordinateurs virtuels Linux et FreeBSD pris en charge pour Hyper-V sur Windows
Déployer un cluster Hyper-V
Créer des images Linux pour Azure
Optimiser votre machine virtuelle Linux sur Azure

Bonnes pratiques pour l’exécution de
FreeBSD sur Hyper-V
Article • 11/04/2023
Server 2008 R2, Windows 10, Windows 8.1, Windows 8, Windows 7.1, Windows 7
Cette rubrique contient une liste de recommandations pour l’exécution de FreeBSD en

tant que système d’exploitation invité sur une machine virtuelle Hyper-V.
Activer CARP dans FreeBSD 10.2 sur Hyper-V

Le protocole CARP (Protocole commun de redondance des adresses) permet à plusieurs
hôtes de partager la même adresse IP et le même ID d’hôte virtuel (VHID) pour fournir
une haute disponibilité pour un ou plusieurs services. Si un ou plusieurs hôtes échouent,
les autres hôtes prennent le relais de manière transparente afin que les utilisateurs ne
remarquent pas d’échec du service. Pour utiliser CARP dans FreeBSD 10.2, suivez les
instructions du manuel FreeBSD et procédez comme suit dans le Gestionnaire Hyper-
V.
Vérifiez que la machine virtuelle dispose d’une carte réseau et qu’un commutateur
virtuel lui est attribué. Sélectionnez la machine virtuelle, puis sélectionnez
Paramètres >des actions.
Activer l’usurpation des adresses MAC. Pour ce faire, effectuez la procédure
suivante :
1. Sélectionnez la machine virtuelle, puis sélectionnez Paramètres >des actions.
2. Développez Carte réseau et sélectionnez Fonctionnalités avancées.
3. Sélectionnez Activer l’usurpation d’adresse MAC.
Créer des étiquettes pour les périphériques de

disque
Au démarrage, les nœuds d’appareil sont créés à mesure que de nouveaux appareils
sont découverts. Cela signifie que les noms des appareils peuvent changer lors de l’ajout
de nouveaux appareils. Si vous obtenez une erreur de montage racine (ROOT MOUNT
ERROR) au démarrage, vous devez créer des étiquettes pour chaque partition IDE afin
d’éviter les conflits et les modifications. Pour savoir comment procéder, consultez
Étiquetage des périphériques de disque . Vous trouverez ci-dessous des exemples.
） Important
Faites une copie de sauvegarde de votre fstab avant d’apporter les modifications.
1. Redémarrez le système en mode mono-utilisateur. Pour ce faire, sélectionnez

l’option 2 du menu de démarrage pour FreeBSD 10.3+ (option 4 pour FreeBSD 8.x)
ou effectuez un « boot -s » à partir de l’invite de démarrage.
2. En mode mono-utilisateur, créez des étiquettes GEOM pour chacune des partitions
de disque IDE répertoriées dans votre fstab (racine et échange). Voici un exemple
de FreeBSD 10.3.
Bash
# cat /etc/fstab
# Device Mountpoint FStype Options Dump Pass#
/dev/da0p2 / ufs rw 1 1
/dev/da0p3 none swap sw 0 0
# glabel label rootfs /dev/da0p2

# glabel label swap /dev/da0p3
# exit
Pour plus d’informations sur les étiquettes GEOM, consultez : Étiquetage des
périphériques de disque .
3. Le système continuera avec le démarrage multi-utilisateur. Une fois le démarrage

terminé, modifiez /etc/fstab et remplacez les noms d’appareils conventionnels par
leurs étiquettes respectives. /etc/fstab final se présente comme suit :
# Device Mountpoint FStype Options Dump

Pass#
/dev/label/rootfs / ufs rw 1
1
/dev/label/swap none swap sw 0
0
4. Le système peut maintenant être redémarré. Si tout s’est bien passé, il se présente
normalement et le montage affiche :
# mount
/dev/label/rootfs on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, mutilabel)
Utilisez une carte réseau sans fil comme

commutateur virtuel
Si le commutateur virtuel sur l’hôte est basé sur la carte réseau sans fil, réduisez le
temps d’expiration ARP à 60 secondes par la commande suivante. Sinon, la mise en
réseau de la machine virtuelle peut cesser de fonctionner après un certain temps.
# sysctl net.link.ether.inet.max_age=60
Voir aussi

Compatibilité des fonctionnalités Hyper-
V par génération et invité
Article • 14/04/2023
Les tableaux de cet article indiquent les générations et les systèmes d’exploitation
compatibles avec certaines des fonctionnalités Hyper-V, regroupés par catégories. En
général, vous obtiendrez la meilleure disponibilité des fonctionnalités avec un
ordinateur virtuel de génération 2 qui exécute le système d’exploitation le plus récent.
N’oubliez pas que certaines fonctionnalités s’appuient sur du matériel ou une autre
infrastructure. Pour plus d’informations sur le matériel, consultez Configuration système
pour Hyper-V sur Windows Server 2016. Dans certains cas, une fonctionnalité peut être
utilisée avec n’importe quel système d’exploitation invité pris en charge. Pour plus
d’informations sur les systèmes d’exploitation pris en charge, consultez :
Ordinateurs virtuels Linux et FreeBSD pris en charge

Systèmes d’exploitation invités Windows pris en charge
Disponibilité et sauvegarde
Fonctionnalité Generation Système d’exploitation invité
Points de 1 et 2 Tout invité pris en charge

contrôle
Clustering 1 et 2 Invités qui exécutent des applications prenant en charge le

invité cluster et sur lesquels un logiciel cible iSCSI est installé
Réplication 1 et 2 Tout invité pris en charge
Contrôleur de 1 et 2 Tout invité Windows Server pris en charge utilisant uniquement

domaine des points de contrôle de production. Consultez Systèmes
d’exploitation invités Windows Server pris en charge
Calcul
Mémoire 1 et 2 Versions spécifiques des invités pris en charge. Consultez Vue

dynamique d’ensemble de la mémoire dynamique Hyper-V pour les
versions antérieures à Windows Server 2016 et Windows 10.
Ajout/suppression 1 et 2 Windows Server 2016, Windows 10

de mémoire à
chaud
NUMA virtuel 1 et 2 Tout invité pris en charge
Développement et test
Fonctionnalité Generation Système
d’exploitation
invité
Ports 1 et 2 Tout invité pris

COM/série Remarque : Pour la génération 2, utilisez Windows PowerShell en charge
pour configurer. Pour plus d’informations, consultez Ajouter
un port COM pour le débogage du noyau.
Mobilité
Migration dynamique 1 et 2 Tout invité pris en charge
Importation/Exportation 1 et 2 Tout invité pris en charge
Mise en réseau
Ajout/suppression à chaud de 2 Tout invité pris en charge

carte réseau virtuelle
Carte réseau virtuelle héritée 1 Tout invité pris en charge
SR-IOV (Single-Root Input-Output 1 et 2 Invités Windows 64 bits, à partir de Windows

Virtualization) Server 2012 et Windows 8.
VMMQ (Virtual Machine Multi- 1 et 2 Tout invité pris en charge

Queue)
Expérience de connexion à distance
Attribution 1 et 2 Windows Server 2016, Windows Server 2012 R2 uniquement

discrète de avec Mise à jour 3133690 installée, Windows 10
périphérique Remarque : Pour plus d’informations sur la Mise à jour 3133690,
(DDA) consultez cet article de support.
Mode de 1 et 2 Windows Server 2016, Windows Server 2012 R2, Windows 10 et

session Windows 8.1, avec les services Bureau à distance activés
amélioré Remarque : Vous devrez peut-être également configurer l’hôte.
Pour plus de détails, consultez Utiliser des ressources locales sur
un ordinateur virtuel Hyper-V avec VMConnect.
RemoteFx 1 et 2 Génération 1 sur les versions Windows 32 bits et 64 bits à partir

de Windows 8.
Génération 2 sur les versions Windows 10 64 bits
Sécurité
Démarrage 2 Linux : Ubuntu 14.04 et versions ultérieures, SUSE Linux

sécurisé Enterprise Server 12 et versions ultérieures, Red Hat
Enterprise Linux 7.0 et versions ultérieures et CentOS 7.0 et
versions ultérieures
Windows : toutes les versions prises en charge pouvant
s’exécuter sur un ordinateur virtuel de génération 2
Machines virtuelles 2 Windows : toutes les versions prises en charge pouvant

dotées d’une s’exécuter sur un ordinateur virtuel de génération 2
protection
maximale
Stockage
Disques durs virtuels partagés 1 et 2 Windows Server 2016, Windows Server 2012
(VHDX uniquement) R2, Windows Server 2012
SMB3 1 et 2 Tout ce qui prend en charge SMB3
Espaces de stockage direct 2 Windows Server 2016

Fibre Channel virtuel 1 et 2 Windows Server 2016, Windows Server 2012

R2, Windows Server 2012
Format VHDX 1 et 2 Tout invité pris en charge

Prise en main d’Hyper-V sur
Windows Server
Article • 17/04/2023

Utilisez les ressources suivantes pour configurer et essayer Hyper-V sur l’option
d’installation Minimale ou GUI de Windows Server 2019 ou Windows Server 2016. Mais
avant d’installer quoi que ce soit, vérifiez la Configuration requise pour Windows Server
et la Configuration requise pour Hyper-V.
Télécharger et installer Windows Server
Installer le rôle Hyper-V sur Windows Server
Créer un commutateur virtuel pour les ordinateurs virtuels Hyper-V
Créer une machine virtuelle avec Hyper-V

Installer le rôle Hyper-V sur Windows
Server
Article • 22/09/2023
Pour créer et exécuter des machines virtuelles, installez le rôle Hyper-V sur Windows
Server à l’aide de Gestionnaire de serveur ou de l’applet de commande Install-
WindowsFeature dans Windows PowerShell. Pour Windows 10, consultez Installer
Hyper-V sur Windows 10.
Pour en savoir plus sur Hyper-V, consultez Vue d’ensemble de la technologie Hyper-V.
Pour essayer Windows Server 2019, vous pouvez télécharger et installer une copie
d’évaluation. Consultez le Centre d’évaluation .
Avant d’installer Windows Server ou d’ajouter le rôle Hyper-V, vérifiez que :
Le matériel de votre ordinateur est compatible. Pour plus d’informations, consultez

Configuration système requise pour Windows Server et Configuration requise pour
Hyper-V sur Windows Server.
Vous ne prévoyez pas d’utiliser des applications de virtualisation tierces qui

s’appuient sur les mêmes fonctionnalités de processeur que celles requises par
Hyper-V. Les exemples incluent VMWare Workstation et VirtualBox. Vous pouvez
installer Hyper-V sans désinstaller ces autres applications. Toutefois, si vous
essayez de les utiliser pour gérer des machines virtuelles lorsque l’hyperviseur
Hyper-V est en cours d’exécution, il se peut que les machines virtuelles ne
démarrent pas ou qu’elles ne s’exécutent pas de manière fiable. Pour plus
d’informations et d’instructions sur la désactivation de l’hyperviseur Hyper-V si
vous avez besoin d’utiliser l’une de ces applications, consultez Les applications de
virtualisation ne fonctionnent pas avec Hyper-V, Device Guard et Credential
Guard .
Si vous souhaitez installer uniquement les outils de gestion, tels que le Gestionnaire
Hyper-V, consultez Gérer à distance les hôtes Hyper-V avec le Gestionnaire Hyper-V.
Installez Hyper-V à l’aide de Gestionnaire de

serveur
1. Dans le Gestionnaire de serveur, dans le menu Gérer, cliquez sur Ajouter des rôles
et fonctionnalités.
2. Dans la page Avant de commencer, vérifiez que votre serveur de destination et

environnement réseau sont préparés pour le rôle et la fonctionnalité que vous
voulez installer. Cliquez sur Suivant.
3. Sur la page Sélectionner le type d’installation, sélectionnez Installation basée sur

un rôle ou une fonctionnalité, puis Suivant.
4. Dans la page Sélectionner le serveur de destination, sélectionnez un serveur dans

le pool de serveurs, puis sélectionnez Suivant.
5. Dans la page Sélectionner des rôles de serveurs, sélectionnez Hyper-V. Dans la

page Ajouter des rôles et de fonctionnalités , sélectionnez Ajouter des
fonctionnalités, puis sélectionnez Suivant.
6. Dans la page Sélectionner des fonctionnalités, sélectionnez Suivant, puis

sélectionnez Suivant à nouveau.
7. Dans la page Créer des commutateurs virtuels, la page Migration de machine

virtuelle et la page Magasins par défaut, sélectionnez les options qui
correspondent à votre environnement spécifique.
8. Dans la page Confirmer les sélections d’installation, sélectionnez Redémarrer

automatiquement le serveur de destination si nécessaire puis cliquez sur
Installer.
9. Une fois l’installation terminée, vérifiez qu’Hyper-V est correctement installé.

Ouvrez la page Tous les serveurs dans Gestionnaire de serveur et sélectionnez un
serveur sur lequel vous avez installé Hyper-V. Vérifiez la mosaïque Rôles et
fonctionnalités sur la page du serveur sélectionné.
Installez Hyper-V à l’aide de l’applet de

commande Install-WindowsFeature
1. Sur le bureau de Windows, sélectionnez le bouton Démarrer et tapez une partie du
nom Windows PowerShell.
2. Faites un clic droit sur Windows PowerShell, puis sélectionnez Exécuter en tant
qu’administrateur.
3. Pour installer Hyper-V sur un serveur auquel vous êtes connecté à distance,
exécutez la commande suivante et remplacez par <computer_name> le nom du
serveur.
PowerShell
Install-WindowsFeature -Name Hyper-V -ComputerName <computer_name> -

IncludeManagementTools -Restart
Si vous êtes connecté localement au serveur, exécutez la commande sans -

ComputerName <computer_name> .
4. Une fois le serveur redémarré, vous pouvez voir que le rôle Hyper-V est installé et
voir quels autres rôles et fonctionnalités sont installés en exécutant la commande
suivante :
PowerShell
Get-WindowsFeature -ComputerName <computer_name>
Si vous êtes connecté localement au serveur, exécutez la commande sans -

ComputerName <computer_name> .
７ Notes
Si vous installez ce rôle sur un serveur qui exécute l’option d’installation Server
Core de Windows Server 2016 et que vous utilisez le paramètre -
IncludeManagementTools , seul le module Hyper-V pour Windows PowerShell est
installé. Vous pouvez utiliser l’outil de gestion de l’interface utilisateur graphique,

gestionnaire Hyper-V, sur un autre ordinateur pour gérer à distance un hôte Hyper-
V qui s’exécute sur une installation Server Core. Pour obtenir des instructions sur la
connexion à distance, consultez Gérer à distance les hôtes Hyper-V avec le
Gestionnaire Hyper-V.
Install-WindowsFeature
Créer et configurer un commutateur
virtuel avec Hyper-V
Article • 17/04/2023
S’applique à : Windows Server 2022, Windows 10, Windows Server 2016, Microsoft
Hyper-V Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019
Cet article vous explique comment créer et configurer votre commutateur virtuel à l’aide
du Gestionnaire Hyper-V ou de PowerShell. Un commutateur virtuel permet aux
machines virtuelles créées sur des hôtes Hyper-V de communiquer avec d’autres
ordinateurs. Lorsque vous installez le rôle Hyper-V pour la première fois sur
Windows Server, vous pouvez créer simultanément un commutateur virtuel si vous le
souhaitez. Pour plus d’informations sur les commutateurs virtuels, consultez
Commutateur virtuel Hyper-V.
Pour plus d’informations sur la configuration de votre infrastructure réseau avec

Windows Server, consultez la documentation relative à la mise en réseau.
Prérequis
Avant de pouvoir créer et configurer votre commutateur virtuel, votre ordinateur doit
remplir les conditions préalables suivantes :
Le rôle de serveur Hyper-V doit être installé.

Déterminez le type de commutateur virtuel que vous devez créer.
Identifiez le réseau auquel vous allez connecter votre ordinateur. Pour plus
d’informations, consultez l’article Planification d’un réseau de base.
Vous devez disposer de droits d'administration.
Créer un commutateur virtuel

Une fois les conditions préalables remplies, vous êtes prêt à créer votre commutateur
virtuel. Dans cette section, nous allons créer un commutateur virtuel de base en suivant
cette procédure.
Voici comment créer un commutateur virtuel à l’aide du Gestionnaire Hyper-V.

1. Ouvrez le Gestionnaire Hyper-V.
2. Dans le volet Actions, sélectionnez Gestionnaire de commutateur virtuel.
3. Choisissez le type de commutateur virtuel, puis sélectionnez Créer un

commutateur virtuel.
4. Entrez un nom pour le commutateur virtuel, puis effectuez l’une des étapes
suivantes.
a. Si vous avez sélectionné externe, choisissez la carte réseau que vous

souhaitez utiliser, puis sélectionnez OK.
Un avertissement s’affichera, indiquant que la modification peut perturber

votre connectivité réseau. Sélectionnez Oui si vous souhaitez continuer.
b. Si vous avez sélectionné interne ou privé, sélectionnez OK.
Partage du système d’exploitation de gestion

Un commutateur virtuel externe permet à vos machines virtuelles de se connecter à un
réseau externe. Vous pouvez aussi autoriser le système d’exploitation de gestion à
partager la même carte réseau sélectionnée. Pour commencer, suivez ces étapes.
Voici comment autoriser le système d’exploitation de gestion à partager le

commutateur de carte réseau sélectionné à l’aide du Gestionnaire Hyper-V.
3. Sélectionnez le commutateur virtuel que vous souhaitez configurer, cochez la

case Autoriser le système d’exploitation de gestion à partager cette carte
réseau, puis sélectionnez OK.

Identification de réseau local virtuel

Vous pouvez spécifier le numéro d’identification du réseau local virtuel utilisé par les
cartes réseau et les commutateurs virtuels des machines virtuelles. Pour les
commutateurs virtuels connectés à un réseau externe ou interne, vous pouvez spécifier
le numéro d’identification (réseau local virtuel). Le numéro d’identification de réseau
local virtuel est utilisé par le système d’exploitation de gestion et les machines virtuelles
qui communiquent via ce commutateur virtuel.
Vous pouvez également configurer votre commutateur virtuel avec d’autres options de
réseau local virtuel, telles que le mode de port et le numéro d’identification de réseau
local virtuel natif. Pour ces options, vous devrez utiliser PowerShell et vous assurer que la
configuration est compatible avec la configuration de vos réseaux.
Pour configurer l’identification de réseau local virtuel pour le commutateur, procédez

comme suit.
Voici comment spécifier le numéro d’identification de réseau local virtuel à l’aide du

3. Sélectionnez le commutateur virtuel que vous souhaitez configurer. Cochez

l’option Activer l’identification de réseau local virtuel pour le système
d’exploitation de gestion.
a. Vous pouvez entrer n’importe quel numéro d’identification de réseau local

virtuel ou conserver la valeur par défaut, puis sélectionner OK.

Les identificateurs de réseau local virtuel doivent être cohérents avec votre réseau
pour garantir la compatibilité entre votre ordinateur, vos machines virtuelles et
d’autres périphériques réseau.
Étape suivante
Maintenant que vous avez créé et configuré votre commutateur virtuel, voici d’autres
articles qui vous aideront à continuer à utiliser Hyper-V.
En savoir plus sur Switch Embedded Teaming (SET).
Apprenez à créer une machine virtuelle dans Hyper-V.
Découvrez les autres options de configuration dans les articles de référence de
PowerShell Set-VMSwitch et de Set-VMNetworkAdapterVlan.
Créer une machine virtuelle avec Hyper-
V
Article • 14/04/2023

Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019, Windows 11,
Windows 10
Découvrez comment créer une machine virtuelle en utilisant le Gestionnaire Hyper-V et

Windows PowerShell, et les options dont vous disposez quand vous créez une machine
virtuelle dans le Gestionnaire Hyper-V.
Création d'une machine virtuelle

2. Dans le volet Actions, cliquez sur Nouveau, puis sur Machine virtuelle.
3. Dans l’Assistant Nouvel ordinateur virtuel, cliquez sur Suivant.
4. Effectuez les choix appropriés pour votre machine virtuelle sur chacune des
pages. Pour plus d’informations, consultez Options des nouvelles machines
virtuelles et valeurs par défaut dans le Gestionnaire Hyper-V.
5. Après avoir vérifié vos choix dans la page Résumé, cliquez sur Terminer.
6. Dans le Gestionnaire Hyper-V, cliquez avec le bouton droit sur la machine

virtuelle, puis sélectionnez Se connecter.
7. Dans la fenêtre Connexion à un ordinateur virtuel, sélectionnez

Action>Démarrer.
Options de l’Assistant Nouvel ordinateur virtuel

du Gestionnaire Hyper-V
Le tableau suivant liste les options que vous pouvez choisir quand vous créez une
machine virtuelle dans le Gestionnaire Hyper-V ainsi que les valeurs par défaut pour
chacune d’elles.
Page Valeur par défaut pour Windows Autres options

Server 2016, Windows 10 et ultérieur
Spécifier le Nom : nouvelle machine virtuelle. Vous pouvez aussi entrer votre
nom et Emplacement : propre nom et choisir un autre
l’emplacement C:\ProgramData\Microsoft\Windows\Hyper- emplacement pour la machine
V\. virtuelle.
C’est là que les fichiers de
configuration de la machine
virtuelle seront stockés.
Spécifier la Génération 1 Vous pouvez aussi choisir de

génération créer une machine virtuelle de
génération 2. Pour plus
d’informations, consultez Dois-
je créer une machine virtuelle
de génération 1 ou 2 dans
Hyper-V ?.
Affecter la Mémoire de démarrage : 1 024 Mo Vous pouvez définir la mémoire

mémoire Mémoire dynamique : non sélectionné de démarrage de 32 Mo à
5 902 Mo.
Vous pouvez aussi choisir
d’utiliser la mémoire
dynamique. Pour plus
d’informations, consultez Vue
d’ensemble de la mémoire
dynamique Hyper-V.
Configurer la Non connecté Vous pouvez sélectionner une

mise en connexion réseau pour la
réseau machine virtuelle à utiliser dans
une liste de commutateurs
virtuels existants. Consultez
Créer un commutateur virtuel
pour les machines virtuelles
Hyper-V.
Connecter un Créer un disque dur virtuel Vous pouvez aussi choisir

disque dur Nom : <nom_machine_virtuelle>.vhdx d’utiliser un disque dur virtuel
virtuel existant, ou bien attendre et
Emplacement : attacher un disque dur virtuel
C:\Users\Public\Documents\Hyper-V\Virtual ultérieurement.
Hard Disks\
Taille : 127 Go
Page Valeur par défaut pour Windows Autres options
Server 2016, Windows 10 et ultérieur
Options Installer un système d’exploitation Ces options changent l’ordre de

d’installation ultérieurement démarrage de la machine
virtuelle pour vous permettre
d’installer à partir d’un fichier
.iso, d’une disquette
démarrable ou d’un service
d’installation réseau, comme
Services de déploiement
Windows (WDS).
Résumé Affiche les options que vous avez choisies Astuce : Vous pouvez copier le
pour vous permettre de vérifier qu’elles sont résumé de la page et le coller
correctes. dans un e-mail ou ailleurs pour
- Nom faciliter le suivi de vos machines
- Génération virtuelles.
- Mémoire
- Réseau
- Disque dur
- Système d’exploitation
New-VM
Versions de la configuration de la machine virtuelle prise en charge
Dois-je créer une machine virtuelle de génération 1 ou 2 dans Hyper-V ?
Créer un commutateur virtuel pour les ordinateurs virtuels Hyper-V

Planifier Hyper-V sur Windows Server
Article • 14/04/2023
Utilisez ces ressources pour vous aider à planifier votre déploiement Hyper-V.
Scalabilité d'Hyper-V dans Windows Server

Sécurité d’Hyper-V dans Windows Server
Réseaux dans Windows Server
Dois-je créer un ordinateur virtuel de génération 1 ou 2 ?
Planifier l’accélération GPU dans Windows Server
Planifier le déploiement d’appareils à l’aide de la technologie Discrete Device
Assignment
Capacité de prise en charge des
applications et systèmes d’exploitation
invités
Article • 09/03/2023
Hyper-V est un hyperviseur largement utilisé dans de nombreux produits serveur

Microsoft, notamment la famille Windows Server (éditions Datacenter, Standard et
Essentials) et Azure Stack HCI. Hyper-V fournit une plateforme avec une prise en charge
et une compatibilité larges de l’écosystème. Cet article précise les versions de Windows
Server ou Azure Stack HCI associées aux numéros de build Hyper-V. Il vous permet de
comprendre les scénarios pris en charge où une application ou un système
d’exploitation invité ont été validés pour Hyper-V.
Bien que les différents produits qui incluent Hyper-V puissent contenir des variantes
dans leurs fonctionnalités, le codebase commun fournit une plateforme cohérente aux
systèmes d’exploitation invités et aux applications exécutés à l’intérieur d’une machine
virtuelle pour qu’ils s’exécutent sur des produits compatibles qui partagent le même
numéro de build Hyper-V. Cela signifie que toutes les instructions de prise en charge ou
de compatibilité d’un système d’exploitation invité ou d’une application certifiés pour
des builds spécifiques d’Hyper-V sont compatibles avec tous les produits qui partagent
le même numéro de build pour Hyper-V.
Le tableau ci-dessous indique quels numéros de build Hyper-V sont disponibles dans
quels produits compatibles :
Build Hyper-V Produits compatibles
20348 Windows Server 2022 Datacenter

Windows Server 2022 Standard
Windows Server 2022 Essentials
Azure Stack HCI version 21H2
17763 et 17784 Windows Server 2019 Datacenter

Serveur Hyper-V 2019
Build Hyper-V Produits compatibles
14393 Windows Server 2016 Datacenter

Hyper-V Server 2016
Pour plus d'informations, consultez les pages suivantes :
Informations de publication de Windows Server

Systèmes d’exploitation invités Windows pris en charge sur Hyper-V
Systèmes d’exploitation invités Linux et FreeBSD pris en charge sur Hyper-V
Dois-je créer une machine virtuelle de
génération 1 ou 2 dans Hyper-V ?
Article • 09/03/2023
S’applique à : Windows 10, Windows 11, Windows Server 2016, Microsoft Hyper-V
Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019, Windows
Server 2022 et Azure Stack HCI
７ Notes
Si vous envisagez de charger des machines virtuelles Windows à partir d’un site
local vers Microsoft Azure, les machines virtuelles de génération 1 et 2 sont prises
en charge tant qu’elles utilisent le format de fichier VHD et qu’elles possèdent un
disque de taille fixe (sans augmentation dynamique). Consultez Machines virtuelles
de génération 2 sur Azure pour en savoir plus sur les fonctionnalités de
génération 2 prises en charge sur Azure. Pour plus d’informations sur le
chargement d’un VHD ou d’un VHDX Windows, consultez Préparer un VHD ou un
VHDX Windows à charger sur Azure.
Votre choix de créer une machine virtuelle de génération 1 ou 2 dépend du système

d’exploitation invité que vous souhaitez installer et de la méthode de démarrage que
vous souhaitez utiliser pour déployer la machine virtuelle. Nous vous recommandons de
créer une machine virtuelle de génération 2 pour tirer parti de fonctionnalités telles que
le démarrage sécurisé, sauf si l’un des énoncés suivants est vrai :
Vous utilisez un disque virtuel préconstruit (VHD ou VHDX) qui n’est pas
compatible avec UEFI.
La génération 2 ne prend pas en charge le système d’exploitation que vous
souhaitez exécuter sur la machine virtuelle.
La génération 2 ne prend pas en charge la méthode de démarrage que vous
souhaitez utiliser.
Pour plus d’informations sur les fonctionnalités disponibles avec les machines virtuelles
de génération 2, consultez Compatibilité des fonctionnalités Hyper-V par génération et
par invité.
Vous ne pouvez pas modifier la génération d’une machine virtuelle une fois que vous
l’avez créée. Par conséquent, nous vous recommandons de passer en revue les
considérations présentées ici, ainsi que de choisir le système d’exploitation, la méthode
de démarrage et les fonctionnalités que vous souhaitez utiliser avant de choisir une
génération.
Quels sont les systèmes d’exploitation pris en

charge ?
Les machines virtuelles de génération 1 prennent en charge la plupart des systèmes
d’exploitation invités. Les machines virtuelles de génération 2 prennent en charge la
plupart des versions 64 bits de Windows, ainsi que des versions plus actuelles des
systèmes d’exploitation Linux et FreeBSD. Aidez-vous des sections suivantes pour voir
quelle génération de machine virtuelle prend en charge le système d’exploitation invité
que vous souhaitez installer.
Systèmes d’exploitation invités CentOS et Red Hat Enterprise Linux pris en charge
Systèmes d’exploitation invités Debian pris en charge
Systèmes d’exploitation invités FreeBSD pris en charge
Systèmes d’exploitation invités Oracle Linux pris en charge
Systèmes d’exploitation invités SUSE pris en charge
Systèmes d’exploitation invités Ubuntu pris en charge

Le tableau suivant indique les versions 64 bits de Windows que vous pouvez utiliser
comme systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.
Versions 64 bits de Windows Génération 1 Génération 2
Windows Server 2022 ✔ ✔
Windows Server 2012 R2 ✔ ✔
Windows Server 2008 R2 ✔ ✖

Windows Server 2008 ✔ ✖
Windows 11 ✖ ✔
Windows 10 ✔ ✔
Windows 8.1 ✔ ✔
Windows 8 ✔ ✔
Windows 7 ✔ ✖
Le tableau suivant indique les versions 32 bits de Windows que vous pouvez utiliser
comme systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.
Windows 10 ✔ ✖
Windows 8.1 ✔ ✖
Windows 8 ✔ ✖
Windows 7 ✔ ✖
Systèmes d’exploitation invités CentOS et Red Hat

Enterprise Linux pris en charge
Le tableau suivant indique les versions de Red Hat Enterprise Linux (RHEL) et de CentOS
que vous pouvez utiliser comme systèmes d’exploitation invités pour les machines
virtuelles de génération 1 et 2.
Versions du système Génération Génération 2

d’exploitation 1
Série 8.x de ✔ ✔
RHEL/CentOS
RHEL/CentOS
RHEL/CentOS Note : prise en charge uniquement sur Windows Server
2016 et versions ultérieures.
Versions du système Génération Génération 2
d’exploitation 1
Série 5.x de ✔ ✖
RHEL/CentOS
Pour plus d’informations, consultez Machines virtuelles CentOS et Red Hat Enterprise
Linux sur Hyper-V.
Systèmes d’exploitation invités Debian pris en charge

Le tableau suivant indique les versions de Debian que vous pouvez utiliser comme
systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.
Versions du système d’exploitation Génération 1 Génération 2
Série 10.x de Debian (buster) ✔ ✔
Série 9.x de Debian (stretch) ✔ ✔
Série 8.x de Debian (jessie) ✔ ✔
Série 7.x de Debian (wheezy) ✔ ✖
Pour plus d’informations, consultez Machines virtuelles Debian sur Hyper-V.
Systèmes d’exploitation invités FreeBSD pris en charge

Le tableau suivant indique les versions de FreeBSD que vous pouvez utiliser comme
FreeBSD 12 à 12.1 ✔ ✔
FreeBSD 11.1 à 11.3 ✔ ✔
FreeBSD 11 ✔ ✖
FreeBSD 10 à 10.3 ✔ ✖
FreeBSD 9.1 à 9.3 ✔ ✖
FreeBSD 8.4 ✔ ✖
Pour plus d’informations, voir Machines virtuelles FreeBSD sur Hyper-V.

Systèmes d’exploitation invités Oracle Linux pris en
charge
Le tableau suivant indique les versions des séries de noyaux compatibles Red Hat que
vous pouvez utiliser comme systèmes d’exploitation invités pour les machines virtuelles
de génération 1 et 2.
Versions des séries de noyaux compatibles Red Hat Génération 1 Génération 2
Série 8.x d’Oracle Linux ✔ ✔
Série 7.x d’Oracle Linux ✔ ✔
Série 6.x d’Oracle Linux ✔ ✖
Le tableau suivant indique les versions d’Unbreakable Enterprise Kernel que vous
pouvez utiliser comme systèmes d’exploitation invités pour les machines virtuelles de
génération 1 et 2.
Versions d’Unbreakable Enterprise Kernel (UEK) Génération 1 Génération 2
Oracle Linux UEK R3 QU3 ✔ ✖
Pour plus d’informations, voir Machines virtuelles Oracle Linux sur Hyper-V.
Systèmes d’exploitation invités SUSE pris en charge

Le tableau suivant indique les versions de SUSE que vous pouvez utiliser comme
Série 15 de SUSE Linux Enterprise Server ✔ ✔
Série 12 de SUSE Linux Enterprise Server ✔ ✔
Série 11 de SUSE Linux Enterprise Server ✔ ✖
Open SUSE 12.3 ✔ ✖
Pour plus d’informations, voir Machines virtuelles SUSE sur Hyper-V.

Systèmes d’exploitation invités Ubuntu pris en charge
Le tableau suivant indique les versions d’Ubuntu que vous pouvez utiliser comme
Ubuntu 20.04 ✔ ✔
Ubuntu 18.04 ✔ ✔
Ubuntu 16.04 ✔ ✔
Ubuntu 14.04 ✔ ✔
Ubuntu 12.04 ✔ ✖
Pour plus d’informations, voir Machines virtuelles Ubuntu sur Hyper-V.
Comment démarrer la machine virtuelle ?

Le tableau suivant indique les méthodes de démarrage prises en charge par les
machines virtuelles de génération 1 et 2.
Méthode de démarrage Génération Génération

1 2
démarrage PXE avec une carte réseau standard ; ✖ ✔
Démarrage PXE avec une carte réseau héritée ✔ ✖
Démarrage à partir d’un disque dur virtuel SCSI (.VHDX) ou d’un DVD ✖ ✔
virtuel (.ISO)
Démarrage à partir du disque dur virtuel du contrôleur IDE (.VHD), ✔ ✖

d’un DVD virtuel (.ISO) ou d’un lecteur CD/DVD physique
Démarrage à partir d’une disquette virtuelle (.VFD) ✔ ✖
Quels sont les avantages offerts par l’utilisation

d’une machine virtuelle de génération 2 ?
Voici quelques-uns des avantages offerts lors de l’utilisation d’une machine virtuelle de
génération 2 :
Démarrage sécurisé
Cette fonctionnalité vérifie que le chargeur de démarrage est signé par une
autorité de confiance dans la base de données UEFI afin d’empêcher l’exécution de
microprogrammes, systèmes d’exploitation ou pilotes UEFI non autorisés au
démarrage. Le démarrage sécurisé est activé par défaut pour les ordinateurs
virtuels de génération 2. Si vous devez exécuter un système d’exploitation invité
qui n’est pas pris en charge par le démarrage sécurisé, vous pouvez le désactiver
après la création de la machine virtuelle. Pour plus d'informations, voir Démarrage
sécurisé.
Pour activer le démarrage sécurisé sur les machines virtuelles Linux de

génération 2, vous devez choisir le modèle de démarrage sécurisé UEFI CA lorsque
vous créez la machine virtuelle.
Volume de démarrage plus important Le volume de démarrage maximal pour les

machines virtuelles de génération 2 est de 64 To. Il s’agit de la taille de disque
maximale prise en charge par un .VHDX. Pour les machines virtuelles de
génération 1, la taille maximale du volume de démarrage est de 2 To pour un
fichier .VHDX et de 2 040 Go pour un fichier .VHD. Pour plus d’informations, voir
Vue d’ensemble du format de disque dur virtuel d’Hyper-V.
Avec les machines virtuelles de génération 2, vous pouvez observer une légère
amélioration des durées d’installation et de démarrage.
Quelle est la différence en matière de prise en

charge des appareils ?
Le tableau suivant compare les appareils disponibles entre les machines virtuelles de
génération 1 et 2.
Périphérique de Remplacement Améliorations de génération 2

génération 1 de génération 2
Contrôleur IDE Contrôleur SCSI Démarrage à partir d’un fichier .VHDX (taille
virtuel maximale de 64 To et capacité de
redimensionnement en ligne)
CD-ROM IDE CD-ROM SCSI Prise en charge de 64 périphériques DVD SCSI par
virtuel contrôleur SCSI.
BIOS hérité Microprogramme Démarrage sécurisé

UEFI
Carte réseau héritée Carte réseau Démarrage réseau avec IPv4 et IPv6
synthétique
Périphérique de Remplacement Améliorations de génération 2
génération 1 de génération 2
Contrôleur de Aucune prise en N/A

disquettes et charge des
contrôleur DMA contrôleurs de
disquettes
Émetteur/récepteur UART facultatif Rapidité et fiabilité accrues

asynchrone universel pour le débogage
(UART) pour ports
COM
Contrôleur de clavier Entrée basée sur Utilisation moindre des ressources due à l'absence
i8042 le logiciel d'émulation. Réduit également la surface d'attaque
sur le système d'exploitation invité.
Clavier PS/2 Clavier logiciel Utilisation moindre des ressources due à l'absence
d'émulation. Réduit également la surface d'attaque
Souris PS/2 Souris logicielle Utilisation moindre des ressources due à l'absence
d'émulation. Réduit également la surface d'attaque
Vidéo S3 Vidéo basée sur le Utilisation moindre des ressources due à l'absence
logiciel d'émulation. Réduit également la surface d'attaque
Bus PCI Plus nécessaire N/A
Contrôleur Plus nécessaire N/A

d'interruptions
programmable (PIC)
Minuteur d'intervalle Plus nécessaire N/A

programmable (PIT)
Super périphérique Plus nécessaire N/A

d'E/S
Plus d’informations sur les machines virtuelles

de génération 2
Voici quelques conseils supplémentaires sur l’utilisation de machines virtuelles de
génération 2.
Joindre ou ajouter un lecteur DVD
Vous ne pouvez pas joindre un lecteur CD ou DVD physique à une machine
virtuelle de génération 2. Le lecteur de DVD virtuel sur les ordinateurs virtuels de
génération 2 ne prend en charge que les fichiers image ISO. Pour créer un fichier
image ISO d’un environnement Windows, vous pouvez utiliser l’outil en ligne de
commande OScdimg. Pour plus d’informations, voir Options de ligne de
commande Oscdimg.
Quand vous créez une machine virtuelle avec l’applet de commande Windows
PowerShell New-VM , la machine virtuelle de génération 2 n’a pas de lecteur DVD.
Vous pouvez ajouter un lecteur DVD pendant que la machine virtuelle est en cours
d’exécution.
Utiliser le microprogramme UEFI

Le démarrage sécurisé ou le microprogramme UEFI ne sont pas obligatoires sur
l’hôte physique Hyper-V. Hyper-V fournit un microprogramme virtuel aux
machines virtuelles, qui est indépendant de ce qui se trouve sur l’hôte Hyper-V.
Le microprogramme UEFI d’une machine virtuelle de génération 2 ne prend pas en
charge le mode d’installation pour le démarrage sécurisé.
Nous ne prenons pas en charge l’exécution d’un interpréteur de commandes UEFI
ni d’autres applications UEFI sur une machine virtuelle de génération 2. L'utilisation
d'un shell ou d'une application UEFI non-Microsoft est techniquement possible s'il
(ou elle) est compilé(e) directement à partir des sources. Si ces applications ne sont
pas correctement signées numériquement, vous devrez désactiver le démarrage
sécurisé pour la machine virtuelle.
Utiliser des fichiers VHDX

Vous pouvez redimensionner un fichier VHDX qui contient le volume de démarrage
d’une machine virtuelle de génération 2 pendant que la machine virtuelle est en
cours d’exécution.
Nous ne prenons pas en charge et ne vous recommandons pas de créer un seul
disque virtuel (fichier VHD ou VHDX) qui peut être démarré à la fois sur les
machines virtuelles de génération 1 et 2.
La génération de l’ordinateur virtuel est une propriété de l’ordinateur virtuel, et
non du disque dur virtuel. Il n’est donc pas possible de savoir si un fichier VHDX a
été créé par une machine virtuelle de génération 1 ou de génération 2.
Un fichier VHDX créé avec une machine virtuelle de génération 2 peut être joint au
contrôleur IDE ou SCSI d’une machine virtuelle de génération 1. Toutefois, s’il s’agit
d’un fichier VHDX démarrable, la machine virtuelle de génération 1 ne démarrera
pas.
Utiliser IPv6 au lieu d’IPv4

Lors du démarrage à partir du réseau avec PXE, les machines virtuelles de génération 2
utilisent IPv4 par défaut. Pour utiliser IPv6 à la place, exécutez l’applet de commande
Windows PowerShell Set-VMFirmware. Par exemple, la commande suivante définit IPv6
comme protocole par défaut pour une machine virtuelle nommée TestVM :
PowerShell
Set-VMFirmware -VMName 'TestVM' -IPProtocolPreference IPv6
Ajouter un port COM pour le débogage du

noyau
Les ports COM ne sont pas disponibles dans les machines virtuelles de génération 2 tant
que vous ne les avez pas ajoutés. Vous pouvez le faire avec Windows PowerShell ou
Windows Management Instrumentation (WMI). Ces étapes vous montrent comment
procéder avec Windows PowerShell.
Pour ajouter un port COM :
1. Désactivez le démarrage sécurisé. Le débogage du noyau n’est pas compatible

avec le démarrage sécurisé. Vérifiez que la machine virtuelle est dans un état
Désactivé, puis utilisez l’applet de commande Set-VMFirmware. Par exemple, la
commande suivante désactive le démarrage sécurisé sur la machine virtuelle
TestVM :
PowerShell
Set-VMFirmware -VMName 'TestVM' -EnableSecureBoot Off
2. Ajoutez un port COM. Servez-vous de l’applet de commande Set-VMComPort pour

cela. Par exemple, la commande suivante configure le premier port COM sur la
machine virtuelle, TestVM, pour se connecter au canal nommé TestPipe sur
l’ordinateur local :
PowerShell
Set-VMComPort -VMName 'TestVM' -Number 1 -Path '\\.\pipe\TestPipe'
７ Notes
Les ports COM configurés ne sont pas répertoriés dans les paramètres d’une
machine virtuelle dans le Gestionnaire Hyper-V.
Voir aussi
Machines virtuelles Linux et FreeBSD sur Hyper-V
Utiliser des ressources locales sur une machine virtuelle Hyper-V avec VMConnect
Planifier l’évolutivité d’Hyper-V dans Windows Server 2016
Planifier la mise en réseau Hyper-V dans
Windows Server
Article • 12/04/2023
S’applique à : Windows Server 2022, Microsoft Hyper-V Server 2016, Windows

Server 2016, Microsoft Hyper-V Server 2019, Windows Server 2019
Une compréhension de base de la mise en réseau dans Hyper-V vous aide à planifier la
mise en réseau pour les machines virtuelles. Cet article aborde également certaines
considérations relatives à la mise en réseau lors de l’utilisation de la migration
dynamique et lors de l’utilisation d’Hyper-V avec d’autres fonctionnalités et rôles de
serveur.
Principes de base de la mise en réseau Hyper-V

La mise en réseau de base dans Hyper-V est assez simple. Elle utilise deux parties : un
commutateur virtuel et une carte réseau virtuelle. Vous aurez besoin d’au moins un des
deux pour établir la mise en réseau d’une machine virtuelle. Le commutateur virtuel se
connecte à n’importe quel réseau Ethernet. La carte réseau virtuelle se connecte à un
port sur le commutateur virtuel, ce qui permet à une machine virtuelle d’utiliser un
réseau.
Le moyen le plus simple d’établir une mise en réseau de base consiste à créer un
commutateur virtuel lorsque vous installez Hyper-V. Ensuite, lorsque vous créez une
machine virtuelle, vous pouvez la connecter au commutateur. La connexion au
commutateur ajoute automatiquement une carte réseau virtuelle à la machine virtuelle.
Pour plus d’instructions, consultez Créer un commutateur virtuel pour les ordinateurs
virtuels Hyper-V.
Pour gérer différents types de réseaux, vous pouvez ajouter des commutateurs virtuels
et des cartes réseau virtuelles. Tous les commutateurs font partie de l’hôte Hyper-V,
mais chaque carte réseau virtuelle appartient à une seule machine virtuelle.
Un commutateur virtuel est un commutateur réseau Ethernet de couche 2 basé sur

logiciel. Il fournit des fonctionnalités intégrées pour la surveillance, le contrôle et le
segmentage du trafic, ainsi que la sécurité et les diagnostics. Vous pouvez ajouter à
l’ensemble de fonctionnalités intégrées en installant des plug-ins, également appelés
extensions. Ceux-ci sont disponibles à partir de fournisseurs de logiciels indépendants.
Pour plus d’informations sur le commutateur et les extensions, consultez Commutateur
virtuel Hyper-V.
Choix de commutateur et de carte réseau

Hyper-V offre trois types de commutateurs virtuels et deux types de cartes réseau
virtuelles. Vous choisirez le commutateur de chaque type souhaité lors de sa création.
Vous pouvez utiliser le Gestionnaire Hyper-V ou le module Hyper-V pour Windows
PowerShell afin de créer et de gérer des commutateurs virtuels et cartes réseau
virtuelles. Certaines fonctionnalités de mise en réseau avancées, telles que les listes de
contrôle d’accès aux ports étendus (ACL), ne peuvent être gérées qu’à l’aide d’applets de
commande dans le module Hyper-V.
Vous pouvez apporter des modifications à un commutateur virtuel ou une carte réseau
virtuelle une fois que vous l’avez créé. Par exemple, il est possible de remplacer un
commutateur existant par un autre type de commutateur, mais cela affecte les
fonctionnalités réseau de toutes les machines virtuelles connectée à ce commutateur.
Donc, vous ne le ferez probablement pas, sauf si vous avez fait une erreur ou avez
besoin de tester quelque chose. Par exemple, vous pouvez connecter une carte réseau
virtuelle à un autre commutateur, que vous pouvez faire si vous souhaitez vous
connecter à un autre réseau. Toutefois, vous ne pouvez pas changer une carte réseau
virtuelle d’un type à un autre. Au lieu de modifier le type, vous ajoutez une autre carte
réseau virtuelle et choisissez le type approprié.
Les types de commutateur virtuel sont les suivants :
Commutateur virtuel externe : se connecte à un réseau câblé physique par le biais

d’une liaison à une carte réseau physique.
Commutateur virtuel interne : se connecte à un réseau qui peut être utilisé

uniquement par les machines virtuelles s’exécutant sur l’hôte où se trouve le
commutateur virtuel, et entre l’hôte et les machines virtuelles.
Commutateur virtuel privé : se connecte à un réseau qui peut être utilisé

uniquement par les machines virtuelles s’exécutant sur l’hôte où se trouve le
commutateur virtuel, mais ne permet pas de mise en réseau entre l’hôte et les
machines virtuelles.
Options de commutateur virtuel :
Nom du Description
paramètre
Nom du Description
paramètre
Autoriser le Autorisez l’hôte Hyper-V à partager l’utilisation du commutateur virtuel et de

système l’équipe de carte réseau ou de carte réseau avec la machine virtuelle. Avec cette
d’exploitation option activée, l’hôte peut utiliser l’un des paramètres que vous configurez pour
de gestion à le commutateur virtuel, tels que les paramètres de qualité de service (QoS), les
partager paramètres de sécurité ou d’autres fonctionnalités du commutateur virtuel Hyper-
cette carte V.
réseau
Activer la Autorisez le trafic de machine virtuelle à contourner le commutateur de machine

virtualisation virtuelle et à accéder directement à la carte réseau physique. SR-IOV est
d’E/S d’une disponible uniquement pour les machines virtuelles exécutant Windows Server.
racine unique Pour plus d’informations, consultez Virtualisation d’E/S mono-racine dans la
(SR-IOV) Référence de l’affiche compagnon : mise en réseau Hyper-V.
Les types de cartes réseau virtuelles sont :
Carte réseau spécifique à Hyper-V : disponible pour les machines virtuelles de

génération 1 et 2. Il est conçu spécifiquement pour Hyper-V et nécessite un pilote
inclus dans les services d’intégration Hyper-V. Ce type de carte réseau est plus
rapide et est le choix recommandé, sauf si vous devez démarrer sur le réseau ou
exécuter un système d’exploitation invité non pris en charge. Le pilote requis est
fourni uniquement pour les systèmes d’exploitation invités pris en charge. Notez
que dans le Gestionnaire Hyper-V et les applets de commande réseau, ce type est
simplement appelé carte réseau.
Cartes réseau héritées : disponibles uniquement sur les ordinateurs virtuels de

génération 1. Émule une carte PCI Fast Ethernet basée sur Intel 21140 et peut être
utilisée pour démarrer sur un réseau afin de pouvoir installer un système
d’exploitation à partir d’un service tel que les services de déploiement Windows.
Mise en réseau Hyper-V et technologies

associées
Les versions récentes de Windows Server ont introduit des améliorations qui vous
offrent plus d’options pour configurer la mise en réseau pour Hyper-V. Par exemple,
Windows Server 2012 introduit la prise en charge de la mise en réseau convergée. Cela
vous permet de router le trafic réseau via un commutateur virtuel externe. Windows
Server 2016 s’appuie sur cela en autorisant l’accès en mémoire directe à distance
(RDMA) sur les cartes réseau liées à un commutateur virtuel Hyper-V. Vous pouvez
utiliser cette configuration avec ou sans Switch Embedded Teaming (SET). Pour plus
d’informations, consultez RDMA (Remote Direct Memory Access) et SET (Switch
Embedded Teaming)
Certaines fonctionnalités s’appuient sur des configurations réseau spécifiques ou

s’effectuent mieux sous certaines configurations. Tenez compte de ces éléments lors de
la planification ou de la mise à jour de votre infrastructure réseau.
Clustering de basculement : il est recommandé d’isoler le trafic du cluster et d’utiliser la

qualité de service (QoS) Hyper-V sur le commutateur virtuel. Pour plus d’informations,
consultez Recommandations de réseau pour un cluster Hyper-V
Migration dynamique : utilisez des options de performances pour réduire l’utilisation

du réseau et du processeur et le temps nécessaire pour effectuer une migration
dynamique. Pour plus d’instructions, consultez Configurer des hôtes une migration
dynamique sans clustering de basculement.
Espaces de stockage direct : cette fonctionnalité s’appuie sur le protocole réseau

SMB3.0 et RDMA. Pour plus d’informations, consultez Espaces de stockage direct dans
Windows Server 2016.
Planifier la scalabilité d’Hyper-V dans
Windows Server
Article • 14/04/2023
Cet article fournit des détails sur la configuration maximale pour les composants que
vous pouvez ajouter et supprimer sur un hôte Hyper-V ou ses ordinateurs virtuels, telles
que les processeurs virtuels ou les points de contrôle. Lors de la planification de votre
déploiement, vous devez prendre en compte les valeurs maximales qui s’appliquent à
chaque ordinateur virtuel, ainsi que celles qui s’appliquent à l’hôte Hyper-V. Les valeurs
maximales continuent d’augmenter dans les versions de Windows Server, en réponse
aux demandes de prise en charge de scénarios plus récents tels que le Machine
Learning et l’Analytique données.
７ Notes
Pour plus d'informations sur System Center Virtual Machine Manager (VMM), voir
Virtual Machine Manager. VMM est un produit Microsoft vendu séparément qui
est conçu pour gérer un centre de données virtualisé.
Valeurs maximales pour les ordinateurs virtuels

Ces valeurs maximales s’appliquent à chaque ordinateur virtuel. Tous les composants ne
sont pas disponibles dans les deux générations d’ordinateurs virtuels. Pour voir une
comparaison des générations, consultez Dois-je créer un ordinateur virtuel de
génération 1 ou 2 dans Hyper-V ?.
Composant Maximale Notes
Points de 50 Le nombre réel peut être inférieur, selon le stockage disponible.

contrôle Chaque point de contrôle est stocké sous la forme d’un fichier
.avhd qui utilise du stockage physique.
Mémoire 12 To pour la Vérifiez la configuration requise du système d’exploitation

génération 2 ; spécifique pour déterminer les capacités minimales et
1 To pour la recommandées.
génération 1
Ports série 2 Aucune.

(COM)
Taille des Variable La taille maximale est fonction du système d’exploitation invité.
disques
physiques
connectés
directement
à un
ordinateur
virtuel
Carte Fibre 4 En guise de meilleure pratique, nous vous recommandons de

Channel connecter chaque carte Fibre Channel virtuelle à un SAN virtuel
virtuelle différent.
Lecteurs de 1 lecteur de Aucune.

disquettes disquettes
virtuels virtuel
Capacité du 64 To pour le Chaque disque dur virtuel est stocké sur un média physique en
disque dur format VHDX ; tant que fichier .vhdx ou .vhd, selon le format utilisé par le disque
virtuel 2 040 Go pour dur virtuel.
le format VHD
Disques 4 Le disque de démarrage (parfois appelé disque d’amorçage) doit

virtuels IDE être connecté à l’un des périphériques IDE. Il peut s’agir d’un
disque dur virtuel ou d’un disque physique connecté directement
à un ordinateur virtuel.
Processeurs 240 pour la Le nombre de processeurs virtuels pris en charge par un système
virtuels génération 2 ; d’exploitation invité pourrait être inférieur. Pour plus
64 pour la d’informations, consultez les informations publiées pour le
génération 1 ; système d’exploitation spécifique. La limite de partition racine de
320 320 s’applique à Windows Server 2016 et 2019. À compter de
disponibles Windows Server 2022, la limite est augmentée à 1024.
pour le
système
d’exploitation
hôte (partition
racine)
Contrôleurs 4 L’utilisation de périphériques SCSI virtuels nécessite les services

SCSI d’intégration, qui sont disponibles pour les systèmes
virtuels d’exploitation invités pris en charge. Pour plus d’informations sur
les systèmes d’exploitation pris en charge, consultez Ordinateurs
virtuels Linux et FreeBSD pris en charge et Systèmes
d’exploitation invités Windows pris en charge.
Disques 256 Chaque contrôleur SCSI prend en charge jusqu’à 64 disques. En

SCSI d’autres termes, chaque ordinateur virtuel peut être configuré
virtuels avec un maximum de 256 disques SCSI virtuels (4 contrôleurs x
64 disques par contrôleur). (4 contrôleurs x 64 disques par
contrôleur).
Cartes Windows La carte réseau propre à Hyper-V offre de meilleures

réseau Server 2019 et performances et nécessite un pilote inclus dans les services
virtuel versions d’intégration. Pour plus d’informations, consultez Planifier les
ultérieures réseaux Hyper-V dans Windows Server.
prennent en
charge un total
de 68 :
64 cartes
réseau
propres
à Hyper-
V
4 cartes
réseau
héritées ;
Windows
Server 2016
prend en
charge un total
de 12 :
8 cartes
réseau
propres
à Hyper-
V
4 cartes
réseau
héritées
Valeurs maximales pour les hôtes Hyper-V

Ces valeurs maximales s’appliquent à chaque hôte Hyper-V.

Processeurs 512 Les deux éléments suivants doivent être activés dans
logiques le microprogramme :
Virtualisation assistée par le matériel
Prévention de l’exécution des données (DEP)
appliquée par matériel
Sur Windows Server 2016 et 2019, le système

d’exploitation hôte (partition racine) ne verra que 320
processeurs logiques maximum. À compter de
Windows Server 2022, le système d’exploitation hôte
(partition racine) verra un maximum de 1024
processeurs.
Mémoire 48 To (Windows Aucune.

Server 2022 et Azure
Stack HCI 21H2) ;
24 To (Windows
Server 2016 et 2019)
Association de Aucune limite imposée Aucune.

cartes réseau par Hyper-V.
Cartes réseau Aucune limite imposée Aucune.

physiques par Hyper-V.
Ordinateurs 1 024 Aucune.

virtuels en
cours
d'exécution
par serveur
Stockage Limité par la capacité Remarque : Microsoft prend en charge le stockage

prise en charge par le NAS (Network-Attached Storage) lors de l’utilisation
système d’exploitation de SMB 3.0. Le stockage NFS n'est pas pris en charge.
de gestion. Aucune
limite imposée par
Hyper-V.
Ports de Variable ; aucune limite La limite pratique varie en fonction des ressources
commutateurs imposée par Hyper-V. informatiques disponibles.
de réseau
virtuel par
serveur
Processeurs Aucun ratio imposé Aucune.

virtuels par par Hyper-V.
processeur
logique
Processeurs 2 048 Aucune.

virtuels par
serveur
Réseaux de Aucune limite imposée Aucune.

zone de par Hyper-V.
stockage
virtuels
Commutateurs Variable ; aucune limite La limite pratique varie en fonction des ressources
virtuels imposée par Hyper-V. informatiques disponibles.
Clusters de basculement et Hyper-V

Ce tableau liste les valeurs maximales qui s’appliquent lors de l’utilisation d’Hyper-V et
du clustering de basculement. Il est important de procéder à une planification de la
capacité afin de s’assurer qu’il y aura suffisamment de ressources matérielles pour
exécuter tous les ordinateurs virtuels dans un environnement en cluster.
Pour en savoir plus sur les mises à jour du clustering de basculement, notamment les
nouvelles fonctionnalités pour les ordinateurs virtuels, consultez Nouveautés du
clustering de basculement dans Windows Server 2016.
Nœuds par 64 Tenez compte des nœuds à réserver pour le basculement, ainsi que
cluster des tâches de maintenance telles que l’application de mises à jour.
Nous vous recommandons de planifier suffisamment de ressources
pour prévoir la réservation d’un nœud pour le basculement, ce qui
signifie qu’il reste inactif jusqu’à ce qu’un autre nœud y bascule. (Le
terme « nœud passif » est parfois employé.) Vous pouvez
augmenter ce nombre si vous souhaitez réserver des nœuds
supplémentaires. Il n’y a pas de rapport recommandé entre le
nombre de nœuds réservés et le nombre de nœuds actifs ; le seul
impératif est que le nombre total de nœuds dans un cluster ne
peut dépasser le nombre maximal de 64.
Ordinateurs 8 000 par Plusieurs facteurs peuvent avoir une incidence sur le nombre réel
virtuels cluster d’ordinateurs virtuels que vous pouvez exécuter en même temps
exécutés sur un nœud, tels que :
simultanément - Quantité de mémoire physique utilisée par chaque ordinateur
par nœud virtuel
- Bande passante du réseau et du stockage
- Nombre de piles de disques, qui a une incidence sur les
performances d’E/S des disques
Planifier la sécurité Hyper-V dans
Windows Server
Article • 14/04/2023

Sécurisez le système d’exploitation hôte Hyper-V, les ordinateurs virtuels, les fichiers de
configuration et les données des ordinateurs virtuels. Utilisez la liste suivante de
pratiques recommandées comme check-list pour vous aider à sécuriser votre
environnement Hyper-V.
Sécuriser l’hôte Hyper-V

Sécurisez le système d’exploitation hôte.
Réduisez la surface d’attaque en utilisant l’option d’installation minimale de
Windows Server dont vous avez besoin pour le système d’exploitation de
gestion. Pour plus d’informations, consultez la section Options d’installation de
la bibliothèque de contenu technique Windows Server. Nous vous déconseillons
d’exécuter des charges de travail de production sur Hyper-V sur Windows 10.
Maintenez le système d’exploitation hôte Hyper-V, le microprogramme et les
pilotes de périphérique à jour avec les dernières mises à jour de sécurité.
Consultez les recommandations de votre fournisseur pour mettre à jour le
microprogramme et les pilotes.
N’utilisez pas l’hôte Hyper-V comme station de travail et n’installez pas de
logiciels inutiles.
Gérez à distance l’hôte Hyper-V. Si vous devez gérer l’hôte Hyper-V localement,
utilisez Credential Guard. Pour plus d’informations, consultez la section Protéger
les informations d’identification de domaine dérivées avec Credential Guard.
Activez des stratégies d’intégrité du code. Utilisez les services d’intégrité du
code protégés par la sécurité basée sur la virtualisation. Pour plus
d’informations, consultez le Guide de déploiement de Device Guard.
Utilisez un réseau sécurisé.

Utilisez un réseau distinct avec une carte réseau dédiée pour l’ordinateur
physique Hyper-V.
Utilisez un réseau privé ou sécurisé pour accéder aux configurations
d’ordinateur virtuel et aux fichiers de disque dur virtuel.
Utilisez un réseau privé/dédié pour votre trafic de migration dynamique. Activez
IPSec sur ce réseau pour utiliser le chiffrement et sécuriser les données de votre
ordinateur virtuel qui transitent par le réseau pendant la migration. Pour plus
d’informations, consultez Configurer des hôtes pour la migration dynamique
sans clustering de basculement.
Sécurisez le trafic de migration du stockage.
Utilisez SMB 3.0 pour le chiffrement de bout en bout des données SMB et la
protection des données contre la falsification ou l’écoute clandestine sur les
réseaux non approuvés. Utilisez un réseau privé pour accéder au contenu du
partage SMB afin d’éviter les attaques de l’intercepteur. Pour plus d’informations,
consultez Améliorations de la sécurité SMB.
Configurez les hôtes afin qu’ils fassent partie d’une infrastructure protégée.
Pour plus d’informations, consultez Infrastructure protégée.
Sécurisez les périphériques.
Sécurisez les périphériques de stockage sur lesquels vous conservez les fichiers de
ressources d’ordinateurs virtuels.
Sécurisez le disque dur.
Utilisez le chiffrement de lecteur BitLocker pour protéger les ressources.
Durcissez le système d’exploitation hôte Hyper-V.
Utilisez les recommandations relatives aux paramètres de sécurité de base de

référence décrites dans la base de référence de la sécurité Windows Server.
Accordez les autorisations appropriées.

Ajoutez les utilisateurs qui doivent gérer l’hôte Hyper-V au groupe
Administrateurs Hyper-V.
N’accordez pas d’autorisations aux administrateurs d’ordinateurs virtuels sur le
système d’exploitation hôte Hyper-V.
Configurez des exclusions et des options antivirus pour Hyper-V.
Windows Defender a déjà des exclusions automatiques configurées. Pour plus

d’informations sur les exclusions, consultez Exclusions antivirus recommandées
pour les hôtes Hyper-V .
Ne montez pas de VHD inconnus. Cela peut exposer l’hôte à des attaques au
niveau du système de fichiers.
N’activez pas l’imbrication dans votre environnement de production, sauf si cela
est nécessaire.
Si vous activez l’imbrication, n’exécutez pas d’hyperviseurs non pris en charge sur
un ordinateur virtuel.
Pour des environnements plus sécurisés :
Utilisez du matériel avec une puce de module de plateforme sécurisée (TPM) 2.0
pour configurer une infrastructure protégée.
Pour plus d’informations, consultez Configuration système requise pour Hyper-V

sur Windows Server 2016.
Sécuriser les machines virtuelles

Créez des ordinateurs virtuels de génération 2 pour les systèmes d’exploitation
invités pris en charge.
Pour plus d’informations, consultez Paramètres de sécurité des ordinateurs virtuels

de génération 2.
Activez le démarrage sécurisé.

de génération 2.
Sécurisez le système d’exploitation invité.

Installez les dernières mises à jour de sécurité avant d’activer un ordinateur
virtuel dans un environnement de production.
Installez les services d’intégration pour les systèmes d’exploitation invités pris
en charge qui en ont besoin, et tenez-les à jour. Les mises à jour du service
d’intégration pour les invités qui exécutent des versions de Windows prises en
charge sont disponibles via Windows Update.
Durcissez le système d’exploitation qui s’exécute sur chaque ordinateur virtuel
en fonction du rôle qu’il assume. Utilisez les recommandations relatives aux
paramètres de sécurité de base de référence décrites dans la base de référence
de la sécurité Windows.
Utilisez un réseau sécurisé.
Assurez-vous que les cartes réseau virtuelles se connectent au commutateur virtuel

approprié, et que le paramètre de sécurité et les limites appropriés sont appliqués.
Stockez les disques durs virtuels et les fichiers d’instantanés dans un
emplacement sécurisé.
Sécurisez les périphériques.
Configurez uniquement les périphériques requis pour un ordinateur virtuel.

N’activez pas l’attribution discrète de périphériques dans votre environnement de
production, sauf si vous en avez besoin pour un scénario spécifique. Si vous
l’activez, veillez à exposer uniquement les périphériques de fournisseurs
approuvés.
Configurez les logiciels antivirus, de pare-feu et de détection des intrusions au

sein des ordinateurs virtuels en fonction du rôle de l’ordinateur virtuel.
Activez la sécurité basée sur la virtualisation pour les invités qui exécutent
Windows 10 ou Windows Server 2016 ou version ultérieure.
Pour plus d’informations, consultez le guide de déploiement de Device Guard.
Activez uniquement l’attribution discrète de périphériques si nécessaire pour

une charge de travail spécifique.
En raison de la nature du passage à travers un périphérique physique, collaborez

avec le fabricant du périphériques pour déterminer s’il doit être utilisé dans un
environnement sécurisé.
Pour des environnements plus sécurisés :
Déployez des ordinateurs virtuels avec la protection activée, et déployez-les sur

une infrastructure protégée.

de génération 2 et Infrastructure protégée.
Planifier l’accélération GPU dans
Windows Server
Article • 11/04/2023

Cet article présente les fonctionnalités de virtualisation graphique disponibles dans

Windows Server.
Quand utiliser l’accélération GPU

En fonction de votre charge de travail, vous pouvez envisager l’accélération GPU. Voici
ce que vous devez prendre en compte avant de choisir l’accélération GPU :
Charges de travail de communication à distance des applications et des bureaux

(VDI/DaaS) : si vous créez un service de communication à distance d’application
ou de bureau avec Windows Server, tenez compte du catalogue d’applications que
vos utilisateurs doivent exécuter. Certains types d’applications, comme les
applications de CAO/CAM, les simulations, les jeux et les applications de
rendu/visualisation, s’appuient fortement sur le rendu 3D pour offrir une
interactivité fluide et réactive. La plupart des clients considèrent que les GPU sont
nécessaires pour une expérience utilisateur raisonnable avec ces types
d’applications.
Charges de travail de rendu, d’encodage et de visualisation à distance : ces
charges de travail graphiques ont tendance à s’appuyer fortement sur les
fonctionnalités spécialisées d’un GPU, comme le rendu 3D efficace et
l’encodage/décodage des images, afin d’atteindre les objectifs de rentabilité et de
débit. Pour ce type de charge de travail, une seule machine virtuelle avec GPU peut
être en mesure de produire un débit équivalent à de nombreuses machines
virtuelles avec processeur uniquement.
Charges de travail HPC et ML : pour les charges de travail de calcul hautement
parallèles, comme l’apprentissage ou l’inférence de modèle Machine Learning et
de calcul hautes performances, les GPU peuvent réduire considérablement le
temps de production de résultats, d’inférence et d’entraînement. Ils peuvent
également offrir une meilleure rentabilité qu’une architecture à processeur
uniquement à un niveau de performances comparable. De nombreuses
infrastructures HPC et Machine Learning disposent d’une option permettant
d’activer l’accélération GPU ; déterminez si cela peut être bénéfique pour votre
charge de travail spécifique.
Virtualisation de GPU dans Windows Server

Les technologies de virtualisation de GPU activent l’accélération GPU dans un
environnement virtualisé, généralement au sein de machines virtuelles. Si votre charge
de travail est virtualisée avec Hyper-V, vous devez utiliser la virtualisation graphique afin
de fournir une accélération GPU, du GPU physique vers vos applications ou services
virtualisés. Toutefois, si votre charge de travail s’exécute directement sur des hôtes
Windows Server physiques, vous n’avez pas besoin de virtualisation graphique ; vos
applications et services ont déjà accès aux fonctionnalités et aux API de GPU prises en
charge en mode natif dans Windows Server.
Les technologies de virtualisation graphique suivantes sont disponibles pour les

machines virtuelles Hyper-V dans Windows Server :
Affectation discrète d’appareil (DDA)

RemoteFX vGPU
En plus des charges de travail de machine virtuelle, Windows Server prend en charge
l’accélération GPU des charges de travail conteneurisées dans des conteneurs Windows.
Pour plus d’informations, consultez Accélération GPU dans les conteneurs Windows.
Affectation discrète d’appareil (DDA)

Discrete Device Assignment (DDA), également connue sous le nom de transfert de GPU,
vous permet de dédier une ou plusieurs GPU physiques à une machine virtuelle. Dans
un déploiement DDA, les charges de travail virtualisées s’exécutent sur le pilote natif et
disposent généralement d’un accès complet aux fonctionnalités du GPU. DDA offre le
plus haut niveau de compatibilité des applications et de performances potentielles. DDA
peut également fournir une accélération GPU aux machines virtuelles Linux, sous réserve
de prise en charge.
Un déploiement DDA ne peut accélérer qu’un nombre limité de machines virtuelles, car
chaque GPU physique peut fournir une accélération à au plus une machine virtuelle. Si
vous développez un service dont l’architecture prend en charge les machines virtuelles
partagées, envisagez d’héberger plusieurs charges de travail accélérées par machine
virtuelle. Par exemple, si vous créez un service de communication de bureau à distance
avec RDS, vous pouvez améliorer la mise à l’échelle des utilisateurs en tirant parti des
fonctionnalités multisession de Windows Server pour héberger plusieurs bureaux
utilisateur sur chaque machine virtuelle. Ces utilisateurs partageront les avantages de
l’accélération GPU.
Pour plus d’informations, consultez les rubriques suivantes :
Planifier le déploiement Discrete Device Assignment

Déployer des appareils graphiques à l’aide de la technologie Discrete Device
Assignment
RemoteFX vGPU
７ Notes
Pour des raisons de sécurité, le vGPU RemoteFX est désactivé par défaut sur toutes
les versions de Windows à partir de la mise à jour de sécurité du 14 juillet 2020 et
supprimé à partir de la Mise à jour de sécurité du 13 avril 2021. Pour plus
d’informations, consultez l’article KB 4570006 .
RemoteFX vGPU est une technologie de virtualisation graphique qui permet de partager
un seul GPU physique entre plusieurs machines virtuelles. Dans un déploiement
RemoteFX vGPU, les charges de travail virtualisées s’exécutent sur l’adaptateur 3D
RemoteFX de Microsoft, qui coordonne les demandes de traitement GPU entre l’hôte et
les invités. RemoteFX vGPU convient le mieux aux charges de travail des travailleurs du
savoir et aux charges de travail à bursting élevé, où des ressources GPU dédiées ne sont
pas requises. RemoteFX vGPU peut uniquement fournir une accélération GPU aux
machines virtuelles Windows.
Pour plus d’informations, consultez les rubriques suivantes :
Déployer des périphériques graphiques avec vGPU RemoteFX

Prise en charge de la carte vidéo 3D RemoteFX (vGPU)
Comparaison de DDA et de RemoteFX vGPU

Tenez compte des différences de fonctionnalités et de prise en charge suivantes entre
les technologies de virtualisation graphique lors de la planification de votre
déploiement :
Description RemoteFX vGPU Attribution d’appareils en mode discret

Description RemoteFX vGPU Attribution d’appareils en mode discret
Modèle de Dédié ou partagé Dédié uniquement

ressource GPU
Densité de Élevée (un ou plusieurs GPU pour Faible (un ou plusieurs GPU sur une
machines de nombreuses machines machine virtuelle)
virtuelles virtuelles)
Compatibilité DX 11.1, OpenGL 4.4, OpenCL 1.1 Toutes les fonctionnalités GPU fournies
des applications par le fournisseur (DX 12, OpenGL, CUDA)
AVC444 Activée par défaut Disponible via les stratégies de groupe
VRAM de GPU Jusqu’à 1 Go de RAM vidéo Jusqu’à la quantité de RAM vidéo prise en
dédiée charge par le GPU
Fréquence Jusqu’à 30fps Jusqu’à 60fps

d’images
Pilote GPU dans Pilote d’affichage de carte 3D Pilote de fournisseur GPU (NVIDIA, AMD,
l’invité RemoteFX (Microsoft) Intel)
Prise en charge Windows Server 2016 Windows Server 2016 ; Windows

du système Server 2019
d’exploitation
hôte
Prise en charge Windows 2012 R2 ; Windows Windows Server 2012 R2 ; Windows

du système Server 2016 ; Windows 7 SP1 ; Server 2016 ; Windows Server 2019 ;
d’exploitation Windows 8.1 ; Windows 10 Windows 10 ; Linux
invité
Hyperviseur Microsoft Hyper-V. Microsoft Hyper-V.
Matériel GPU GPU Entreprise (comme Nvidia GPU Entreprise (comme Nvidia
Quadro/GRID ou AMD FirePro) Quadro/GRID ou AMD FirePro)
Matériel serveur Aucune exigence Serveur moderne, expose IOMMU au

système d’exploitation (généralement un
matériel compatible SR-IOV)
Planifier le déploiement de
périphériques à l’aide de l’attribution de
périphérique en mode discret
Article • 16/06/2023
S’applique à : Windows Server 2022, Microsoft Hyper-V Server 2019, Windows

Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016
L’attribution de périphérique en mode discret permet au matériel PCIe (Peripheral

Component Interconnect Express) physique d’être directement accessible depuis une
machine virtuelle. Cet article décrit les types de périphériques qui peuvent être utilisés,
la configuration requise du système hôte, les limitations imposées aux machines
virtuelles et les implications en matière de sécurité.
Pour Discrete Device Assignment, Microsoft prend en charge deux classes de

périphériques : les cartes graphiques et les périphériques de stockage NVMe. D’autres
périphériques sont susceptibles de fonctionner, et les fournisseurs de matériel peuvent
déclarer que ces périphériques sont compatibles. Pour les autres périphériques,
contactez les fournisseurs de matériel pour en savoir plus sur leur prise en charge.
Pour en savoir plus sur les autres méthodes de virtualisation GPU, consultez Planifier
l’accélération GPU dans Windows Server. Si vous êtes prêt à essayer l’attribution de
périphérique en mode discret, vous pouvez accéder à Déployer des périphériques
graphiques à l’aide de l’attribution de périphérique en mode discret ou Déployer des
périphériques de stockage NVMe à l’aide de l’attribution de périphérique en mode
discret.
Machines virtuelles et systèmes d’exploitation

invités pris en charge
L’affectation de périphérique discrète est prise en charge pour les machines virtuelles de
génération 1 ou 2. Les invités pris en charge sont les suivants :
Windows 10 ou version ultérieure

Windows Server 2016 ou version ultérieure
Windows Server 2012 R2 avec la mise à jour pour ajouter la prise en charge de
l’attribution de périphérique en mode discret pour Azure .
Pour plus d’informations, consultez Machines virtuelles Linux et FreeBSD prises en
charge pour Hyper-V sur Windows Server et Windows.
Configuration système requise

Votre système doit être conforme à la configuration matérielle requise pour Windows
Server et à la configuration système requise pour Hyper-V sur Windows Server.
L’attribution de périphérique en mode discret nécessite également du matériel de classe
serveur capable d’accorder au système d’exploitation le contrôle de la configuration de
l’infrastructure PCIe (Native PCI Express Control). Par ailleurs, le complexe racine PCIe
doit prendre en charge les services ACS (Access Control Services), qui permettent à
Hyper-V de forcer l’ensemble du trafic PCIe à transiter par l’unité de gestion de mémoire
d’entrée-sortie (IOMMU).
Ces fonctionnalités ne sont généralement pas exposées directement dans le BIOS du

serveur et sont souvent masquées derrière d’autres paramètres. Si les mêmes
fonctionnalités sont requises pour la prise en charge de SR-IOV et dans le BIOS, vous
devrez peut-être définir « Activer SR-IOV ». Contactez le fournisseur de votre système si
vous ne parvenez pas à identifier le paramètre approprié dans votre BIOS.
Pour vérifier que le matériel est compatible avec l’attribution de périphérique en mode
discret, vous pouvez exécuter le script de profil d’ordinateur sur un hôte avec Hyper-V.
Le script teste si votre serveur est correctement configuré et identifie les périphériques
prenant en charge Discrete Device Assignment.
Exigences relatives aux appareils

Tous les périphériques PCIe ne peuvent pas être utilisés avec l’affectation de
périphérique discrète. Les anciens périphériques qui utilisent des interruptions PCI (INTx)
héritées ne sont pas pris en charge. Pour plus d’informations, consultez Attribution de
périphérique en mode discret – Machines et périphériques . Vous pouvez également
exécuter le script de profil d’ordinateur pour afficher les périphériques pouvant être
utilisés avec Discrete Device Assignment.
Les fabricants de périphériques peuvent contacter leur représentant Microsoft pour

obtenir plus de détails.
Pilote de périphérique
L’attribution de périphérique en mode discret transmet l’intégralité du périphérique
PCIe à la machine virtuelle invitée. Il n’est pas nécessaire d’installer de pilote hôte avant
de monter le périphérique dans la machine virtuelle. La seule exigence sur l’hôte est que
le chemin d’accès d’emplacement PCIe du périphérique puisse être déterminé. Le pilote
du périphérique peut être installé pour faciliter l’identification du périphérique. Un GPU
dont le pilote de périphérique n’est pas installé sur l’hôte peut apparaître en tant que
périphérique Microsoft Basic Render Device. Si le pilote de périphérique est installé, son
fabricant et son modèle sont probablement affichés.
Lorsque le périphérique est monté dans l’invité, le pilote de périphérique du fabricant

peut être installé normalement dans la machine virtuelle invitée.
Limitations liées aux machines virtuelles

En raison de la nature de l’implémentation de l’attribution de périphérique en mode
discret, certaines fonctionnalités d’une machine virtuelle sont limitées lorsqu’un
périphérique y est attaché. Les fonctionnalités suivantes ne sont pas disponibles :
Enregistrer/restaurer des machines virtuelles

Migration dynamique d’une machine virtuelle
Utilisation de la mémoire dynamique
Ajout de la machine virtuelle à un cluster haute disponibilité
Sécurité
L’affectation de périphérique discrète transmet l’ensemble du périphérique à la machine
virtuelle. Cela signifie que toutes les fonctionnalités de ce périphérique sont accessibles
depuis le système d’exploitation invité. Certaines fonctionnalités, telles que la mise à
jour du microprogramme, peuvent nuire à la stabilité du système. De nombreux
avertissements sont présentés à l’administrateur lors du démontage du périphérique sur
l’hôte. Vous devez uniquement utiliser l’attribution de périphérique en mode discret
lorsque les locataires des machines virtuelles sont approuvés.
Si l’administrateur souhaite utiliser un périphérique avec un locataire non approuvé, le

fabricant du périphérique peut créer un pilote d’atténuation des risques qui peut être
installé sur l’hôte. Contactez le fabricant du périphérique pour savoir s’il propose un
pilote d’atténuation de périphérique.
Si vous souhaitez contourner les vérifications de sécurité d’un périphérique qui n’a pas
de pilote d’atténuation de périphérique, vous devez passer le paramètre -Force à
l’applet de commande Dismount-VMHostAssignableDevice . À cette occasion, vous avez
modifié le profil de sécurité de ce système. Vous ne devez apporter cette modification
que pendant la phase de prototypage ou dans des environnements approuvés.
Chemin d’emplacement PCIe
Le chemin d’emplacement PCIe est nécessaire pour démonter et monter le périphérique
sur l’hôte. Voici un exemple de chemin d’emplacement :
PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . Le script de profil de machine
retourne également le chemin d’emplacement du périphérique PCIe.
Obtenir le chemin d’emplacement à l’aide du Gestionnaire

de périphériques
1. Ouvrez Gestionnaire de périphériques et recherchez le périphérique.

2. Cliquez avec le bouton droit sur le périphérique, puis sélectionnez Propriétés.
3. Sous l’onglet Détails, développez le menu déroulant Propriété, puis sélectionnez
Chemins d’emplacement.
4. Cliquez avec le bouton droit sur l’entrée qui commence par PCIROOT et
sélectionnez Copier pour obtenir le chemin d’emplacement du périphérique.
Espace MMIO
Certains périphériques, en particulier les GPU, nécessitent que plus d’espace MMIO soit
alloué à la machine virtuelle pour que la mémoire de ce périphérique soit accessible. Par
défaut, chaque machine virtuelle démarre avec une allocation de 128 Mo d’espace
MMIO faible et de 512 Mo d’espace MMIO élevé. Cependant, un périphérique peut
nécessiter plus d’espace MMIO, ou plusieurs périphériques peuvent être transmis à la
fois, si bien que les besoins combinés dépassent ces valeurs. Il est facile de modifier
l’espace MMIO. Cette opération peut être effectuée dans PowerShell à l’aide des
commandes suivantes :
PowerShell
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm

Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm
Le moyen le plus simple de déterminer la quantité d’espace MMIO à allouer consiste à

utiliser le script de profil d’ordinateur. Pour télécharger et exécuter le script de profil de
machine, exécutez les commandes suivantes dans une console PowerShell :
PowerShell
curl -o SurveyDDA.ps1
https://raw.githubusercontent.com/MicrosoftDocs/Virtualization-
Documentation/live/hyperv-tools/DiscreteDeviceAssignment/SurveyDDA.ps1
.\SurveyDDA.ps1
Pour les périphériques qui peuvent être affectés, le script affiche les besoins MMIO d’un
périphérique donné. La sortie de script suivante est un exemple :
PowerShell
NVIDIA GRID K520

Express Endpoint -- more secure.
...
And it requires at least: 176 MB of MMIO gap space
...
L’espace MMIO faible est utilisé uniquement par les systèmes d’exploitation et les
périphériques 32 bits qui utilisent des adresses 32 bits. Dans la plupart des cas, la
définition de l’espace MMIO élevé d’une machine virtuelle suffit, car les configurations
32 bits ne sont pas courantes.
） Important
Lorsque vous affectez de l’espace MMIO à une machine virtuelle, veillez à spécifier
un espace MMIO suffisant. L’espace MMIO doit être la somme de l’espace MMIO
demandé pour tous les périphériques affectés en question, à laquelle s’ajoute un
tampon pour les périphériques virtuels qui ont besoin de quelques Mo d’espace
MMIO. Utilisez les valeurs MMIO par défaut décrites précédemment comme
mémoire tampon pour l’espace MMIO faible et l’espace MMIO élevé (128 Mo et
512 Mo, respectivement).
Reprenons l’exemple précédent. Si vous affectez un seul GPU K520, attribuez à l’espace
MMIO de la machine virtuelle la valeur générée par le script de profil de machine plus
un tampon, soit : 176 Mo + 512 Mo. Si vous affectez trois GPU K520, attribuez un espace
MMIO représentant trois fois la quantité de base de 176 Mo plus un tampon, soit :
528 Mo + 512 Mo.
Pour plus d’informations sur l’espace MMIO, consultez le billet Discrete Device
Assignment - GPUs sur le blog TechCommunity.
Script de profil de machine

Pour déterminer si le serveur est correctement configuré et identifier les périphériques
qui peuvent être transmis en utilisant l’attribution de périphérique en mode discret,
exécutez le script PowerShell SurveyDDA.ps1.
Avant d’utiliser le script, vérifiez que le rôle Hyper-V est installé et que vous exécutez le
script à partir d’une fenêtre de commande PowerShell disposant de privilèges
d’administrateur.
Si la configuration du système ne permet pas une prise en charge de l’attribution de

périphérique en mode discret, l’outil affiche un message d’erreur avec des détails sur le
problème. Si le système est mal configuré, l’outil énumère tous les périphériques situés
sur le bus PCIe.
Pour chaque périphérique trouvé, l’outil indique s’il peut être utilisé avec Discrete Device
Assignment. Si un périphérique est identifié comme étant compatible avec Discrete
Device Assignment, le script fournit une raison. Quand un périphérique est correctement
identifié comme étant compatible, le chemin d’emplacement du périphérique est
affiché. Si ce périphérique nécessite de l’espace MMIO, cela est également indiqué.
Qu’est-ce que la virtualisation
imbriquée ?
Article • 02/08/2023
La virtualisation imbriquée est une fonctionnalité qui vous permet d’exécuter Hyper-V à
l’intérieur d’une machine virtuelle Hyper-V. Au fil des ans, le matériel s’est amélioré et
les cas d’usage de la virtualisation imbriquée se sont étendus. Par exemple, la
virtualisation imbriquée peut être utile pour les opérations suivantes :
Exécution d’applications ou d’émulateurs dans une machine virtuelle imbriquée

Test des versions logicielles sur des machines virtuelles
Réduction des temps de déploiement des environnements de formation
Utilisation de l’isolation Hyper-V pour les conteneurs
Les processeurs modernes incluent des fonctionnalités matérielles qui rendent la

virtualisation plus rapide et plus sûre. Hyper-V s’appuie sur ces extensions de processeur
pour exécuter des machines virtuelles, par exemple, Intel VT-x et AMD-V. Grâce à la
virtualisation imbriquée, cette prise en charge matérielle est disponible pour les
machines virtuelles invitées.
Le diagramme ci-dessous illustre Hyper-V sans imbrication. L’hyperviseur Hyper-V prend

le contrôle total des fonctionnalités de virtualisation matérielle (flèche orange) et ne les
expose pas au système d’exploitation invité.
Par contre, le diagramme ci-dessous illustre Hyper-V avec la virtualisation imbriquée

activée. Dans ce cas, Hyper-V expose les extensions de virtualisation matérielle à ses
machines virtuelles. Quand l’imbrication est activée, une machine virtuelle invitée peut
installer son propre hyperviseur et exécuter ses propres machines virtuelles invitées.
Mémoire dynamique et redimensionnement de

la mémoire d’exécution
Hyper-V est en cours d’exécution dans une machine virtuelle, la machine virtuelle doit
être désactivée pour ajuster sa mémoire. Ainsi, même si la mémoire dynamique est
activée, la quantité de mémoire ne varie pas. La simple activation de la virtualisation
imbriquée n’a aucun effet sur la mémoire dynamique ou le redimensionnement de la
mémoire d’exécution.
Pour les machines virtuelles dont la mémoire dynamique n’est pas activée, toute
tentative d’ajustement de la quantité de mémoire en fonctionnement échoue.
L’incompatibilité se produit uniquement lorsque Hyper-V s’exécute dans la machine
virtuelle Hyper-V.
Applications de virtualisation tierces

Les applications de virtualisation autres que Hyper-V ne sont pas prises en charge sur
les machines virtuelles Hyper-V et sont susceptibles d’échouer. Les applications de
virtualisation incluent tous les logiciels qui nécessitent des extensions de virtualisation
matérielle.
Scénarios pris en charge
L’utilisation d’une machine virtuelle Hyper-V imbriquée en production est prise en
charge pour Azure et localement dans les scénarios suivants. Nous vous recommandons
également de vous assurer que vos services et applications sont aussi pris en charge.
La virtualisation imbriquée ne convient pas pour le clustering de basculement Windows

Server et les applications sensibles aux performances. Nous vous recommandons
d’évaluer entièrement les services et les applications.
Machines virtuelles Hyper-V sur des machines virtuelles

Hyper-V
L’exécution de machines virtuelles Hyper-V imbriquées sur des machines virtuelles
Hyper-V est idéale pour les laboratoires de test et les environnements d’évaluation, en
particulier dans les cas où les configurations peuvent être facilement modifiées et que
les états enregistrés peuvent être utilisés pour rétablir des configurations spécifiques.
Les laboratoires de test ne nécessitent généralement pas le même contrat de niveau de
service (SLA) que les environnements de production.
Les environnements de production exécutant des machines virtuelles Hyper-V exécutées

sur des machines virtuelles Hyper-V sont pris en charge. Nous vous recommandons
toutefois de vous assurer que vos services et applications sont aussi pris en charge. Si
vous utilisez une machine virtuelle Hyper-V imbriquée en production, il est recommandé
de bien déterminer si les services ou les applications fournissent le comportement
attendu.
Pour en savoir plus sur la configuration de la virtualisation imbriquée sur Azure,

consultez le billet de blog Tech Community Comment configurer la virtualisation
imbriquée pour une machine virtuelle/un disque dur virtuel Azure .
Virtualisation tierce sur une virtualisation Hyper-V

Bien qu’il soit possible d’exécuter une virtualisation tierce sur Hyper-V, Microsoft ne
teste pas ce scénario. La virtualisation tierce sur une virtualisation Hyper-V n’est pas
prise en charge. Vérifiez que votre fournisseur d’hyperviseur prend en charge ce
scénario.
Virtualisation Hyper-V sur une virtualisation tierce

Bien qu’il soit possible d’exécuter une virtualisation Hyper-V sur une virtualisation tierce,
Microsoft ne teste pas ce scénario. La virtualisation Hyper-V sur une virtualisation tierce
n’est pas prise en charge. Vérifiez que votre fournisseur d’hyperviseur prend en charge
ce scénario.
Azure Stack HCI imbriqué sur des machines virtuelles

Hyper-V
Azure Stack HCI est conçu et testé pour s’exécuter sur du matériel physique validé.
Azure Stack HCI peut s’exécuter imbriqué dans une machine virtuelle à des fins
d’évaluation, mais les environnements de production dans une configuration imbriquée
ne sont pas pris en charge.
Pour en savoir plus sur Azure Stack HCI imbriqué sur des machines virtuelles Hyper-V,
consultez l’article Virtualisation imbriquée dans Azure Stack HCI.
Conteneurs isolés Hyper-V s’exécutant imbriqués sur

Hyper-V
Microsoft propose une isolation Hyper-V pour les conteneurs. Ce mode d’isolation offre
une sécurité accrue et une plus grande compatibilité entre les versions de l’hôte et du
conteneur. Grâce à l’isolation Hyper-V, plusieurs instances de conteneur s’exécutent
simultanément sur un hôte. Chaque conteneur s’exécute à l’intérieur d’une machine
virtuelle hautement optimisée et reçoit effectivement son propre noyau. Étant donné
qu’un conteneur isolé Hyper-V assure l’isolation à l’aide d’une couche d’hyperviseur
entre lui et l’hôte du conteneur, quand celui-ci est une machine virtuelle basée sur
Hyper-V, cela entraîne une surcharge de performances. La surcharge de performances
associée se produit en termes de temps de démarrage du conteneur, de stockage, de
réseau et d’opérations du processeur.
Quand un conteneur isolé Hyper-V est exécuté dans une machine virtuelle Hyper-V, il
s’exécute imbriqué. L’utilisation d’une machine virtuelle Hyper-V ouvre de nombreux
scénarios utiles, mais augmente également la latence, car il existe deux niveaux
d’hyperviseurs s’exécutant sur l’hôte physique.
L’exécution de conteneurs isolés Hyper-V imbriqués sur Hyper-V est prise en charge.
Pour en savoir plus sur les conteneurs Hyper-V imbriqués, consultez l’article Réglage des
performances des conteneurs Windows Server.
Exécution de WSL 2 dans une machine virtuelle Hyper-V
s’exécutant imbriquée sur Hyper-V
Le sous-système Windows pour Linux (WSL) est une fonctionnalité du système
d’exploitation Windows qui vous permet d’exécuter un système de fichiers Linux, ainsi
que des outils en ligne de commande Linux et des applications GUI, directement sur
Windows.
L’exécution de WSL 2 dans une machine virtuelle Hyper-V s’exécutant imbriquée sur
Hyper-V est prise en charge.
Pour en savoir plus sur l’activation de WSL 2 dans une machine virtuelle, consultez le
forum aux questions sur le sous-système Windows pour Linux.
Étape suivante
Exécuter Hyper-V dans une machine virtuelle avec la virtualisation imbriquée
Déployer Hyper-V sur Windows Server
Article • 09/03/2023

Utilisez ces ressources pour vous aider à déployer Hyper-V sur Windows Server 2016.
Configurer des réseaux locaux virtuels pour Hyper-V

Configurer des hôtes une migration dynamique sans clustering de basculement
Mettre à niveau la version de la machine virtuelle dans Hyper-V sur Windows 10 ou
Windows Server 2016
Déployer des appareils graphiques à l’aide de la technologie Discrete Device
Assignment
Déployer des périphériques graphiques avec vGPU RemoteFX
Déployer des appareils de stockage à l’aide de la technologie Discrete Device
Assignment
Exporter et importer des machines
virtuelles
Article • 11/04/2023
Cet article vous montre comment exporter et importer des machines virtuelles, ce qui
est un moyen rapide de les déplacer ou de les copier. Cet article décrit également
certains des choix à faire lors d’une exportation ou d’une importation.
Exporter une machine virtuelle

Une exportation regroupe tous les fichiers requis en une seule unité : les fichiers de
disque dur virtuel, les fichiers de configuration de machine virtuelle et tous les fichiers
de point de contrôle. Vous pouvez faire cela sur une machine virtuelle dont l’état est
démarré ou arrêté.
À l’aide du Gestionnaire Hyper-V

Pour créer une exportation de machine virtuelle :
1. Dans le Gestionnaire Hyper-V, cliquez avec le bouton droit sur la machine virtuelle,
puis sélectionnez Exporter.
2. Choisissez où stocker les fichiers exportés, puis cliquez sur Exporter.
Une fois l’exportation terminée, tous les fichiers exportés apparaissent sous
l’emplacement de l’exportation.
Utilisation de PowerShell
Ouvrez une session en tant qu’administrateur et exécutez une commande comme suit,
après avoir remplacé le <nom> et le <chemin d’accès> de la machine virtuelle :
PowerShell
Export-VM -Name \<vm name\> -Path \<path\>

Pour plus d’informations, consultez Export-VM.
Importer une machine virtuelle

Lors de l’importation d’une machine virtuelle, celle-ci est inscrite auprès de l’hôte Hyper-
V. Vous pouvez la réimporter dans l’hôte ou dans le nouvel hôte. Si vous importez vers
le même hôte, vous n’avez pas besoin d’exporter d’abord la machine virtuelle, car
Hyper-V tente de recréer la machine virtuelle à partir des fichiers disponibles.
L’importation d’une machine virtuelle l’inscrit afin qu’elle puisse être utilisée sur l’hôte
Hyper-V.
） Important
Les configurations de machine virtuelle Hyper-V ont un numéro de version

spécifique. Vous ne pouvez importer une machine virtuelle que si l’hôte Hyper-V
prend en charge cette version de configuration. En règle générale, cela signifie que
vous pouvez importer une machine virtuelle vers un hôte Hyper-V exécutant une
version plus récente d’Hyper-V, mais que vous ne pouvez pas importer une
machine virtuelle créée sur une version plus récente d’Hyper-V vers une version
antérieure d’Hyper-V. Pour plus d’informations, consultez Versions de
configuration de machine virtuelle prises en charge.
L’Assistant Importation d’une machine virtuelle vous aide également à résoudre les
incompatibilités qui peuvent exister lors du passage d’un hôte à un autre. Il s’agit
généralement de différences dans le matériel physique, comme la mémoire, les
commutateurs virtuels et les processeurs virtuels.
Importer à l’aide du Gestionnaire Hyper-V

Pour importer une machine virtuelle :
1. Dans le menu Actions du Gestionnaire Hyper-V, cliquez sur Importer une machine
virtuelle.
2. Cliquez sur Suivant.
3. Sélectionnez le dossier contenant les fichiers exportés, puis cliquez sur Suivant.
4. Sélectionnez la machine virtuelle à importer.
5. Choisissez le type d’importation, puis cliquez sur Suivant. (Pour obtenir des
descriptions, consultez Importer des types, ci-dessous.)
6. Cliquez sur Terminer.
Importer à l’aide de PowerShell

Utilisez la cmdlet Import-VM, en suivant l’exemple pour le type d’importation souhaité.
Pour obtenir une description des types, consultez Importer des types, ci-dessous.
S’inscrire sur place

Ce type d’importation utilise les fichiers à l’endroit où ils sont stockés au moment de
l’importation et qu’elle conserve l’ID de la machine virtuelle. La commande suivante
montre un exemple de fichier d’importation. Exécutez une commande similaire avec vos
propres valeurs.
PowerShell
Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

29CED892A95A.vmcx'
Restaurer
Pour importer la machine virtuelle en spécifiant votre propre chemin d’accès pour les
fichiers de machine virtuelle, exécutez une commande comme celle-ci, en remplaçant les
exemples par vos valeurs :
PowerShell

29CED892A95A.vmcx' -Copy -VhdDestinationPath 'D:\Virtual Machines\WIN10DOC'
-VirtualMachinePath 'D:\Virtual Machines\WIN10DOC'
Importer en tant que copie

Pour effectuer une importation de copie et déplacer les fichiers de machine virtuelle vers
l’emplacement Hyper-V par défaut, exécutez une commande comme celle-ci, en
remplaçant les exemples par vos valeurs :
PowerShell

29CED892A95A.vmcx' -Copy -GenerateNewId
Pour plus d’informations, consultez Import-VM.
Importer les types

Hyper-V propose trois types d’importation :
Inscrire sur place : ce type suppose que les fichiers d’exportation se trouvent à
l’emplacement où vous allez stocker et exécuter la machine virtuelle. L’ID de la
machine virtuelle importée est le même qu’au moment de l’exportation. Pour cette
raison, si la machine virtuelle est déjà inscrite auprès d’Hyper-V, elle doit être
supprimée pour que l’importation fonctionne. Une fois l’importation terminée, les
fichiers d’exportation deviennent les fichiers d’état en cours d’exécution et ne
peuvent pas être supprimés.
Restaurer la machine virtuelle : restaurez la machine virtuelle à l’emplacement que

vous choisissez, ou utilisez la valeur par défaut Hyper-V. Ce type d’importation
crée une copie des fichiers exportés et les déplace à l’endroit sélectionné. Lors de
l’importation, l’ID de la machine virtuelle est le même qu’au moment de
l’exportation. Pour cette raison, si la machine virtuelle est déjà exécutée dans
d’Hyper-V, elle doit être supprimée pour que l’importation puisse se terminer. Une
fois l’importation terminée, les fichiers exportés restent intacts et peuvent être
supprimés ou réimportés.
Copier la machine virtuelle : semblable au type de restauration en ce sens que

vous sélectionnez un emplacement pour les fichiers. La différence est que la
machine virtuelle importée a un nouvel ID unique, ce qui signifie que vous pouvez
importer la machine virtuelle sur le même hôte plusieurs fois.
Configurer des hôtes une migration
dynamique sans clustering de
basculement
Article • 11/04/2023

Cet article vous montre comment configurer des hôtes qui ne sont pas en cluster afin de
pouvoir effectuer des migrations actives entre eux. Suivez ces instructions si vous n’avez
pas configuré la migration dynamique lorsque vous avez installé Hyper-V, ou si vous
souhaitez modifier les paramètres. Pour configurer des hôtes en cluster, utilisez des
outils pour le cluster de basculement.
Conditions requises pour la configuration de la

migration dynamique
Pour configurer des hôtes qui n’appartiennent pas à un cluster pour la migration
dynamique, vous avez besoin des éléments suivants :
Un compte d’utilisateur avec l’autorisation d’effectuer les différentes étapes.

L’appartenance au groupe Administrateurs Hyper-V local ou au groupe
Administrateurs sur les ordinateurs source et cible répond à cette exigence, sauf si
vous configurez la délégation contrainte. L’appartenance au groupe
Administrateurs de domaine est requise pour configurer la délégation contrainte.
Le rôle Hyper-V dans Windows Server 2016 ou Windows Server 2012 R2 installé
sur les serveurs source et cible. Vous pouvez effectuer une migration dynamique
entre des hôtes exécutant Windows Server 2016 et Windows Server 2012 R2 si la
machine virtuelle est au moins une version 5.
Pour obtenir des instructions de mise à niveau de version, consultez Mettre à
niveau la version de la machine virtuelle dans Hyper-V sur Windows 10 ou
Windows Server 2016. Pour obtenir des instructions d’installation, consultez
Installer le rôle Hyper-V sur Windows Server.
Les ordinateurs source et cible qui appartiennent au même domaine Active

Directory ou à des domaines qui se font confiance mutuellement.
Les outils d’administration Hyper-V installés sur un ordinateur exécutant Windows
Server 2016 ou Windows 10, sauf si les outils sont installés sur le serveur source ou
cible et que vous les exécutez à partir du serveur.
Envisagez les options d’authentification et de

mise en réseau
Réfléchissez à la façon dont vous souhaitez configurer les éléments suivants :
Authentification : quel protocole sera utilisé pour authentifier le trafic de

migration dynamique entre les serveurs source et cible ? Le choix détermine si
vous devez vous connecter au serveur source avant de commencer une migration
dynamique :
Kerberos vous permet d’éviter d’avoir à vous connecter au serveur, mais

nécessite la configuration de la délégation contrainte. Pour obtenir des
instructions, voir ci-dessous.
CredSSP vous permet d’éviter la configuration de la délégation contrainte, mais

vous oblige à vous connecter au serveur source. Vous pouvez le faire via une
session de console locale, une session Bureau à distance ou une session de
Windows PowerShell à distance.
CredSPP nécessite une connexion pour les cas qui ne sont pas évidents. Par
exemple, si vous vous connectez à TestServer01 pour déplacer un ordinateur
virtuel vers TestServer02 et que vous voulez ensuite ramener l’ordinateur virtuel
vers TestServer01, vous devrez vous connecter à TestServer02 avant d’essayer de
ramener l’ordinateur virtuel vers TestServer01. Si vous ne le faites pas, la
tentative d’authentification échoue, une erreur se produit et le message suivant
s’affiche :
« Échec de l’opération de migration d’ordinateur virtuel à l’emplacement source

de la migration. Échec de l’établissement d’une connexion avec l’hôte nom de
l’ordinateur : aucune information d’identification n’est disponible dans le
package de sécurité 0x8009030E."
Performances : Est-il judicieux de configurer les options de performances ? Ces

options peuvent réduire l’utilisation du réseau et du processeur, et accélérer les
migrations actives. Tenez compte de vos besoins et de votre infrastructure, et
testez différentes configurations pour vous aider à décider. Les options sont
décrites à la fin de la deuxième étape.
Préférence de réseau : Souhaitez-vous autoriser le trafic de migration dynamique à
traverser tout réseau disponible ou voulez-vous isoler le trafic dans des réseaux
spécifiques ? Pour des raisons de sécurité, il est conseillé d’isoler le trafic sur des
réseaux privés approuvés, car le trafic de migration dynamique n’est pas chiffré
lorsqu’il est envoyé sur le réseau. L’isolation du réseau peut être obtenue via un
réseau isolé physiquement ou une autre technologie de mise en réseau approuvée
comme les réseaux locaux virtuels.
Étape 1 : Configurer la délégation contrainte

(facultative)
Si vous avez décidé d’utiliser Kerberos pour authentifier le trafic de migration
dynamique, configurez la délégation contrainte à l’aide d’un compte membre du groupe
Administrateurs de domaine.
Utiliser le composant logiciel enfichable Utilisateurs et

ordinateurs pour configurer la délégation contrainte
1. Ouvrez le composant logiciel enfichable Utilisateurs et ordinateurs Active
Directory. (Dans Gestionnaire de serveur, sélectionnez le serveur si ce n’est pas fait,
cliquez sur Outils>>Utilisateurs et ordinateurs Active Directory).
2. Dans le volet de navigation dans Utilisateurs et ordinateurs Active Directory,

sélectionnez le domaine et double-cliquez sur le dossier Ordinateurs.
3. Dans le dossier Ordinateurs, cliquez avec le bouton droit sur le compte

d’ordinateur du serveur source, puis cliquez sur Propriétés.
4. Dans Propriétés, cliquez sur l’onglet Délégation.
5. Sous l’onglet Délégation, sélectionnez Faire confiance à cet ordinateur

uniquement pour la délégation aux services spécifiés puis sélectionnez Utiliser
tout protocole d’authentification.
6. Cliquez sur Add.
7. Dans Ajouter des services, cliquez sur Utilisateurs ou ordinateurs.
8. Dans Sélectionner des utilisateurs ou des ordinateurs, tapez le nom du serveur

cible. Cliquez sur Vérifier les noms, puis sur OK.
9. Dans Ajouter des services, dans la liste des services disponibles, procédez comme
suit, puis cliquez sur OK.
Pour déplacer le stockage de l’ordinateur virtuel, sélectionnez cifs. Ceci est

requis si vous souhaitez déplacer le stockage avec l’ordinateur virtuel ou si
vous voulez déplacer uniquement le stockage d’un ordinateur virtuel. Si le
serveur est configuré pour utiliser le stockage SMB pour Hyper-V, cela doit
être déjà sélectionné.
Pour déplacer les ordinateurs virtuels, sélectionnez Service de migration de

système virtuel Microsoft.
10. Dans l’onglet Délégation de la boîte de dialogue Propriétés, vérifiez que les
services que vous avez sélectionnés à l’étape précédente sont répertoriés comme
les services auxquels l’ordinateur de destination peut présenter les informations
d’identification déléguées. Cliquez sur OK.
11. Dans le dossier Computers, sélectionnez le compte d’ordinateur du serveur de

destination et répétez le processus. Dans la boîte de dialogue Sélectionner des
utilisateurs ou des ordinateurs, veillez à spécifier le nom du serveur source.
Les modifications de configuration prennent effet après les deux événements suivants :
Réplication des modifications sur les contrôleurs de domaine auxquels les serveurs
exécutant Hyper-V sont connectés.
Le contrôleur de domaine émet un nouveau ticket Kerberos.
Étape 2 : Configurer les ordinateurs source et

cible pour la migration dynamique
Cette étape comprend le choix des options d’authentification et de mise en réseau. Pour
des raisons de sécurité, il est conseillé de sélectionner des réseaux spécifiques à utiliser
pour le trafic de migration dynamique, comme indiqué plus tôt. Cette étape vous
montre également comment choisir l’option de performances.
Utiliser le Gestionnaire Hyper-V pour configurer les

ordinateurs sources et cible pour la migration dynamique
1. Ouvrez le Gestionnaire Hyper-V. (Dans Gestionnaire de serveur, cliquez sur
Outils>>Gestionnaire Hyper-V.)
2. Dans le volet de navigation, sélectionnez l’un des serveurs. (S’il n’est pas répertorié,
faites un clic droit sur Gestionnaire Hyper-V, cliquez sur Se connecter au serveur,
tapez le nom du serveur, puis cliquez sur OK. Répétez l’opération pour ajouter
d’autres serveurs.)
3. Dans le volet Action, cliquez sur Paramètres Hyper-V>>Migrations dynamiques.
4. Dans le volet Migrations dynamiques, sélectionnez Activer les migrations

dynamiques entrantes et sortantes.
5. Sous Migrations dynamiques simultanées, spécifiez un chiffre différent si vous ne

voulez pas utiliser la valeur par défaut 2.
6. Sous Migrations dynamiques entrantes, si vous voulez utiliser des connexions

réseau spécifiques pour accepter le trafic de migration dynamique, cliquez sur
Ajouter pour taper les informations d’adresse IP. Dans le cas contraire, cliquez sur
Utiliser n’importe quel réseau disponible pour la migration dynamique. Cliquez
sur OK.
7. Pour choisir Kerberos et les options de performances, développez Migrations

dynamiques, puis sélectionnez Fonctionnalités avancées.
Si vous avez configuré la délégation contrainte, sous Protocole

d’authentification, sélectionnez Kerberos.
Sous Options de performances, passez en revue les détails et choisissez une
autre option si elle convient à votre environnement.
8. Cliquez sur OK.
9. Sélectionnez l’autre serveur dans le Gestionnaire Hyper-V et répétez les étapes.
Utiliser Windows PowerShell pour configurer les

Trois applets de commande sont disponibles pour la configuration de la migration
dynamique sur des hôtes qui n’appartiennent pas au cluster : Enable-VMMigration, Set-
VMMigrationNetwork et Set-VMHost. Cet exemple utilise les trois et effectue les
opérations suivantes :
Configure la migration dynamique sur l’hôte local

Autorise le trafic de migration entrant uniquement sur un réseau spécifique
Choisit Kerberos comme protocole d’authentification
Chaque ligne représente une commande distincte.

PowerShell
PS C:\> Enable-VMMigration
PS C:\> Set-VMMigrationNetwork 192.168.10.1
PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Set-VMHost vous permet également de choisir une option de performances (et de

nombreux autres paramètres de l’hôte). Par exemple, pour choisir SMB mais laisser le
protocole d’authentification défini sur la valeur par défaut credSSP, tapez :
PowerShell
PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Ce tableau décrit le fonctionnement des options de performances.
Option Description
TCP/IP La mémoire de l’ordinateur virtuel est copiée sur le serveur cible via une
connexion TCP/IP.
Compression Compresse le contenu de mémoire de la machine virtuelle avant de le copier sur

le serveur cible via une connexion TCP/IP. Note : Il s’agit du paramètre par défaut.
SMB Le contenu de la mémoire de l’ordinateur virtuel est copié sur le serveur cible via
une connexion SMB 3.0.
- SMB Direct est utilisé quand les cartes réseau sur les serveurs source et cible
disposent de fonctionnalités Accès direct à la mémoire à distance (RDMA).
- SMB Multichannel détecte et utilise automatiquement plusieurs connexions
quand une configuration SMB Multichannel correcte est identifiée.
Pour plus d’informations, voir Améliorer les performances d’un serveur de fichiers
avec SMB Direct.
Étapes suivantes
Après avoir configuré les hôtes, vous êtes prêt à effectuer une migration dynamique.
Pour obtenir des instructions, consultez Utiliser la migration dynamique sans cluster de
basculement pour déplacer une machine virtuelle.
Mettre à niveau la version de la machine
virtuelle dans Hyper-V sur Windows ou
Windows Server
Article • 11/04/2023
S’applique à : Windows Server 2022, Windows 10, Windows Server 2019,

Windows Server 2016
Rendez les dernières fonctionnalités Hyper-V disponibles sur vos machines virtuelles en
mettant à niveau la version de configuration. Ne procédez pas avant d’avoir effectué ce
qui suit :
Vous mettez à niveau vos hôtes Hyper-V vers la dernière version de Windows ou
Windows Server.
Vous mettez à niveau le niveau fonctionnel du cluster.
Vous êtes sûr que vous n’aurez pas besoin de déplacer la machine virtuelle vers un
hôte Hyper-V qui exécute une version antérieure de Windows ou Windows Server.
Pour plus d’informations, consultez Mise à niveau propagée du système d’exploitation

de cluster et Effectuer une mise à niveau propagée d’un cluster hôte Hyper-V dans
VMM.
Étape 1 : Vérifier les versions de configuration

de la machine virtuelle
1. Sur le Bureau Windows, cliquez sur le bouton Démarrer et tapez une partie du nom
Windows PowerShell.
2. Cliquez avec le bouton droit sur Windows PowerShell, puis sélectionnez Exécuter
en tant qu’administrateur.
3. Utilisez la cmdlet Get-VM. Exécutez la commande suivante pour obtenir les
versions de vos machines virtuelles.
PowerShell
Get-VM * | Format-Table Name, Version
Vous pouvez également voir la version de configuration dans le Gestionnaire Hyper-V

en sélectionnant la machine virtuelle et en examinant l’onglet Résumé.
Étape 2 : Mettre à niveau la version de
configuration de la machine virtuelle
1. Arrêtez la machine virtuelle dans le Gestionnaire Hyper-V.
2. Sélectionnez Action > Mettre à niveau la version de la configuration. Si cette
option n’est pas disponible pour la machine virtuelle, cela signifie que la version de
configuration la plus récente prise en charge par l’hôte Hyper-V est déjà installée.
Pour mettre à niveau la version de la configuration de la machine virtuelle à l’aide de

Windows PowerShell, utilisez la cmdlet Update-VMVersion. Exécutez la commande
suivante, où vmname est le nom de la machine virtuelle.
PowerShell
Update-VMVersion <vmname>
Versions de la configuration de la machine

virtuelle prise en charge
À l’aide de la cmdlet PowerShell Get-VMHostSupportedVersion, vous pouvez voir les
versions de configuration de machine virtuelle prises en charge par votre hôte Hyper-V.
Lorsque vous créez une machine virtuelle, elle est créée avec la version de configuration
par défaut. Pour voir quelles versions de configuration de machine virtuelle votre hôte
Hyper-V prend en charge et quelles sont les versions par défaut, exécutez la commande
suivante.
PowerShell
Get-VMHostSupportedVersion
Si vous devez créer une machine virtuelle que vous pouvez déplacer vers un hôte
Hyper-V qui exécute une version antérieure de Windows, utilisez la cmdlet New-VM
avec le paramètre -Version . Par exemple, pour créer une machine virtuelle nommée
« WindowsCV5 » avec la configuration version 5.0, exécutez la commande suivante :
PowerShell
New-VM -Name "WindowsCV5" -Version 5.0
７ Notes
Vous ne pouvez importer une machine virtuelle que si l’hôte Hyper-V prend en
charge cette version de configuration. En règle générale, cela signifie que vous
pouvez importer une machine virtuelle vers un hôte Hyper-V exécutant une version
plus récente d’Hyper-V, mais que vous ne pouvez pas importer une machine
virtuelle créée sur une version plus récente d’Hyper-V vers une version antérieure
d’Hyper-V.
Si la version de configuration de la machine virtuelle n’est pas répertoriée comme

prise en charge pour votre système d’exploitation hôte Hyper-V dans le tableau ci-
dessous, vous devez mettre à niveau la version de configuration de la machine
virtuelle vers une version plus récente ou créer une machine virtuelle de la même
génération à l’aide des disques durs virtuels existants avant de pouvoir démarrer la
machine virtuelle.
Versions de configuration de machine virtuelle prises en

charge pour les hôtes de maintenance à long terme
Le tableau suivant répertorie les versions de configuration de machine virtuelle pour les
hôtes exécutant une version de maintenance à long terme de Windows.
Version de 10.0 9.3 9.2 9,1 9.0 8.3 8,2 8.1 8.0 7.1 7.0 6.2 5.0
Windows de l’hôte
Hyper-V
Windows ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
Server 2022
Windows 10 ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
Entreprise LTSC 2021
Windows ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Server 2019
Windows 10 ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Entreprise LTSC 2019
Windows ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
Server 2016
Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
Enterprise 2016 LTSB
Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔
Enterprise 2015 LTSB
Version de 10.0 9.3 9.2 9,1 9.0 8.3 8,2 8.1 8.0 7.1 7.0 6.2 5.0
Hyper-V
Windows ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔
Server 2012 R2
Windows 8.1 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔
Versions de configuration de machine virtuelle prises en

charge pour les hôtes de canal semi-annuel
Le tableau suivant répertorie les versions de configuration de machine virtuelle pour les
hôtes exécutant une version de canal semi-annuel de Windows. Pour obtenir plus
d’informations sur les versions de canal semi-annuel de Windows, consultez les pages
suivantes pour Windows Server et Windows.
Version de 10.0 9.3 9.2 9,1 9.0 8.3 8,2 8.1 8.0 7.1 7.0 6.2 5.0
Hyper-V
Windows 11 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
(version 21H2)
Windows 10 mise à ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
jour de
novembre 2021
(version 21H2)
Windows 10 mise à ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
jour de mai 2021
(version 21H1)
Windows Server, ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
version 20H2
Windows 10 mise à ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
jour d’octobre 2020
(version 20H2)
Windows Server, ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
version 2004
Windows 10 mise à ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✖ ✖ ✖ ✖
jour de mai 2020
(version 2004)
Version de 10.0 9.3 9.2 9,1 9.0 8.3 8,2 8.1 8.0 7.1 7.0 6.2 5.0
Hyper-V
Windows Server, ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
version 1909
Windows 10 mise à ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
jour de
novembre 2019
(version 1909)
Windows Server, ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
version 1903
Windows 10 mise à ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
jour de mai 2019
(version 1903)
Windows Server, ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
version 1809
Mise à jour de ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Windows 10
d’octobre 2018
(Version 1809)
Windows Server, ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
version 1803
Windows 10 - Mise à ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔
jour d’avril 2018
(version 1803)
Windows 10 Fall ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔ ✔
Creators Update
(version 1709)
Windows 10 ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔ ✔
Creators Update
(version 1703)
Mise à jour ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✖ ✔ ✔ ✔ ✔ ✔
anniversaire
Windows 10 (version
1607)
Pourquoi mettre à niveau la version de

configuration de la machine virtuelle ?
Lorsque vous déplacez ou importez une machine virtuelle sur un ordinateur qui exécute
Hyper-V sur Windows Server 2019, Windows Server 2016 ou Windows 10, la
configuration de la machine virtuelle n’est pas automatiquement mise à jour. Cela
signifie que vous pouvez déplacer la machine virtuelle vers un hôte Hyper-V qui exécute
une version précédente de Windows ou Windows Server. Toutefois, cela signifie
également que vous ne pouvez pas utiliser certaines des nouvelles fonctionnalités de
machine virtuelle tant que vous n’avez pas mis à jour manuellement la version de
configuration.
） Important
Vous ne pouvez pas rétrograder une version de configuration de machine virtuelle

une fois que vous l’avez mise à niveau.
La version de configuration de la machine virtuelle représente la compatibilité des

fichiers de configuration, d’état enregistré et d’instantané de la machine virtuelle avec la
version d’Hyper-V. Lorsque vous mettez à jour la version de configuration, vous
modifiez la structure de fichiers utilisée pour stocker la configuration des machines
virtuelles et les fichiers de point de contrôle. Vous mettez également à jour la version de
configuration vers la dernière version prise en charge par cet hôte Hyper-V. Les
machines virtuelles mises à niveau utilisent un nouveau format de fichier de
configuration qui est conçu pour accroître les performances de lecture et d’écriture des
données de configuration de machine virtuelle. La mise à niveau permet également de
réduire le risque de corruption des données en cas de défaillance du stockage.
Le tableau suivant répertorie les descriptions, les extensions de nom de fichier et les
emplacements par défaut pour chaque type de fichier utilisé pour les machines virtuelles
nouvelles ou mises à niveau.
Types de Description
fichiers de
machine
virtuelle
Configuration Informations de configuration de machine virtuelle stockées au format de

fichier binaire.
Extension de nom de fichier : .vmcx
Emplacement par défaut : C:\ProgramData\Microsoft\Windows\Hyper-
V\Virtual Machines
Types de Description
fichiers de
machine
virtuelle
État d’exécution Informations d’état du runtime de machine virtuelle stockées au format de

fichier binaire.
Extension de nom de fichier : .vmrs et .vmgs
V\Virtual Machines
Disque dur Stocke les disques durs virtuels pour la machine virtuelle.
virtuel Extension de nom de fichier : .vhd ou .vhdx
V\Virtual Hard Disks
Disque dur Fichiers de disque de différenciation utilisés pour les points de contrôle de
virtuel machine virtuelle.
automatique Extension de nom de fichier : .avhdx
V\Virtual Hard Disks
Point de contrôle Les points de contrôle sont stockés dans plusieurs fichiers de point de
contrôle. Chaque point de contrôle crée un fichier de configuration et un
fichier d’état d’exécution.
Extensions de nom de fichier : .vmrs et .vmcx
Emplacement par défaut : C:\ProgramData\Microsoft\Windows\Snapshots
Que se passe-t-il si je ne mets pas à jour la

version de configuration de machine virtuelle ?
Si vous avez créé des machines virtuelles avec une version antérieure d’Hyper-V,
certaines fonctionnalités disponibles sur le système d’exploitation hôte plus récent
peuvent ne pas fonctionner avec ces machines virtuelles tant que vous ne mettez pas à
jour la version de la configuration.
En règle générale, nous recommandons de mettre à jour la version de la configuration

après la mise à niveau des ordinateurs hôtes de virtualisation vers une version plus
récente de Windows, et lorsque vous êtes certain que vous n’aurez pas besoin de
restauration. Lorsque vous utilisez la fonctionnalité de mise à niveau propagée du
système d’exploitation de cluster, cela se produit généralement après la mise à jour du
niveau fonctionnel du cluster. De cette façon, vous bénéficiez également de nouvelles
fonctionnalités, ainsi que de modifications et d’optimisations internes.
７ Notes
Une fois la version de configuration de la machine virtuelle mise à jour, la machine
virtuelle ne peut pas démarrer sur les hôtes qui ne prennent pas en charge la
version de configuration mise à jour.
Le tableau suivant montre la version minimale de configuration de la machine virtuelle

requise pour utiliser certaines fonctionnalités d’Hyper-V.
Fonctionnalité Version de
configuration de
machine virtuelle
minimale
Autoriser des fonctionnalités de processeur supplémentaires pour 9.0

Perfmon
Exposer automatiquement la configuration de multithreading 9.0

simultané pour les machines virtuelles s’exécutant sur des hôtes à
l’aide du planificateur de cœurs
Prise en charge de la mise en veille prolongée 9.0
Augmenter le nombre maximal par défaut d’appareils virtuels à 64 par 8.3

appareil (par exemple, mise en réseau et appareils affectés)
Prise en charge de la sécurité basée sur la virtualisation invité (VBS) 8.0
Clé de stockage 8.0
Machines virtuelles à mémoire élevée 8.0
Virtualisation imbriquée 8.0
Nombre de processeurs virtuels 8.0
Support XSAVE 8.0
VMMQ (Virtual Machine Multi-Queue) 7.1
Module de plateforme sécurisée virtuelle (vTPM) 7.0
Ajout/suppression de mémoire à chaud 6.2
PowerShell Direct 6.2
Points de contrôle de production 6.2
Démarrage sécurisé pour les machines virtuelles Linux 6.2
Regroupement de machines virtuelles 6.2

Pour plus d’informations sur ces fonctionnalités, consultez Nouveautés d’Hyper-V sur
Windows Server.
Déployer des appareils graphiques à
l’aide de l’attribution d’appareils en
mode discret
Article • 20/07/2023

À compter de Windows Server 2016, vous pouvez utiliser l’attribution d’appareil discrète
(DDA) pour transmettre un appareil PCIe entier à une machine virtuelle (VM). Cela
permet un accès performant à des appareils tels que le stockage NVMe ou les cartes
graphiques à partir d’une machine virtuelle tout en étant en mesure d’appliquer des
pilotes natifs des appareils. Pour plus d’informations sur les appareils compatibles et les
implications de sécurité possibles, consultez Planifier le déploiement d’appareils à l’aide
de l’attribution d’appareils en mode discret.
） Important
Bien qu’il ne soit pas nécessaire, si la virtualisation d’E/S racine unique (SR-IOV)
n’est pas activée ou prise en charge, vous pouvez rencontrer des problèmes
lorsque vous utilisez DDA pour déployer des appareils graphiques.
Il existe trois étapes pour utiliser un appareil avec DDA :
1. Configurer la machine virtuelle pour DDA

2. Démonter l’appareil de la partition hôte
3. Affecter l’appareil à la machine virtuelle invitée
Vous pouvez exécuter toutes les commandes sur l’hôte dans une console PowerShell de
Windows en tant qu’administrateur.
Configurer la machine virtuelle pour DDA

La première étape de la solution consiste à traiter les restrictions DDA aux machines
virtuelles. Configurez la Automatic Stop Action machine virtuelle pour activer TurnOff
avec l’applet de commande PowerShell suivante :
PowerShell
Set-VM -Name VMName -AutomaticStopAction TurnOff
Préparation des machines virtuelles pour les appareils

graphiques
Certains matériels fonctionnent mieux si la machine virtuelle est configurée d’une
certaine manière. Pour plus d’informations sur la nécessité des configurations suivantes
pour votre matériel, contactez le fournisseur de matériel. Pour plus d’informations,
consultez Planifier le déploiement d’appareils à l’aide de l’attribution d’appareils en
mode discret et sur ce billet de blog .
1. Activez la combinaison d’écriture sur l’UC à l’aide de l’applet de commande

suivante :
PowerShell
Set-VM -GuestControlledCacheTypes $true -VMName VMName
2. Configurez l’espace MMIO 32 bits à l’aide de l’applet de commande suivante :
PowerShell
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName VMName
3. Configurez un espace MMIO supérieur à 32 bits à l’aide de l’applet de commande

suivante :
PowerShell
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName VMName
 Conseil
Les valeurs d’espace MMIO affichées sont des valeurs raisonnables à définir
pour expérimenter avec un seul GPU. Si, après avoir démarré la machine
virtuelle, l’appareil signale une erreur liée à des ressources insuffisantes, vous
devrez probablement modifier ces valeurs. Pour plus d’informations sur la
façon de calculer précisément les exigences MMIO, consultez Planifier le
déploiement d’appareils à l’aide d’une attribution d’appareils en mode
discret .
Démonter l’appareil de la partition hôte
Suivez les instructions de cette section pour démonter l’appareil de la partition hôte.
Installer le pilote de partitionnement (facultatif)

Le DDA permet aux fournisseurs de matériel de fournir un pilote d’atténuation de
sécurité avec leurs appareils. Ce pilote n’est pas identique au pilote de périphérique
installé dans la machine virtuelle invitée. C’est à la discrétion du fournisseur de matériel
de fournir ce pilote. Toutefois, s’ils fournissent un pilote, installez-le avant de démonter
l’appareil à partir de la partition hôte. Contactez le fournisseur de matériel pour vérifier
s’ils possèdent un pilote d’atténuation.
Si aucun pilote de partitionnement n’est fourni, lors du démontage, vous devez utiliser
l’option -Force pour contourner l’avertissement de sécurité. Pour plus d’informations
sur les implications en matière de sécurité, consultez Planifier le déploiement d’appareils
à l’aide de l’attribution d’appareils en mode discret.
Localiser le chemin d’emplacement de l’appareil

Le chemin d’accès à l’emplacement PCI est nécessaire pour démonter et monter
l’appareil à partir de l’hôte. Un exemple de chemin d’accès à l’emplacement ressemble à
ce qui suit : PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000) . Pour plus
d’informations sur la localisation du chemin d’accès à l’emplacement, consultez Planifier
le déploiement d’appareils à l’aide d’une attribution d’appareils en mode discret.
Désactivez l’appareil
Utilisez le Gestionnaire de périphériques ou PowerShell pour vous assurer que l’appareil
est désactivé .
Démonter l’appareil
Selon que le fournisseur a fourni un pilote d’atténuation, vous devez utiliser l’option -
Force ou non, comme indiqué ici :
Si un pilote d’atténuation a été installé, utilisez l’applet de commande suivante :
PowerShell
Dismount-VMHostAssignableDevice -LocationPath $locationPath

Si aucun pilote d’atténuation n’a pas été installé, utilisez l’applet de commande
suivante :
PowerShell
Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath
Attribuer l’appareil à la machine virtuelle

invitée
La dernière étape consiste à indiquer à Hyper-V qu’une machine virtuelle doit avoir
accès à l’appareil. Spécifier le chemin d’accès à l’emplacement et le nom de la machine
virtuelle.
PowerShell
Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName
Effectuer des tâches sur la machine virtuelle

Une fois qu’un appareil est monté avec succès dans une machine virtuelle, vous pouvez
désormais démarrer cette machine virtuelle et interagir avec l’appareil comme si vous
étiez un système nu. Vous pouvez désormais installer les pilotes du fournisseur de
matériel dans la machine virtuelle et les applications seront en mesure de voir le
matériel. Vous pouvez vérifier cela en ouvrant le gestionnaire de périphériques dans la
machine virtuelle invitée et vérifier que le matériel s’affiche.
Supprimer un appareil et le retourner à l’hôte

Si vous souhaitez rétablir l’état d’origine de l’appareil, vous devez arrêter la machine
virtuelle et exécuter cette commande :
PowerShell
# Remove the device from the VM

Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName
# Mount the device back in the host
Mount-VMHostAssignableDevice -LocationPath $locationPath
Vous pouvez ensuite réactiver l’appareil dans le gestionnaire de périphériques et le
système d’exploitation hôte sera en mesure d’interagir à nouveau avec l’appareil.
Monter un GPU sur une machine virtuelle

Cet exemple démontre comment utiliser PowerShell pour configurer une machine
virtuelle nommée ddatest1 afin de prendre le premier GPU disponible du fabricant
NVIDIA et de l’attribuer à la machine virtuelle.
PowerShell
# Configure the VM for a Discrete Device Assignment

$vm = "ddatest1"
# Set automatic stop action to TurnOff
Set-VM -Name $vm -AutomaticStopAction TurnOff
# Enable Write-Combining on the CPU
Set-VM -GuestControlledCacheTypes $true -VMName $vm
# Configure 32 bit MMIO space
Set-VM -LowMemoryMappedIoSpace 3Gb -VMName $vm
# Configure Greater than 32 bit MMIO space
Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName $vm
# Find the Location Path and disable the Device

# Enumerate all PNP Devices on the system
$pnpdevs = Get-PnpDevice -presentOnly
# Select only those devices that are Display devices manufactured by NVIDIA
$gpudevs = $pnpdevs | Where-Object {$_.Class -like "Display" -and
$_.Manufacturer -like "NVIDIA"}
# Select the location path of the first device that's available to be
dismounted by the host.
$locationPath = ($gpudevs | Get-PnpDeviceProperty
DEVPKEY_Device_LocationPaths).data[0]
# Disable the PNP Device
Disable-PnpDevice -InstanceId $gpudevs[0].InstanceId
# Dismount the Device from the Host

Dismount-VMHostAssignableDevice -Force -LocationPath $locationPath
# Assign the device to the guest VM.

Add-VMAssignableDevice -LocationPath $locationPath -VMName $vm
Résoudre les problèmes liés au montage d’un GPU

Si vous avez passé un GPU à une machine virtuelle, mais que le bureau à distance ou
une application ne reconnaît pas le GPU, vérifiez les problèmes courants suivants :
Vérifiez que vous avez installé la version la plus récente du pilote pris en charge
par le fournisseur du GPU et que le pilote ne signale pas d’erreurs. Pour ce faire,
vérifiez l’état de l’appareil dans gestionnaire de périphériques.
Assurez-vous que votre appareil dispose d’un espace MMIO suffisant alloué au
sein de la machine virtuelle. Pour plus d’informations, consultez Espace MMIO.
Vérifiez que vous utilisez un GPU que le fournisseur prend en charge dans cette
configuration. Par exemple, certains fournisseurs empêchent leurs cartes de
consommation de fonctionner lorsqu’elles sont passées à une machine virtuelle.
Assurez-vous que l’application prend en charge l’exécution à l’intérieur d’une

machine virtuelle et que l’application prend en charge à la fois le GPU et ses pilotes
associés. Certaines applications ont une liste d’autorisation de GPUs et
d’environnements.
Si vous utilisez le rôle Hôte de session Bureau à distance ou Windows Multipoint

Services sur l’invité, vous devez obligatoirement vous assurer qu’une entrée de
stratégie de groupe spécifique est définie pour autoriser l’utilisation du GPU par
défaut. Utilisez un objet de stratégie de groupe appliqué à l’invité (ou à l’éditeur de
stratégie de groupe local sur l’invité) pour accéder à l’élément de stratégie de
groupe suivant :
Configuration ordinateur\Modèles d’administrateur\Composants

Windows\Services Bureau à distance\Hôte de session Bureau à
distance\Environnement de session à distance\Utilisation des cartes graphiques
matérielles pour toutes les sessions des services Bureau à distance .
Définissez la stratégie de groupe sur Activé, puis redémarrez la machine virtuelle

une fois la stratégie appliquée.
Déployer des périphériques graphiques
avec vGPU RemoteFX
Article • 14/04/2023
Microsoft Hyper-V Server 2016
７ Notes
Pour des raisons de sécurité, le vGPU RemoteFX est désactivé par défaut sur toutes
les versions de Windows à partir de la mise à jour de sécurité du 14 juillet 2020 et
supprimé à partir de la Mise à jour de sécurité du 13 avril 2021. Pour plus
d’informations, consultez l’article KB 4570006 .
La fonctionnalité vGPU pour RemoteFX permet à plusieurs machines virtuelles de

partager un GPU physique. Les ressources de rendu et de calcul sont partagées
dynamiquement entre les machines virtuelles, ce qui rend le vGPU RemoteFX approprié
pour les charges de travail en rafale où des ressources GPU dédiées ne sont pas
nécessaires. Par exemple, dans un service VDI, vGPU RemoteFX peut être utilisé pour
faire passer les tâches de rendu des applications sur le GPU, ce qui a pour effet de
réduire la charge du processeur et d’améliorer la scalabilité du service.
Configuration requise pour la fonctionnalité

vGPU de RemoteFX
Configuration système requise pour l’hôte :
Windows Server 2016

Un GPU compatible DirectX 11.0 avec un pilote compatible WDDM 1.2
Un processeur avec prise en charge de SLAT (Second Level Address Translation)
Configuration requise pour la machine virtuelle invitée :
Système d’exploitation invité pris en charge. Pour plus d’informations, consultez

Prise en charge de l’adaptateur vidéo 3D (vGPU) RemoteFX.
Autres considérations relatives aux machines virtuelles invitées :

Les fonctionnalités OpenGL et OpenCL sont disponibles seulement dans les invités
exécutant Windows 10 ou Windows Server 2016.
DirectX 11.0 est disponible seulement pour les invités exécutant Windows 8 ou
ultérieur.
Activer vGPU RemoteFX

pour configurer vGPU RemoteFX sur votre hôte Windows Server 2016 :
1. Installez les pilotes graphiques recommandés par votre fournisseur de GPU pour
Windows Server 2016.
2. Créez une machine virtuelle exécutant un système d’exploitation invité pris en
charge par vGPU RemoteFX. Pour plus d’informations, consultez Prise en charge de
l’adaptateur vidéo 3D (vGPU) RemoteFX.
3. Ajoutez la carte graphique 3D RemoteFX à la machine virtuelle. Pour plus
d’informations, consultez Configurer l’adaptateur 3D vGPU RemoteFX.
Par défaut, vGPU RemoteFX va utiliser tous les GPU disponibles et pris en charge. Pour
limiter les GPU utilisés par vGPU RemoteFX, effectuez ces étapes :
1. Dans le Gestionnaire Hyper-V, accédez aux Paramètres Hyper-V.

2. Dans Paramètres Hyper-V, sélectionnez GPU physiques.
3. Sélectionnez le GPU que vous ne souhaitez pas utiliser, puis décochez Utiliser
cette unité GPU avec RemoteFX.
Configurer la carte RemoteFX vGPU 3D

Vous pouvez configurer la carte graphique RemoteFX vGPU 3D à l'aide de l'interface
utilisateur du Gestionnaire Hyper-V ou des applets de commande PowerShell.
Configurer vGPU RemoteFX avec le Gestionnaire Hyper-V
1. Arrêtez la machine virtuelle si elle est en cours d’exécution.
2. Ouvrez le Gestionnaire Hyper-V, accédez à Paramètres de la machine virtuelle,

puis sélectionnez Ajout de matériel.
3. Sélectionnez Carte graphique 3D RemoteFX, puis sélectionnez Ajouter.
4. Définissez le nombre maximum de moniteurs, la résolution maximale de ceux-ci et

la mémoire vidéo dédiée, ou conservez les valeurs par défaut.
７ Notes
La définition de valeurs plus élevées pour une ou plusieurs de ces

options aura un impact sur la mise à l’échelle de votre service : vous ne
devez donc définir que ce qui est nécessaire.
Quand vous avez besoin de 1 Go de VRAM dédiée, utilisez une machine
virtuelle invitée de 64 bits au lieu de 32 bits (x86) pour obtenir de
meilleurs résultats.
5. Sélectionnez OK pour terminer la configuration.
Configurer vGPU RemoteFX avec des cmdlets PowerShell

Exécutez les cmdlets PowerShell suivantes pour ajouter, passer en revue et configurer
l’adaptateur :
Add-VMRemoteFx3dVideoAdapter
Get-VMRemoteFx3dVideoAdapter
Set-VMRemoteFx3dVideoAdapter
Get-VMRemoteFXPhysicalVideoAdapter
Superviser les performances

Les performances et la mise à l’échelle d’un service activé pour vGPU RemoteFX
dépendent d’une variété de facteurs, comme le nombre total de GPU sur votre système,
la mémoire du système et sa vitesse, le nombre de cœurs de processeur et la fréquence
d’horloge du processeur, la rapidité du stockage et l’implémentation de l’architecture
NUMA.
Mémoire du système hôte

Pour chaque machine virtuelle activée avec un vGPU, RemoteFX utilise la mémoire du
système à la fois dans le système d’exploitation invité et dans le serveur hôte.
L’hyperviseur garantit la disponibilité de la mémoire du système pour un système
d’exploitation invité. Sur l’hôte, chaque bureau virtuel activé pour vGPU doit publier ses
besoins en mémoire système auprès de l’hyperviseur. Quand le bureau virtuel activé
pour vGPU démarre, l’hyperviseur réserve de la mémoire système supplémentaire dans
l’hôte.
La mémoire requise pour le serveur activé pour RemoteFX est dynamique, car la
quantité de mémoire consommée sur le serveur RemoteFX dépend du nombre de
moniteurs associés aux bureaux virtuels activés pour vGPU et de la résolution maximale
de ces moniteurs.
Mémoire vidéo GPU de l’hôte

Chaque bureau virtuel activé pour vGPU utilise la mémoire vidéo matérielle GPU sur le
serveur hôte pour rendre le bureau. En outre, un codec utilise la mémoire vidéo pour
compresser l’écran rendu. La quantité de mémoire nécessaire au rendu et à la
compression est directement basée sur le nombre de moniteurs provisionnés sur la
machine virtuelle. La quantité de mémoire vidéo réservée varie en fonction de la
résolution d’écran du système et du nombre de moniteurs. Certains utilisateurs ont
besoin d’une résolution d’écran plus élevée pour des tâches spécifiques, mais il existe
une plus grande scalabilité avec des paramètres de résolution inférieurs si tous les
autres paramètres restent constants.
Processeur de l’hôte
L’hyperviseur planifie l’hôte et les machines virtuelles sur le processeur. La surcharge est
augmentée sur un hôte activé pour RemoteFX, car le système exécute un processus
supplémentaire (rdvgm.exe) par bureau virtuel activé pour vGPU. Ce processus utilise le
pilote de périphérique graphique pour exécuter des commandes sur le GPU. Le codec
utilise également le processeur pour compresser les données d’écran qui doivent être
renvoyées au client.
Davantage de processeurs virtuels signifie une meilleure expérience utilisateur. Nous

recommandons d’allouer au moins deux processeurs virtuels par bureau virtuel activé
pour vGPU. Nous recommandons également d’utiliser l’architecture x64 pour les
bureaux virtuels activés pour vGPU, car les performances sur les machines virtuelles x64
sont meilleures que celles des machines virtuelles x86.
Puissance de traitement du GPU

Chaque bureau virtuel activé pour vGPU a un processus DirectX correspondant qui
s’exécute sur le serveur hôte. Ce processus réexécute toutes les commandes graphiques
qu’il reçoit du bureau virtuel RemoteFX sur le GPU physique. Ceci équivaut à exécuter
plusieurs applications DirectX en même temps sur le même GPU physique.
En règle générale, les périphériques graphiques et les pilotes sont configurés pour
exécuter seulement quelques applications à la fois sur le bureau, mais RemoteFX étend
les GPU pour aller encore plus loin. Les vGPU sont fournis avec des compteurs de
performances qui mesurent la réponse du GPU aux requêtes RemoteFX et vous aident à
vérifier que les GPU trop sollicités.
Quand un GPU a des ressources insuffisantes, les opérations de lecture et d’écriture

prennent beaucoup de temps. Les administrateurs peuvent utiliser des compteurs de
performances pour savoir quand ajuster les ressources et éviter les temps d’arrêt pour
les utilisateurs.
Pour en savoir plus sur les compteurs de performances pour la supervision du

comportement du vGPU RemoteFX, consultez Diagnostiquer les problèmes de
performances graphiques dans Bureau à distance.
Déployer des appareils de stockage
NVMe à l’aide de la technologie Discrete
Device Assignment
Article • 05/10/2023

Server 2016, Windows Server 2016
À compter de Windows Server 2016, vous pouvez utiliser l’attribution d’appareil discrète
ou DDA pour transmettre un appareil PCIe entier à une machine virtuelle. Cela
permettra un accès hautes performances à des appareils tels que le stockage NVMe ou
les cartes graphiques à partir d’une machine virtuelle tout en étant en mesure de tirer
parti des pilotes natifs des appareils. Consultez le Plan de déploiement d’appareils à
l’aide de l’affectation discrète d’appareils pour plus d’informations sur les appareils qui
fonctionnent, quelles sont les implications possibles en matière de sécurité, etc. Il y a
trois étapes pour utiliser un appareil avec DDA :

Affectation de l’appareil à la machine virtuelle invitée
Toutes les commandes peuvent être exécutées sur l’hôte sur une console Windows
PowerShell en tant qu’administrateur.

L’attribution d’appareil discrète impose certaines restrictions aux machines virtuelles et
l’étape suivante doit être effectuée.
1. Configurer l'« action d’arrêt automatique » d’une machine virtuelle pour désactiver
en exécutant
Set-VM -Name VMName -AutomaticStopAction TurnOff

Localisation du chemin d’emplacement de l’appareil
Le chemin d’accès vers l’emplacement PCI est requis pour démonter et monter l’appareil
à partir de l’hôte. Un exemple de chemin d’accès vers l’emplacement ressemble à ce qui
suit : "PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000)" . Pour plus d’informations
sur le chemin d’accès à l’emplacement, consultez Planifier le déploiement d’appareils à
l’aide de l’attribution d’appareil discrète.
Désactivez l’appareil
À l’aide de Gestionnaire de périphériques ou de PowerShell, vérifiez que l’appareil est «
désactivé ».
Démonter l’appareil
Dismount-VMHostAssignableDevice -LocationPath $locationPath
Affectation de l’appareil à la machine virtuelle

invitée
La dernière étape consiste à indiquer à Hyper-V qu’une machine virtuelle doit avoir
accès à l’appareil. En plus du chemin d’accès d’emplacement trouvé ci-dessus, vous
devez connaître le nom de la machine virtuelle.
Add-VMAssignableDevice -LocationPath $locationPath -VMName VMName
Prochaine étape
Une fois qu’un appareil est monté avec succès dans une machine virtuelle, vous pouvez
démarrer cette machine virtuelle et interagir avec l’appareil comme vous le feriez
normalement si vous étiez en cours d’exécution sur un système nu. Vous pouvez vérifier
cela en ouvrant le gestionnaire de périphériques dans la machine virtuelle invitée et en
voyant que le matériel s’affiche.
Suppression d’un appareil et renvoi à l’hôte
Si vous souhaitez revenir à l’état d’origine de l’appareil, vous devez arrêter la machine
virtuelle et émettre les éléments suivants :
#Remove the device from the VM

Remove-VMAssignableDevice -LocationPath $locationPath -VMName VMName
#Mount the device back in the host
Mount-VMHostAssignableDevice -LocationPath $locationPath
Vous pouvez ensuite réactiver l’appareil dans le gestionnaire de périphériques et le

système d’exploitation hôte pourra interagir à nouveau avec l’appareil.
Exécuter Hyper-V dans une machine
virtuelle avec la virtualisation imbriquée
Article • 28/07/2023
La virtualisation imbriquée est une fonctionnalité qui vous permet d’exécuter Hyper-V à
l’intérieur d’une machine virtuelle (VM) Hyper-V. La virtualisation imbriquée est utile
pour exécuter un émulateur de téléphone Visual Studio dans une machine virtuelle, ou
pour tester des configurations qui nécessitent normalement plusieurs hôtes.
Pour en savoir plus sur la virtualisation imbriquée et les scénarios pris en charge,
consultez Qu’est-ce que la virtualisation imbriquée pour Hyper-V ?.
Prérequis
Processeur Intel avec la technologie VT-x et EPT

L’hôte Hyper-V doit être Windows Server 2016 ou version ultérieure, ou Windows
10 ou version ultérieure.
Configuration de machine virtuelle version 8.0 ou ultérieure.
Processeur AMD EPYC/Ryzen ou version ultérieure

L’hôte Hyper-V doit être Windows Server 2016 ou version ultérieure, ou Windows
10 ou version ultérieure.
Configuration de machine virtuelle version 10.0 ou ultérieure.
７ Notes
L’invité peut être n’importe quel système d’exploitation invité pris en charge par
Windows. Les systèmes d’exploitation Windows plus récents prennent parfois en
charge l’état d’éveil à la présence d’un environnement virtualisé (« enlightenment »)
qui améliore les performances.
Configurer la virtualisation imbriquée

1. Création d’une machine virtuelle Consultez la configuration requise pour les
versions de système d’exploitation et les machines virtuelles.
2. Lorsque la machine virtuelle est à l’état OFF, exécutez la commande suivante sur
l’hôte Physique Hyper-V pour activer la virtualisation imbriquée pour la machine
virtuelle.
PowerShell
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
3. Démarrez la machine virtuelle.
4. Installez Hyper-V sur la machine virtuelle, comme vous le feriez sur un serveur
physique. Pour plus d’informations sur l’installation d’Hyper-V, consultez Installer
Hyper-V.
７ Notes
Lorsque vous utilisez Windows Server 2019 comme machine virtuelle de premier
niveau, le nombre de processeurs virtuels doit être inférieur ou égal à 225.
Désactiver la virtualisation imbriquée

Vous pouvez désactiver la virtualisation imbriquée d’une machine virtuelle à l’arrêt à
l’aide de la commande PowerShell suivante :
PowerShell
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $false
Options réseau
Il existe deux options pour la mise en réseau des machines virtuelles imbriquées :
1. Usurpation des adresses MAC

2. Mise en réseau NAT
Usurpation des adresses MAC

Pour que les paquets réseau puissent être acheminés via deux commutateurs virtuels,
l'usurpation des adresses MAC doit être activée sur le premier niveau (L1) du
commutateur virtuel. Pour activer l’usurpation des adresses MAC, exécutez la commande
PowerShell.
PowerShell
Get-VMNetworkAdapter -VMName <VMName> | Set-VMNetworkAdapter -

MacAddressSpoofing On
Traduction d’adresses réseau (NAT)

La deuxième option s’appuie sur la traduction d’adresses réseau (NAT). Cette approche
est idéale pour les cas où l’usurpation des adresses MAC n’est pas possible, comme
dans un environnement de cloud public.
Tout d’abord, un commutateur NAT virtuel doit être créé dans la machine virtuelle hôte
(machine virtuelle « intermédiaire »). L’exemple suivant crée un commutateur interne
nommé VmNAT et crée un objet NAT pour toutes les adresses IP du 192.168.100.0/24
sous-réseau.
PowerShell
New-VMSwitch -Name VmNAT -SwitchType Internal

New-NetNat –Name LocalNAT –InternalIPInterfaceAddressPrefix
“192.168.100.0/24”
Affectez ensuite une adresse IP à la carte réseau :
PowerShell
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress

192.168.100.1 -AddressFamily IPv4 -PrefixLength 24
Une adresse IP et une passerelle doivent être affectées à chaque machine virtuelle
imbriquée. L’adresse IP de la passerelle doit pointer vers la carte NAT de l’étape
précédente. Vous pouvez également affecter un serveur DNS :
PowerShell
Get-NetAdapter "vEthernet (VmNat)" | New-NetIPAddress -IPAddress

192.168.100.2 -DefaultGateway 192.168.100.1 -AddressFamily IPv4 -
PrefixLength 24
Netsh interface ip add dnsserver “vEthernet (VmNat)” address=<my DNS server>
Étapes suivantes
Gérer des hôtes Hyper-V distants avec le Gestionnaire Hyper-V
Gérer Hyper-V sur Windows Server
Article • 09/03/2023
Utilisez les ressources mentionnées dans cette section pour mieux gérer Hyper-V sur
Windows Server :
Configuration d'appareils à mémoire persistante pour les ordinateurs virtuels

Hyper-V
Choisir entre des points de contrôle standard ou de production
Créer une définition de VHD
Activer ou désactiver des points de contrôle
Gérer des hôtes avec le Gestionnaire Hyper-V
Gérer les contrôles de ressources du processeur hôte
Utilisation de groupes d'UC de machine virtuelle
Gérer les types de planificateur d'hyperviseur
À propos de la sélection du type de planificateur Hyper-V
Gérer les services d’intégration
Gérer les machines virtuelles Windows avec PowerShell Direct
Configurer le réplica Hyper-V
Activer le matériel de supervision des performances Intel
Déplacer les ordinateurs virtuels à l'aide d'une migration dynamique
Applets de commande pour la
configuration d’appareils à mémoire
persistante pour les machines virtuelles
Hyper-V
Article • 11/04/2023
S’applique à : Windows Server 2022, Windows Server 2019
Cet article fournit aux administrateurs système et aux professionnels de l’informatique

des informations sur la configuration des machines virtuelles Hyper-V avec de la
mémoire persistante (également appelée mémoire de classe de stockage ou NVDIMM).
Les périphériques de mémoire persistante NVDIMM-N compatibles JDEC sont pris en
charge sous Windows Server 2016 et Windows 10 et fournissent un accès au niveau des
octets aux appareils non volatiles à très faible latence. Les périphériques de mémoire
persistante des machines virtuelles sont pris en charge sous Windows Server 2019.
Créer un périphérique de mémoire persistant

pour une machine virtuelle
Utilisez l’applet de commande New-VHD pour créer un périphérique de mémoire
persistant pour une machine virtuelle. L’appareil doit être créé sur un volume NTFS DAX
existant. La nouvelle extension de nom de fichier (.vhdpmem) est utilisée pour spécifier
que l’appareil est un périphérique de mémoire persistante. Seul le format de fichier VHD
fixe est pris en charge.
Exemple : New-VHD d:\VMPMEMDevice1.vhdpmem -Fixed -SizeBytes 4GB
Créer une machine virtuelle avec un contrôleur

de mémoire persistant
Utilisez l’applet de commande New-VM pour créer une machine virtuelle de
génération 2 avec la taille de mémoire spécifiée et le chemin d’accès à une image VHDX.
Ensuite, utilisez Add-VMPmemController pour ajouter un contrôleur de mémoire
persistant à une machine virtuelle.
Exemple :
PowerShell
New-VM -Name "ProductionVM1" -MemoryStartupBytes 1GB -VHDPath

c:\vhd\BaseImage.vhdx
Add-VMPmemController ProductionVM1x
Lier un périphérique de mémoire persistant à

une machine virtuelle
Utiliser Add-VMHardDiskDrive pour lier un périphérique de mémoire persistante à une
machine virtuelle
Exemple : Add-VMHardDiskDrive ProductionVM1 PMEM -ControllerLocation 1 -Path

D:\VPMEMDevice1.vhdpmem
Les périphériques de mémoire persistante au sein d’une machine virtuelle Hyper-V

apparaissent comme un périphérique de mémoire persistante à consommer et à gérer
par le système d’exploitation invité. Les systèmes d’exploitation invités peuvent utiliser
l’appareil en tant que bloc ou volume DAX. Lorsque des périphériques de mémoire
persistants au sein d’une machine virtuelle sont utilisés comme volume DAX, ils
bénéficient d’une capacité d’adresse au niveau des octets à faible latence de l’appareil
hôte (aucune virtualisation d’E/S sur le chemin du code).
７ Notes
La mémoire persistante est uniquement prise en charge pour les machines

virtuelles Hyper-V de génération 2. La migration dynamique et la migration du
stockage ne sont pas prises en charge pour les machines virtuelles avec une
mémoire persistante. Les points de contrôle de production des machines virtuelles
n’incluent pas d’état de mémoire persistant.
Choisir entre des points de contrôle
standard ou de production dans Hyper-
V
Article • 11/04/2023
À partir de Windows Server 2016 et Windows 10, vous pouvez choisir entre des points
de contrôle standard et de production pour chaque machine virtuelle. Les nouvelles
machines virtuelles utilisent des points de contrôle de production par défaut.
Les points de contrôle de production sont des images « dans le temps » d’une
machine virtuelle. Vous pouvez par la suite restaurer ces images, celles-ci étant
entièrement prises en charge par toutes les charges de travail de production.
Notez que la création du point de contrôle repose sur la technologie de
sauvegarde de l’invité, et non sur la technologie de l’état de mise en mémoire.
Les points de contrôle standard capturent l’état, les données et la configuration

matérielle d’une machine virtuelle en cours d’exécution et sont destinés à être
utilisés dans des scénarios de développement et de test. Les points de contrôle
standard peuvent s’avérer utiles pour recréer un état ou une condition spécifique
d’une machine virtuelle afin de résoudre un problème.
Modifier les points de contrôle en points de

contrôle de production ou standard
1. Dans le Gestionnaire Hyper-V, cliquez avec le bouton droit sur la machine virtuelle,
puis cliquez sur Paramètres.
2. Sous la section Gestion, sélectionnez Points de contrôle.
3. Sélectionnez les points de contrôle de production ou les points de contrôle

standard.
Si vous choisissez les points de contrôle de production, vous pouvez également

spécifier si l’hôte doit créer un point de contrôle standard s’il est impossible de
créer un point de contrôle de production. Si vous décochez cette case et qu’aucun
point de contrôle de production ne peut être créé, aucun point de contrôle n’est
créé.
4. Si vous souhaitez stocker les fichiers de configuration de point de contrôle dans un

autre emplacement, modifiez-les dans la section Emplacement du fichier de point
de contrôle.
5. Cliquez sur Appliquer pour enregistrer vos modifications. Si vous avez terminé,
cliquez sur OK pour fermer la boîte de dialogue.
７ Notes
Seuls les points de contrôle de production sont pris en charge sur les invités qui
exécutent le rôle Active Directory Domain Services (contrôleur de domaine) ou le
rôle AD LDS (Active Directory Lightweight Directory Services).
Points de contrôle de production
Activer ou désactiver des points de contrôle

Créer des ensembles de disques durs
virtuels Hyper-V
Article • 14/04/2023
Les fichiers de définition de VHD sont un nouveau modèle de disque virtuel partagé
pour les clusters invités dans Windows Server 2016. Les fichiers de définition de VHD
prennent en charge le redimensionnement en ligne des disques virtuels partagés,
prennent en charge les réplicas Hyper-V et peuvent être inclus dans des points de
contrôle de cohérence des applications.
Les fichiers de définition de VHD utilisent un nouveau type de fichier VHD : .VHDS. Les
fichiers de définition de VHD stockent des informations de point de contrôle sur le
disque virtuel de groupe utilisé dans les clusters invités, sous la forme de métadonnées.
Hyper-V gère tous les aspects de la gestion des chaînes de points de contrôle et de la
fusion de la définition de VHD partagé. Le logiciel de gestion peut exécuter des
opérations de disque comme le redimensionnement en ligne sur les fichiers de
définition de VHD de la même façon que pour les fichiers .VHDX. Cela signifie que le
logiciel de gestion n’a pas besoin de connaître le format du fichier de définition de VHD.
７ Notes
Il est important d’évaluer l’impact des fichiers de définition de VHD avant le

déploiement en production. Vérifiez qu’il n’y a pas de dégradation fonctionnelle ou
des performances dans votre environnement, comme de la latence pour le disque.
Créer un fichier de définition de VHD à partir

du Gestionnaire Hyper-V
1. Ouvrez le Gestionnaire Hyper-V. Cliquez sur Démarrer, pointez sur Outils
d'administration, puis cliquez sur Gestionnaire Hyper-V.
2. Dans le volet Action, cliquez sur Nouveau, puis cliquez sur Disque dur.
3. Dans la page Choisir le format de disque, sélectionnez VHD Set comme format du
disque dur virtuel.
4. Continuez dans les pages de l’Assistant pour personnaliser le disque dur virtuel.
Vous pouvez cliquer sur Suivant pour avancer d'une page dans l'Assistant, ou vous
pouvez cliquer sur le nom d'une page dans le volet gauche pour passer
directement à cette page.
5. Une fois que vous avez terminé la configuration du disque dur virtuel, cliquez sur
Terminer.
Créer un fichier de définition de VHD à partir

de Windows PowerShell
Utilisez la cmdlet New-VHD, avec le type de fichier .VHDS dans le chemin du fichier. Cet
exemple crée un fichier de définition de VHD nommé base.vhds, d’une taille de
10 gigaoctets.
PowerShell
PS c:\>New-VHD -Path c:\base.vhds -SizeBytes 10GB
Migrer un fichier VHDX partagé vers un fichier

de définition de VHD
La migration d’un VHDX partagé existant vers un VHDS nécessite de mettre la machine
virtuelle hors connexion. Voici le processus recommandé avec Windows PowerShell :
1. Supprimez le VHDX de la machine virtuelle. Par exemple, exécutez :
PowerShell
PS c:\>Remove-VMHardDiskDrive existing.vhdx
2. Convertissez le VHDX en VHDS. Par exemple, exécutez :
PowerShell
PS c:\>Convert-VHD existing.vhdx new.vhds
3. Ajoutez le VHDS à la machine virtuelle. Par exemple, exécutez :
PowerShell
PS c:\>Add-VMHardDiskDrive new.vhds
Activer ou désactiver les points de
contrôle dans Hyper-V
Article • 11/04/2023
Vous pouvez choisir d’activer ou de désactiver les points de contrôle pour chaque
machine virtuelle.
1. Dans le Gestionnaire Hyper-V, cliquez avec le bouton droit sur l’ordinateur virtuel,
puis cliquez sur Paramètres.
2. Sous la section Gestion, sélectionnez Points de contrôle.
3. Pour permettre le retrait des points de contrôle de cette machine virtuelle, vérifiez
que l’option Activer les points de contrôle est sélectionnée. Pour désactiver les
points de contrôle, décochez la case Activer les points de contrôle.
4. Cliquez sur Appliquer pour appliquer vos modifications. Si vous avez terminé,
cliquez sur OK pour fermer la boîte de dialogue.
Choisir entre des points de contrôle standard ou de production dans Hyper-V
Gérer des hôtes Hyper-V distants avec le
Article • 14/04/2023
Windows Server 2012 R2, Windows 10, Windows 8.1
Cet article liste les combinaisons prises en charge des hôtes Hyper-V et des versions du
Gestionnaire Hyper-V, et explique comment se connecter à des hôtes Hyper-V distants
et locaux pour pouvoir les gérer.
Le Gestionnaire Hyper-V vous permet de gérer un petit nombre d’hôtes Hyper-V, à la

fois distants et locaux. Il est installé quand vous installez les outils d’administration
Hyper-V, ce que vous pouvez faire via une installation complète d’Hyper-V ou une
installation des outils uniquement. L’installation d’outils uniquement signifie que vous
pouvez utiliser les outils sur les ordinateurs qui ne répondent pas à la configuration
matérielle requise pour héberger Hyper-V. Pour plus d’informations sur le matériel pour
les hôtes Hyper-V, consultez Configuration système requise.
Si le Gestionnaire Hyper-V n’est pas installé, consultez les instructions ci-dessous.
Combinaisons prises en charge des versions du

Gestionnaire Hyper-V et de l’hôte Hyper-V
Dans certains cas, vous pouvez utiliser une version du Gestionnaire Hyper-V différente
de la version d’Hyper-V sur l’hôte, comme indiqué dans le tableau. Dans ce cas, le
Gestionnaire Hyper-V fournit les fonctionnalités disponibles pour la version d’Hyper-V
sur l’hôte que vous gérez. Par exemple, si vous utilisez la version du Gestionnaire Hyper-
V dans Windows Server 2012 R2 pour gérer à distance un hôte exécutant Hyper-V dans
Windows Server 2012, vous ne pourrez pas utiliser les fonctionnalités disponibles dans
Windows Server 2012 R2 sur cet hôte Hyper-V.
Le tableau suivant montre les versions d’un hôte Hyper-V que vous pouvez gérer à
partir d’une version particulière du Gestionnaire Hyper-V. Seules les versions du système
d’exploitation prises en charge sont listées. Pour plus d’informations sur l’état de la prise
en charge d’une version particulière du système d’exploitation, utilisez le bouton
Recherche par produit dans la page Politique de support Microsoft . En général, les
versions antérieures du Gestionnaire Hyper-V peuvent gérer seulement un hôte Hyper-V
exécutant la même version ou la version comparable de Windows Server.
Version du Gestionnaire Version de l’hôte Hyper-V
Hyper-V
Windows Server 2016, - Windows Server 2016 : toutes les éditions et options
Windows 10 d’installation, y compris Nano Server et la version
correspondante d’Hyper-V Server
- Windows Server 2012 R2 : toutes les éditions et options
d’installation, et la version correspondante d’Hyper-V Server
- Windows Server 2012 : toutes les éditions et options
- Windows 10
- Windows 8.1
Windows Server 2012 R2, - Windows Server 2012 R2 : toutes les éditions et options
Windows 8.1 d’installation, et la version correspondante d’Hyper-V Server
- Windows Server 2012 : toutes les éditions et options
- Windows 8.1
Windows Server 2012 - Windows Server 2012 : toutes les éditions et options
Windows Server 2008 R2 - Windows Server 2008 R2 : toutes les éditions et options
Service Pack 1, Windows 7 d’installation, et la version correspondante d’Hyper-V Server
Service Pack 1
Windows Server 2008, - Windows Server 2008 : toutes les éditions et options
Windows Vista Service Pack 2 d’installation, et la version correspondante d’Hyper-V Server
７ Notes
La prise en charge des Service Pack a pris fin pour Windows 8 le 12 janvier 2016.
Pour plus d’informations, consultez le Questions fréquentes (FAQ) sur
Windows 8.1 .
Se connecter à un hôte Hyper-V

Pour vous connecter à un hôte Hyper-V dans le Gestionnaire Hyper-V, Cliquez avec le
bouton droit sur Gestionnaire Hyper-V dans le volet gauche, puis cliquez sur Se
connecter au serveur.
Gérer Hyper-V sur un ordinateur local

Le Gestionnaire Hyper-V ne liste pas les ordinateurs qui hébergent Hyper-V tant que
vous n’avez pas ajouté l’ordinateur, y compris un ordinateur local. Pour ce faire :
1. Dans le volet gauche, cliquez avec le bouton droit sur Gestionnaire Hyper-V.
2. Cliquez sur Se connecter au serveur.
3. Dans Sélectionner un ordinateur, cliquez sur Ordinateur local, puis sur OK.
Si vous ne pouvez pas vous connecter :
Il est possible que seuls les outils Hyper-V soient installés. Pour vérifier que la
plateforme Hyper-V est installée, recherchez le service Gestion d’ordinateurs
virtuels. /(Ouvrez l’application de bureau Services : cliquez sur Démarrer, cliquez
sur la zone Démarrer la recherche, tapez services.msc, puis appuyez sur Entrée. Si
le service Gestion d’ordinateurs virtuels n’est pas listé, installez la plateforme
Hyper-V en suivant les instructions fournies dans Installer Hyper-V.
Vérifiez que le matériel respecte les spécifications. Voir Configuration requise.
Vérifiez que votre compte d’utilisateur appartient au groupe Administrateurs ou au
groupe Administrateurs Hyper-V.
Gérer des hôtes Hyper-V à distance

Pour gérer des hôtes Hyper-V distants, activez la gestion à distance à la fois sur
l’ordinateur local et sur l’hôte distant.
Sur Windows Server, ouvrez le Gestionnaire de serveur >Serveur local>Gestion à

distance, puis cliquez sur Autoriser les connexions à distance à cet ordinateur.
Ou, à partir de l’un ou l’autre des systèmes d’exploitation, ouvrez Windows PowerShell
en tant qu’administrateur et exécutez :
PowerShell
Enable-PSRemoting
Se connecter à des hôtes dans le même domaine

Pour Windows 8.1 et antérieur, la gestion à distance fonctionne seulement quand l’hôte
se trouve dans le même domaine et que votre compte d’utilisateur local se trouve
également sur l’hôte distant.
Pour ajouter un hôte Hyper-V distant au Gestionnaire Hyper-V, sélectionnez Un autre

ordinateur dans la boîte de dialogue Sélectionner un ordinateur, puis entrez le nom
d’hôte, le nom NetBIOS ou le nom de domaine complet de l’hôte distant.
Le Gestionnaire Hyper-V dans Windows Server 2016 et Windows 10 offre davantage de

types de connexion à distance que les versions précédentes ; ils sont décrits dans les
sections suivantes.
Se connecter à un hôte distant Windows Server 2016 ou

Windows 10 en tant qu’autre utilisateur
Ceci vous permet de vous connecter à l’hôte Hyper-V quand vous n’êtes pas connecté à
l’ordinateur local en tant qu’utilisateur membre du groupe Administrateurs Hyper-V ou
du groupe Administrateurs sur l’hôte Hyper-V. Pour ce faire :
3. Sélectionnez Se connecter en tant qu’autre utilisateur dans la boîte de dialogue
Sélectionner un ordinateur.
4. Sélectionnez Définir l’utilisateur.
７ Notes
Ceci va fonctionner seulement pour les hôtes distants Windows Server 2016 ou
Windows 10.

Windows 10 en utilisant une adresse IP
Pour ce faire :
3. Entrez l’adresse IP dans le champ texte Un autre ordinateur.
７ Notes
Windows 10.
Windows 10 en dehors de votre domaine ou sans
domaine
Pour ce faire :
1. Sur l’hôte Hyper-V à gérer, ouvrez une session Windows PowerShell en tant
qu’administrateur.
2. Créez les règles de pare-feu nécessaires pour les zones réseau privées :
PowerShell
Enable-PSRemoting
3. Pour autoriser l’accès à distance sur les zones publiques, activez des règles de
pare-feu pour CredSSP et WinRM :
PowerShell
Enable-WSManCredSSP -Role server
Pour plus d’informations, consultez Enable-PSRemoting et Enable-WSManCredSSP.
Ensuite, configurez l’ordinateur que vous allez utiliser pour gérer l’hôte Hyper-V.
1. Ouvrez une session Windows PowerShell en tant qu’administrateur.
2. Exécutez ces commandes :
PowerShell
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "fqdn-of-hyper-v-

host"
PowerShell
Enable-WSManCredSSP -Role client -DelegateComputer "fqdn-of-hyper-v-

host"
3. Vous devrez peut-être aussi configurer la stratégie de groupe suivante :
Configuration de l’ordinateur>Modèles
d’administration>Système>Délégation d’informations
d’identification>Autoriser la délégation de nouvelles informations
d’identification avec l’authentification de serveur NTLM uniquement
Cliquez sur Activer et ajoutez wsman/fqdn-of-hyper-v-host.
７ Notes
Windows 10.
Pour plus d’informations sur les cmdlets, consultez Set-Item et Enable-WSManCredSSP.
Installer le Gestionnaire Hyper-V

Pour utiliser un outil d’interface utilisateur, choisissez celui qui convient au système
d’exploitation sur l’ordinateur où vous allez exécuter le Gestionnaire Hyper-V :
Dans Windows Server, ouvrez le Gestionnaire de serveur >Gérer>Ajouter des rôles et

des fonctionnalités. Accédez à la page Fonctionnalités et développez Outils
d’administration de serveur distant>Outils d’administration de rôles>Outils
d’administration Hyper-V.
Dans Windows, le Gestionnaire Hyper-V est disponible sur n’importe quel système
d’exploitation Windows qui inclut Hyper-V.
1. Dans le bureau Windows, cliquez sur le bouton Démarrer et commencez à taper

Programmes et fonctionnalités.
2. Dans les résultats de la recherche, cliquez sur Programmes et fonctionnalités.
3. Dans le volet gauche, cliquez sur Activer ou désactiver des fonctionnalités
Windows.
4. Développez le dossier Hyper-V, puis cliquez sur Outils d’administration Hyper-V.
5. Pour installer le Gestionnaire Hyper-V, cliquez sur Outils de gestion Hyper-V. Si
vous voulez aussi installer le module Hyper-V, cliquez sur cette option.
Pour utiliser Windows PowerShell, exécutez la commande suivante en tant

qu’administrateur :
PowerShell
add-windowsfeature rsat-hyper-v-tools
Installer Hyper-V
Gestion des ressources du processeur
hôte Hyper-V
Article • 14/04/2023
Les contrôles de ressources du processeur hôte Hyper-V introduits dans Windows

Server 2016 ou ultérieur permettent aux administrateurs Hyper-V de mieux gérer et
allouer les ressources processeur du serveur hôte entre la « racine », ou partition de
gestion, et les machines virtuelles invitées. En utilisant ces contrôles, les administrateurs
peuvent dédier un sous-ensemble des processeurs d’un système hôte à la partition
racine. Ceci peut séparer le travail effectué dans un hôte Hyper-V des charges de travail
exécutées dans des machines virtuelles invitées en les exécutant sur des sous-ensembles
distincts des processeurs du système.
Pour plus d’informations sur le matériel pour les hôtes Hyper-V, consultez Configuration
requise pour Hyper-V sur Windows 10.
Contexte
Avant de définir des contrôles pour les ressources du processeur hôte Hyper-V, il est
utile de passer en revue les principes de base de l’architecture Hyper-V. Vous trouverez
un résumé général dans la section Architecture d’Hyper-V. Voici des concepts
importants pour cet article :
Hyper-V crée et gère des partitions de machines virtuelles, auxquelles les

ressources de calcul sont allouées et partagées, sous le contrôle de l’hyperviseur.
Les partitions fournissent des limites d’isolation fortes entre toutes les machines
virtuelles invitées, et entre les machines virtuelles invitées et la partition racine.
La partition racine est elle-même une partition de machine virtuelle, bien qu’elle ait
des propriétés uniques et des privilèges beaucoup plus importants que les
machines virtuelles invitées. La partition racine fournit les services de gestion qui
contrôlent toutes les machines virtuelles invitées, assure la prise en charge des
appareils virtuels pour les invités et gère toutes les E/S des appareils pour les
machines virtuelles invitées. Microsoft recommande fortement de n’exécuter
aucune charge de travail d’application dans une partition hôte.
Chaque processeur virtuel de la partition racine est mappé en mode 1:1 à un

processeur logique sous-jacent. Un processeur virtuel hôte s’exécute toujours sur
le même processeur logique sous-jacent : il n’y a pas de migration des processeurs
virtuels de la partition racine.
Par défaut, les processeurs logiques sur lesquels les processeurs virtuels hôtes
s’exécutent peuvent également exécuter des processeurs virtuels invités.
Un processeur virtuel invité peut être planifié par l’hyperviseur pour s’exécuter sur
n’importe quel processeur logique disponible. Alors que le planificateur de
l’hyperviseur prendre en compte la localisation du cache temporel, la topologie
NUMA et de nombreux autres facteurs lors de la planification d’un processeur
virtuel invité, le processeur virtuel peut au final être planifié sur n’importe quel
processeur logique hôte.
La racine minimale ou configuration

« minroot »
Les premières versions d’Hyper-V avaient une limite maximale en termes d’architecture
de 64 processeurs virtuels par partition. Ceci s’appliquait à la fois à la partition racine et
aux partitions d’invité. À mesure que des systèmes avec plus de 64 processeurs logiques
apparaissaient sur des serveurs haute performance, Hyper-V a également fait évoluer
ses limites d’échelle de l’hôte pour prendre en charge ces systèmes plus grands, en
prenant en charge un hôte avec jusqu’à 320 processeurs logiques. Cependant, le
dépassement de la limite de 64 processeurs virtuels par partition a présenté à ce
moment-là plusieurs problématiques et a introduit des complexités qui rendaient
prohibitive la prise en charge de plus de 64 processeurs virtuels par partition. Pour
résoudre ce problème, Hyper-V a limité à 64 le nombre de processeurs virtuels attribués
à la partition racine, même si la machine sous-jacente avait beaucoup plus de
processeurs logiques disponibles. L’hyperviseur continuait à utiliser tous les processeurs
logiques disponibles pour exécuter des machines virtuelles invitées, mais limitait
artificiellement la partition racine à 64. Cette configuration a été appelée « racine
minimale » ou « minroot ». Les tests de performances ont confirmé que, même sur des
systèmes à grande échelle avec plus de 64 processeurs logiques, la racine n’avait pas
besoin de plus de 64 processeurs virtuels racines pour fournir une prise en charge
suffisante à un grand nombre de machines virtuelles invitées et de processeurs virtuels
invités. En fait, beaucoup moins que 64 processeurs virtuels racines était souvent
adéquat, en fonction bien sûr du nombre et de la taille des machines virtuelles invitées,
des charges de travail spécifiques exécutées, etc.
Ce concept de « minroot » continue d’être utilisé aujourd’hui. En fait, même si Hyper-V

pour Windows Server 2016 a augmenté à 512 sa limite maximale de prise en charge de
l’architecture pour les processeurs logiques hôtes, la partition racine sera néanmoins
toujours limitée à un maximum de 320 processeurs logiques.
Utilisation de « minroot » pour limiter et isoler
les ressources de calcul de l’hôte
Avec le seuil par défaut élevé de 320 processeurs logiques dans Hyper-V pour Windows
Server 2016, la configuration « minroot » sera utilisée seulement sur les très grands
systèmes de serveurs. Cependant, cette fonctionnalité peut être configurée sur un seuil
beaucoup plus bas par l’administrateur de l’hôte Hyper-V, et donc exploitée pour
restreindre considérablement la quantité de ressources du processeur hôte disponibles
pour la partition racine. Le nombre spécifique de processeurs logiques racines à utiliser
doit bien sûr être choisi avec soin pour prendre en charge un nombre maximal de
demandes des machines virtuelles et des charges de travail allouées à l’hôte. Cependant,
des valeurs raisonnables pour le nombre de processeurs logiques hôtes peuvent être
déterminées via une évaluation et une supervision minutieuses des charges de travail de
production, et validées dans des environnements hors production avant un déploiement
à grande échelle.
Activation et configuration de « minroot »

La configuration de « minroot » est contrôlée via des entrées BCD de l’hyperviseur. Pour
activer « minroot », à partir d’une invite de commande avec des privilèges
d’administrateur :
bcdedit /set hypervisorrootproc n
Où n est le nombre de processeurs virtuels racines.
Le système doit être redémarré et le nouveau nombre de processeurs racines va être

conservé pendant toute la durée de vie du démarrage du système d’exploitation. La
configuration de « minroot » ne peut pas être changée dynamiquement à l’exécution.
S’il existe plusieurs nœuds NUMA, chaque nœud va obtenir n/NumaNodeCount

processeurs.
Notez qu’avec plusieurs nœuds NUMA, vous devez veiller à ce que la topologie de la
machine virtuelle soit telle qu’il y a suffisamment de processeurs logiques libres (c’est-à-
dire des processeurs logiques sans processeurs virtuels racines) sur chaque nœud
NUMA pour exécuter les processeurs virtuels du nœud NUMA de la machine virtuelle
correspondante.
Vérification de la configuration « minroot »
Vous pouvez vérifier la configuration « minroot » de l’hôte en utilisant le Gestionnaire
des tâches, comme illustré ci-dessous.
Quand « minroot » est active, le Gestionnaire des tâches affiche le nombre de

processeurs logiques actuellement alloués à l’hôte, en plus du nombre total de
processeurs logiques dans le système.
Contrôles des ressources de machine
virtuelle
Article • 28/08/2023

Cet article décrit les contrôles de l’isolation et des ressources Hyper-V pour les machines
virtuelles. Ces capacités, que nous appellerons « groupes processeur de machines
virtuelles », ou simplement « groupes processeur », ont été introduites dans Windows
Server 2016. Les groupes processeur permettent aux administrateurs Hyper-V de mieux
gérer et allouer les ressources de processeur de l’hôte sur les machines virtuelles
invitées. En utilisant des groupes processeur, les administrateurs Hyper-V peuvent :
Créer des groupes de machines virtuelles, chaque groupe ayant des allocations
différentes des ressources processeur totales de l’hôte de virtualisation, partagées
par l’ensemble du groupe. Ceci permet à l’administrateur de l’hôte d’implémenter
des classes de service pour différents types de machines virtuelles.
Définir des limites de ressources processeur pour des groupes spécifiques. Cette
« limite de groupe » définit la limite supérieure des ressources processeur de l’hôte
que l’ensemble du groupe peut consommer, appliquant ainsi la classe de service
souhaitée pour ce groupe.
Contraindre un groupe processeur à s’exécuter seulement sur un ensemble

spécifique de processeurs du système hôte. Ceci peut être utilisé pour isoler les
unes des autres des machines virtuelles appartenant à des groupes processeur
différents.
Gestion des groupes processeur

Les groupes processeur sont gérés via le Service de calcul hôte Hyper-V, ou HCS. Vous
trouverez une description complète du HCS, sa genèse, des liens vers les API HCS et
bien d’autres informations sur le blog de l’équipe Virtualisation Microsoft dans le billet
Présentation du Service de calcul hôte (HCS).
７ Notes
Seul le HCS peut être utilisé pour créer et gérer des groupes processeur ; ni l’applet
du Gestionnaire Hyper-V, ni les interfaces de gestion WMI et PowerShell ne
prennent en charge les groupes processeur.
Microsoft fournit un utilitaire de ligne de commande, cpugroups.exe, disponible sur le

Centre de téléchargement Microsoft , qui utilise l’interface HCS pour gérer les groupes
processeur. Cet utilitaire peut également afficher la topologie des processeurs d’un
hôte.
Fonctionnement des groupes processeur

L’allocation des ressources de calcul de l’hôte entre les groupes processeur est
appliquée par l’hyperviseur Hyper-V, en utilisant une limite calculée pour les groupes
processeur. La limite du groupe processeur est une fraction de la capacité processeur
totale pour un groupe processeur. La valeur de la limite du groupe dépend de la classe
du groupe ou du niveau de priorité affecté. La limite calculée du groupe peut être
considérée comme « un certain temps processeur des processeurs logiques ». Ce
budget de groupe étant partagé, si une seule machine virtuelle était active, elle pourrait
utiliser l’allocation processeur de tout le groupe pour elle-même.
La limite du groupe processeur est calculée comme suit : G = n x C, où :
G est la quantité de processeurs logiques de l’hôte que nous voulons affecter au

groupe
n est le nombre total de processeurs logiques dans le groupe
C est l’allocation de processeur maximale, c’est-à-dire la classe de service
souhaitée pour le groupe, exprimée en pourcentage de la capacité de calcul totale
du système.
Par exemple, considérez un groupe processeur configuré avec 4 processeurs logiques et

une limite de 50 %.
G=n*C
G = 4 * 50 %
G = le temps processeur de 2 processeurs logiques pour l’ensemble du groupe
Dans cet exemple, la valeur de G pour le groupe correspond à l’allocation du temps

processeur de 2 processeurs logiques.
Notez que la limite du groupe s’applique quel que soit le nombre de machines virtuelles
ou de processeurs virtuels liés au groupe, et quel que soit l’état (c’est-à-dire Arrêtée ou
Démarrée) des machines virtuelles affectées au groupe processeur. Par conséquent,
chaque machine virtuelle liée au même groupe processeur recevra une fraction de
l’allocation processeur totale du groupe, et ceci changera avec le nombre de machines
virtuelles liées au groupe processeur. Par conséquent, comme des machines virtuelles
sont liées à ou supprimées d’un groupe processeur, la limite globale du groupe
processeur doit être réajustée et définie pour conserver la limite souhaitée par machine
virtuelle. L’administrateur de l’hôte de machines virtuelles ou la couche logicielle de
gestion de la virtualisation est responsable de la gestion des limites de groupe de façon
à obtenir l’allocation des ressources processeur souhaitées par machine virtuelle.
Exemples de classes de service

Examinons quelques exemples simples. Pour commencer, supposons que
l’administrateur de l’hôte Hyper-V souhaite prendre en charge deux niveaux de service
pour les machines virtuelles invitées :
1. Un niveau faible, « C ». Nous allons attribuer à ce niveau 10 % de l’ensemble des

ressources de calcul de l’hôte.
2. Un niveau intermédiaire, « B ». 50 % de l’ensemble des ressources de calcul de

l’hôte sont alloués à ce niveau.
À ce stade de notre exemple, nous allons considérer qu’aucun autre contrôle de

ressource processeur n’est utilisé, comme des limites, des pondérations et des réserves
pour des machines virtuelles individuelles. Les limites des machines virtuelles
individuelles sont cependant importantes, comme nous le verrons un peu plus tard.
Par souci de simplicité, supposons que chaque machine virtuelle a 1 processeur virtuel
et que notre hôte a 8 processeurs logiques. Nous allons commencer avec un hôte vide.
Pour créer le niveau « B », l’administrateur de l’hôte définit la limite de groupe sur 50 % :
G=n*C
G = 8 * 50 %
G = le temps processeur de 4 processeurs logiques pour l’ensemble du groupe
L’administrateur de l’hôte ajoute une seule machine virtuelle de niveau « B ». À ce stade,

notre machine virtuelle de niveau « B » peut utiliser au maximum 50 % du processeur de
l’hôte, ou l’équivalent de 4 processeurs logiques dans notre exemple de système.
À présent, l’administrateur ajoute une deuxième machine virtuelle au niveau « B ».

L’allocation du groupe processeur est répartie uniformément entre toutes les machines
virtuelles. Nous avons un total de 2 machines virtuelles dans le groupe B, de sorte que
chaque machine virtuelle obtient maintenant la moitié du total de 50 % du groupe B,
soit 25 % chacune, ou l’équivalent du temps de calcul de 2 processeurs logiques.
Définition des limites de processeur sur des

machines virtuelles individuelles
En plus de la limite de groupe, chaque machine virtuelle peut également avoir une
« limite de machine virtuelle » individuelle. Les contrôles de ressources processeur par
machine virtuelle, incluant une limite, une pondération et une réserve de processeur, ont
fait partie d’Hyper-V depuis son introduction. Quand elle est combinée avec une limite
de groupe, une limite de machine virtuelle spécifie la quantité maximale de processeur
que chaque processeur virtuel peut obtenir, même si le groupe a des ressources
processeur disponibles.
Par exemple, l’administrateur de l’hôte peut souhaiter placer une limite de machine
virtuelle de 10 % sur les machines virtuelles « C ». De cette façon, même si la plupart des
processeurs virtuels de « C » sont inactifs, chaque processeur virtuel ne pourrait jamais
obtenir plus de 10 %. Sans une limite de machine virtuelle, les machines virtuelles de
« C » pourraient obtenir des performances au-delà de ce qui est autorisé par leur
niveau.
Isolation de groupes de machines virtuelles sur

des processeurs spécifiques de l’hôte
Les administrateurs d’hôtes Hyper-V peuvent également dédier des ressources de calcul
à une machine virtuelle. Par exemple, imaginez que l’administrateur voulait proposer
une machine virtuelle « A » premium avec une limite de classe de 100 %. Ces machines
virtuelles premium nécessitent également une latence une gigue planifiées les plus
faibles possibles, c’est-à-dire ne pouvant pas être déplanifiées par une autre machine
virtuelle. Pour obtenir cette séparation, un groupe processeur peut également être
configuré avec un mappage d’affinité de processeurs logiques spécifiques.
Par exemple, pour configurer une machine virtuelle « A » sur l’hôte dans notre exemple,
l’administrateur crée un groupe processeur et définit l’affinité processeur du groupe sur
un sous-ensemble des processeurs logiques de l’hôte. Les groupes B et C auraient alors
comme affinité les processeurs logiques restants. L’administrateur pourrait créer une
seule machine virtuelle dans le groupe A, qui aurait alors un accès exclusif à tous les
processeurs logiques du groupe A, tandis que les groupes des niveaux inférieurs B et C
partageraient les processeurs logiques restants.
Séparation des processeurs virtuels racines des
processeurs virtuels invités
Par défaut, Hyper-V crée un processeur virtuel racine sur chaque processeur logique
physique sous-jacent. Ces processeurs virtuels racines sont strictement mappés selon un
modèle 1:1 avec les processeurs logiques du système et ils ne migrent pas, c’est-à-dire
que chaque processeur virtuel racine s’exécute toujours sur le même processeur logique
physique. Les processeurs virtuels invités peuvent être exécutés sur n’importe quel
processeur logique disponible et partagent l’exécution avec les processeurs virtuels
racines.
Cependant, il peut être souhaitable de séparer complètement l’activité des processeurs

virtuels racines des processeurs virtuels invités. Considérons notre exemple ci-dessus, où
nous implémentons une machine virtuelle premium de niveau « A ». Pour garantir que
les machines virtuelles de notre machine virtuelle « A » ont une latence et une « gigue »,
ou une variation de planification, les plus faibles possibles, nous aimerions les exécuter
sur un ensemble dédié de processeurs logiques, et être sûrs que la racine ne s’exécute
pas sur ces processeurs logiques.
Pour cela, nous pouvons utiliser une combinaison de la configuration « minroot », qui
limite l’exécution de la partition du système d’exploitation hôte à un sous-ensemble du
nombre total de processeurs logiques du système, et d’un ou plusieurs groupes
processeur avec des affinités.
L’hôte de virtualisation peut être configuré pour restreindre la partition d’hôte à des
processeurs logiques spécifiques, avec un ou plusieurs groupes processeur ayant
comme affinité les processeurs logiques restants. De cette façon, les partitions racine et
invités peuvent s’exécuter sur des ressources processeur dédiées et complètement
isolées, sans partage de processeurs.
Pour en savoir plus sur la configuration de « minroot », consultez Gestion des ressources
du processeur hôte Hyper-V.
Utilisation de l’outil CpuGroups

Examinons quelques exemples d’utilisation de l’outil CpuGroups.
７ Notes
Les paramètres de ligne de commande de l’outil CpuGroups sont passés en

utilisant seulement des espaces comme délimiteurs. Aucun caractère « / » ou « - »
ne doit précéder le commutateur de ligne de commande souhaité.
Découverte de la topologie des processeurs

L’exécution de CpuGroups avec GetCpuTopology retourne des informations sur le
système actuel, comme indiqué ci-dessous, notamment l’index des processeurs
logiques, le nœud NUMA auquel appartient le processeur logique, les ID de package et
de cœur, et l’index des processeurs virtuels RACINES.
L’exemple suivant montre un système avec 2 sockets de processeur et des nœuds

NUMA, un total de 32 processeurs logiques et le multithreading activé, et configuré
pour activer « minroot » avec 8 processeurs virtuels racines, 4 dans chaque nœud
NUMA. Les processeurs logiques qui ont des processeurs virtuels racines ont un
RootVpIndex >= 0 ; Les processeurs logiques avec une valeur RootVpIndex de -1 ne
sont pas disponibles pour la partition racine, mais ils sont néanmoins toujours gérés par
l’hyperviseur et vont exécuter des processeurs virtuels invités selon ce qui est autorisé
par d’autres paramètres de configuration.
Console
C:\vm\tools>CpuGroups.exe GetCpuTopology
LpIndex NodeNumber PackageId CoreId RootVpIndex

------- ---------- --------- ------ -----------
0 0 0 0 0
1 0 0 0 1
2 0 0 1 2
3 0 0 1 3
4 0 0 2 -1
5 0 0 2 -1
6 0 0 3 -1
7 0 0 3 -1
8 0 0 4 -1
9 0 0 4 -1
10 0 0 5 -1
11 0 0 5 -1
12 0 0 6 -1
13 0 0 6 -1
14 0 0 7 -1
15 0 0 7 -1
16 1 1 16 4
17 1 1 16 5
18 1 1 17 6
19 1 1 17 7
20 1 1 18 -1
21 1 1 18 -1
22 1 1 19 -1
23 1 1 19 -1
24 1 1 20 -1
25 1 1 20 -1
26 1 1 21 -1
27 1 1 21 -1
28 1 1 22 -1
29 1 1 22 -1
30 1 1 23 -1
31 1 1 23 -1
Exemple 2 : Afficher tous les groupes processeur sur

l’hôte
Ici, nous allons lister tous les groupes processeur sur l’hôte actuel, leur GroupId, la limite
de processeur du groupe et les indices des processeurs logiques affectés à ce groupe.
Notez que les valeurs de limite de processeur valides sont dans la plage [0, 65536] et
que ces valeurs expriment la limite de groupe en pourcentage (par exemple 32768 =
50 %).
Console
C:\vm\tools>CpuGroups.exe GetGroups
CpuGroupId CpuCap LpIndexes

------------------------------------ ------ --------
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31
Exemple 3 : Afficher un groupe processeur spécifique

Dans cet exemple, nous allons interroger un groupe processeur spécifique en utilisant le
GroupId comme filtre.
Console
C:\vm\tools>CpuGroups.exe GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000003
------------------------------------ ------ ----------
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
Exemple 4 : Créer un groupe processeur

Ici, nous allons créer un groupe processeur en spécifiant l’ID de groupe et l’ensemble de
processeurs logiques à affecter au groupe.
Console
C:\vm\tools>CpuGroups.exe CreateGroup /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /GroupAffinity:0,1,16,17
Affichons maintenant notre groupe nouvellement ajouté.
Console
------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 65536 0,1,16,17
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31
Exemple 5 : Définir la limite du groupe processeur sur

50 %
Ici, nous allons définir la limite du groupe processeur sur 50 %.
Console
C:\vm\tools>CpuGroups.exe SetGroupProperty /GroupId:36AB08CB-3A76-4B38-992E-

000000000001 /CpuCap:32768
Vérifions maintenant notre paramétrage en affichant le groupe que nous venons de

mettre à jour.
Console
C:\vm\tools>CpuGroups.exe GetGroups /GroupId:36AB08CB-3A76-4B38-992E-

000000000001

------------------------------------ ------ ---------
36AB08CB-3A76-4B38-992E-000000000001 32768 0,1,16,17
Exemple 6 : Afficher les ID des groupes processeur pour

toutes les machines virtuelles sur l’hôte
Console
C:\vm\tools>CpuGroups.exe GetVmGroup
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G2 4ABCFC2F-6C22-498C-BB38-7151CE678758 36ab08cb-3a76-4b38-992e-
000000000002
P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC 36ab08cb-3a76-4b38-992e-
000000000003
P2 A593D93A-3A5F-48AB-8862-A4350E3459E8 36ab08cb-3a76-4b38-992e-
000000000004
G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200 36ab08cb-3a76-4b38-992e-
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36ab08cb-3a76-4b38-992e-
000000000002
Exemple 7 : Dissocier une machine virtuelle du groupe

processeur
Pour supprimer une machine virtuelle d’un groupe processeur, définissez le CpuGroupId
de la machine virtuelle sur un GUID NULL. Ceci dissocie la machine virtuelle du groupe
processeur.
Console
C:\vm\tools>CpuGroups.exe SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
000000000002
000000000003
000000000004
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000
Exemple 8 : Lier une machine virtuelle à un groupe
processeur existant
Ici, nous allons ajouter une machine virtuelle à un groupe processeur existant. Notez
que la machine virtuelle ne doit être liée à aucun groupe processeur existant, sans quoi
la définition de l’ID du groupe processeur échoue.
Console
C:\vm\tools>CpuGroups.exe SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000001
Vérifions maintenant que la machine virtuelle G1 se trouve dans le groupe processeur

souhaité.
Console
VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
000000000002
000000000003
000000000004
000000000002
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 36AB08CB-3A76-4B38-992E-
000000000001
Exemple 9 : Afficher toutes les machines virtuelles

regroupées par ID de groupe processeur
Console
C:\vm\tools>CpuGroups.exe GetGroupVms
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-
D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-
A4350E3459E8
Exemple 10 : Afficher toutes les machines virtuelles pour

un même groupe processeur
Console
C:\vm\tools>CpuGroups.exe GetGroupVms /GroupId:36ab08cb-3a76-4b38-992e-

000000000002
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-
7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-
DE4102787200
Exemple 11 : Tentative de suppression d’un groupe

processeur non vide
Seuls les groupes processeur vides, c’est-à-dire les groupes processeur sans machines
virtuelles liées, peuvent être supprimés. La tentative de suppression d’un groupe
processeur non vide échoue.
Console
C:\vm\tools>CpuGroups.exe DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001
(null)
Failed with error 0xc0350070
Exemple 12 : Dissocier la seule machine virtuelle d’un

groupe processeur et supprimer le groupe
Dans cet exemple, nous allons utiliser plusieurs commandes pour examiner un groupe
processeur, supprimer la seule machine virtuelle appartenant à ce groupe, puis
supprimer le groupe.
Tout d’abord, énumérons les machines virtuelles de notre groupe.
Console
C:\vm\tools>CpuGroups.exe GetGroupVms /GroupId:36AB08CB-3A76-4B38-992E-

000000000001
CpuGroupId VmName
VmId
------------------------------------ ------ --------------------------------
----
36AB08CB-3A76-4B38-992E-000000000001 G1 F699B50F-86F2-4E48-8BA5-
EB06883C1FDC
Nous voyons qu’une seule machine virtuelle, nommée G1, appartient à ce groupe.
Supprimons la machine virtuelle G1 de notre groupe en définissant l’ID de groupe de la
machine virtuelle sur NULL.
Console
C:\vm\tools>CpuGroups.exe SetVmGroup /VmName:g1 /GroupId:00000000-0000-0000-

0000-000000000000
Et vérifions notre modification...
Console
C:\vm\tools>CpuGroups.exe GetVmGroup /VmName:g1

VmName VmId
CpuGroupId
------ ------------------------------------ --------------------------------
----
G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC 00000000-0000-0000-0000-
000000000000
Maintenant que le groupe est vide, nous pouvons le supprimer sans problème.
Console
C:\vm\tools>CpuGroups.exe DeleteGroup /GroupId:36ab08cb-3a76-4b38-992e-

000000000001
Et nous vérifions que notre groupe a disparu.
Console
------------------------------------ ------ -----------------------------
36AB08CB-3A76-4B38-992E-000000000002 32768 4,5,6,7,8,9,10,11,20,21,22,23
36AB08CB-3A76-4B38-992E-000000000003 65536 12,13,14,15
36AB08CB-3A76-4B38-992E-000000000004 65536 24,25,26,27,28,29,30,31
Exemple 13 : Lier à nouveau une machine virtuelle à son

groupe processeur d’origine
Console
C:\vm\tools>CpuGroups.exe SetVmGroup /VmName:g1 /GroupId:36AB08CB-3A76-4B38-

992E-000000000002
C:\vm\tools>CpuGroups.exe GetGroupVms
CpuGroupId VmName VmId
------------------------------------ -------------------------------- ------
------------------------------
36ab08cb-3a76-4b38-992e-000000000002 G2 4ABCFC2F-6C22-498C-BB38-7151CE678758
36ab08cb-3a76-4b38-992e-000000000002 G3 B0F3FCD5-FECF-4A21-A4A2-DE4102787200
36AB08CB-3A76-4B38-992E-000000000002 G1 F699B50F-86F2-4E48-8BA5-EB06883C1FDC
36ab08cb-3a76-4b38-992e-000000000003 P1 973B9426-0711-4742-AD3B-D8C39D6A0DEC
36ab08cb-3a76-4b38-992e-000000000004 P2 A593D93A-3A5F-48AB-8862-A4350E3459E8
Gérer les types de planificateur
d’hyperviseur Hyper-V
Article • 08/08/2023
Windows Server version 1803, Windows Server version 1709, Windows 10
Cet article décrit les nouveaux modes de logique de planification du processeur virtuel
introduits dans Windows Server 2016. Ces modes, ou types de planificateurs,
déterminent la façon dont l’hyperviseur Hyper-V alloue et gère le travail entre les
processeurs virtuels invités. Un administrateur hôte Hyper-V peut :
Sélectionnez les types de planificateurs d’hyperviseur qui conviennent le mieux aux

machines virtuelles invitées.
Configurez des machines virtuelles pour tirer parti de la logique de planification.
Prérequis
Vous devez installer les mises à jour suivantes pour utiliser les fonctionnalités du
planificateur d’hyperviseur décrites plus loin dans cet article. Ces mises à jour incluent
des modifications pour prendre en charge la nouvelle option BCD
hypervisorschedulertype , qui est nécessaire pour la configuration de l’hôte.
Version Version Mise à jour nécessaire KB Article
Windows Server 2016 1607 2018.07 C KB4338822
Windows Server 2019 1804 Aucune Aucune
Contexte
Avant de discuter de la logique et des contrôles derrière la planification du processeur
virtuel Hyper-V, il est important de comprendre certains concepts tels que le
multithreading simultané et la façon dont Hyper-V virtualise les processeurs.
Comprendre SMT
Le multithreading simultané (SMT) est une technique dans les conceptions de
processeur modernes qui permet de séparer les threads d’exécution distincts et
indépendants de partager les ressources du processeur. Le SMT permet généralement
d’améliorer légèrement les performances de la plupart des charges de travail. Il
parallélise les calculs lorsque cela est possible, ce qui augmente le débit des instructions.
Toutefois, il existe également des moments où il n’y a pas d’amélioration notable des
performances ou il peut même s’avérer une légère perte lorsque les threads sont en
concurrence les uns avec les autres pour les ressources de processeur partagées.
Pour utiliser le SMT avec Windows Server, vous devez disposer d’un processeur
compatible. Par exemple, un processeur avec la technologie Intel Hyper-Threading ou
des Micro Devices (AMD) Multithreading (SMT) avancés.
Pour les besoins de cet article, les descriptions de SMT et la façon dont elle est utilisée
par Hyper-V s’appliquent de manière égale aux systèmes Intel et AMD.
Pour plus d’informations sur la technologie Intel HT, consultez technologie Intel
Hyper-Threading .
Pour plus d’informations sur AMD SMT, consultez l’architecture principale « Zen
» .
Comprendre comment Hyper-V virtualise les processeurs

Avant d’envisager les types de planificateur d’hyperviseur, vous devez comprendre
l’architecture Hyper-V. Vous trouverez un résumé plus détaillé du fonctionnement de
cette architecture dans la vue d’ensemble de la technologie Hyper-V, mais pour l’instant,
vous devez garder à l’esprit les concepts suivants :
Hyper-V crée et gère les partitions de machine virtuelle, alloue et partage les
ressources de calcul entre elles, sous le contrôle de l’hyperviseur. Les partitions
fournissent des limites d’isolation fortes entre toutes les machines virtuelles
invitées et entre les machines virtuelles invitées et la partition racine.
La partition racine est elle-même une partition de machine virtuelle, bien qu’elle ait
des propriétés uniques et des privilèges supérieurs à ceux des machines virtuelles
invitées. Partition racine :
Fournit les services de gestion qui contrôlent toutes les machines virtuelles
invitées.
Fournit la prise en charge des appareils virtuels pour les invités.
Gère toutes les entrées et sorties de l’appareil pour les machines virtuelles
invitées.
Nous vous recommandons de ne pas exécuter de charges de travail d’application
dans la partition racine.
Chaque processeur virtuel de la partition racine est mappé en mode un à un avec

un processeur logique sous-jacent. Un VP hôte s’exécute toujours sur le même LP
sous-jacent. Il n’existe aucune migration des adresses virtuelles de la partition
racine.
Par défaut, les processeurs logiques qui hébergent la racine des partitions des
processeurs virtuels peuvent également exécuter des processeurs virtuels invitées.
Hyperviseur peut planifier l’exécution du VP invité sur n’importe quel processeur

logique disponible. Bien que le planificateur d’hyperviseur tente d’envisager la
localité temporelle du cache, la topologie d’accès à la mémoire non uniforme
(NUMA) et de nombreux autres facteurs lors de la planification d’un VP invité, en
fin de compte, le VP peut être planifié sur n’importe quel LP hôte.
Types de planificateurs de l’hyperviseur

Dans Windows Server 2016, l’hyperviseur Hyper-V prend en charge plusieurs modes de
logique de planificateur, qui déterminent la façon dont l’hyperviseur planifie les
processeurs virtuels sur les processeurs logiques sous-jacents. Ces types de
planificateurs sont les suivants :
Le planificateur classique.
Le planificateur principal.
Le planificateur racine.
Le planificateur classique
Le planificateur classique a été le planificateur par défaut pour toutes les versions de
l’hyperviseur Windows Hyper-V depuis sa création, y compris Hyper-V dans Windows
Server 2016. Le planificateur classique fournit un modèle de planification en tourniquet
préemptif et équitable pour les processeurs virtuels invités.
Le type de planificateur classique est le plus approprié pour les utilisations Hyper-V
traditionnelles, telles que les clouds privés, les fournisseurs d’hébergement, etc. Les
caractéristiques de performances du type de planificateur classique sont optimisées
pour prendre en charge un large éventail de scénarios de virtualisation, tels que :
Sur-abonnement des adresses IP aux adresses IP.

Exécution de nombreuses machines virtuelles et charges de travail hétérogènes en
même temps.
Exécution de machines virtuelles à grande échelle hautes performances.
Prise en charge de l’ensemble de fonctionnalités complet d’Hyper-V sans
restrictions et autres scénarios.
Le planificateur de cœurs
Le planificateur de cœurs de l’hyperviseur est une alternative à la logique du
planificateur classique, introduite dans Windows Server 2016 et Windows 10
version 1607. Le planificateur principal offre une limite de sécurité forte pour l’isolation
des charges de travail invitées. Elle réduit également la variabilité des performances
pour les charges de travail à l’intérieur des machines virtuelles s’exécutant sur un hôte
de virtualisation compatible avec SMT. Le planificateur principal prend en charge
l’exécution de machines virtuelles SMT et non-SMT en même temps sur le même hôte
de virtualisation compatible avec SMT.
Planificateur principal :
Utilise la topologie SMT de l’hôte de virtualisation.

Vous pouvez éventuellement exposer des paires SMT aux machines virtuelles
invitées.
Planifie des groupes de processeurs virtuels invités de la même machine virtuelle
sur des groupes de processeurs logiques SMT.
Ce travail se produit symétriquement. Si les adresses LPS se trouvent en groupes de

deux, les adresses virtuelles sont planifiées en groupes de deux et un cœur n’est jamais
partagé entre les machines virtuelles. Lorsque vous planifiez le VP pour une machine
virtuelle sans SMT activé, ce VP consomme l’intégralité du cœur lorsqu’il s’exécute. Le
résultat global du planificateur de cœurs est que :
Cela créé une limite de sécurité forte qui permet d’isoler des charges de travail
invitées. Les processeurs virtuels invités peuvent uniquement être exécutés sur des
paires de cœurs physiques sous-jacentes, ce qui réduit la vulnérabilité aux attaques
d’enregistrement de canal latéral.
Elle réduit la variabilité du débit.
Elle peut potentiellement réduire les performances. Si un seul processeur virtuel
d’un groupe peut s’exécuter, seul un des flux d’instructions dans le cœur démarre
alors que l’autre reste inactif.
Le système d’exploitation et les applications s’exécutant dans la machine virtuelle
invitée peuvent utiliser des interfaces de comportement et de programmation SMT
(API) pour contrôler et distribuer le travail entre les threads SMT, comme ils le
feraient dans une machine physique.
À compter de Windows Server 2019, Hyper-V utilise le planificateur principal par défaut.
Dans les versions antérieures comme Windows Server 2016, le planificateur était
facultatif et le planificateur classique est l’option par défaut.
Comportement du planificateur de cœurs avec SMT désactivé sur

l’hôte
Dans certains cas, vous pouvez configurer l’hyperviseur pour utiliser le type de
planificateur principal, mais la fonctionnalité SMT est désactivée ou n’est pas présente
sur l’hôte de virtualisation. Dans ces cas, Hyper-V utilise le planificateur classique
indépendamment du paramètre de type du planificateur d’hyperviseur.
Le planificateur racine
Le planificateur racine est arrivé avec Windows 10, version 1803. Lorsque vous activez le
type de planificateur racine, l’hyperviseur donne à la partition racine le contrôle de la
planification du travail. Le planificateur NT dans l’instance de système d’exploitation de
la partition racine gère tous les aspects de la planification des travaux sur les
processeurs logiques du système.
Le planificateur racine répond aux exigences uniques à la prise en charge d’une partition
utilitaire et pour fournir une isolation forte des charges de travail, comme utilisé avec
Windows Defender Application Guard (WDAG). Dans ce scénario, laisser les
responsabilités de la planification au système d’exploitation racine offre plusieurs
avantages :
Vous pouvez utiliser des contrôles de ressources processeur applicables aux

scénarios de conteneur avec la partition de l’utilitaire, ce qui simplifie la gestion et
le déploiement.
Le planificateur de système d’exploitation racine peut facilement collecter des
métriques sur l’utilisation du processeur de charge de travail à l’intérieur du
conteneur. Il peut utiliser ces données comme entrée dans la même stratégie de
planification applicable à toutes les autres charges de travail du système.
Ces mêmes métriques aident également le travail d’attribut effectué dans un
conteneur d’application au système hôte. Le suivi de ces métriques est plus difficile
avec les charges de travail de machine virtuelle traditionnelles, où certains
fonctionnent pour le compte de toutes les machines virtuelles en cours d’exécution
dans la partition racine.
Utilisation du planificateur racine sur les systèmes clients
À partir de Windows 10 version 1803, le planificateur racine est utilisé par défaut
uniquement sur les systèmes clients, à savoir :
Vous pouvez activer l’hyperviseur pour prendre en charge la sécurité basée sur la
virtualisation et l’isolation des charges de travail WDAG.
Il est important d’exploiter correctement les systèmes futurs avec des architectures
principales hétérogènes.
Cette configuration du planificateur de l’hyperviseur est la seule prise en charge pour les
systèmes clients. Les administrateurs ne doivent pas tenter de remplacer le type de
planificateur d’hyperviseur par défaut sur les systèmes clients Windows.
Contrôles des ressources processeur de machine virtuelle et le

planificateur racine
Les contrôles de ressources de processeur de machines virtuelles fournis par Hyper-V ne

sont pas pris en charge lorsque vous activez le planificateur racine d’hyperviseur. La
logique du planificateur du système d’exploitation racine gère les ressources d’hôte sur
une base globale et ne gère pas les ressources invitées d’une seule machine virtuelle.
Les contrôles des ressources du processeur d’Hyper-V par machine virtuelle, comme les
limites, les pondérations et les réserves, peuvent être uniquement appliqués lorsque
l’hyperviseur contrôle directement la planification des processeurs virtuels, par exemple
avec les types de planificateurs classiques et de cœurs.
Utilisation du planificateur racine sur les systèmes serveur

Nous vous déconseillons d’utiliser le planificateur racine avec Hyper-V sur les serveurs.
Ses caractéristiques de performances n’ont pas encore été entièrement caractérisées et
ajustées pour prendre en charge le large éventail de charges de travail typiques de
nombreux déploiements de virtualisation de serveur.
Activer SMT dans les machines virtuelles

invitées
Une fois que vous avez configuré l’hyperviseur de l’hôte de virtualisation pour qu’il
utilise le type de planificateur principal, vous pouvez également configurer les machines
virtuelles invitées pour utiliser SMT. Exposant le fait que les processeurs virtuels sont
hyperthreadés sur une machine virtuelle invitée permet au planificateur dans le système
d’exploitation invité et aux charges de travail s’exécutant sur la machine virtuelle, de
détecter et d’utiliser la topologie SMT dans leur propre planification de travail.
Dans Windows Server 2016, l’outil SMT invité n’est pas configuré par défaut. Un
administrateur hôte Hyper-V doit l’activer explicitement.
À compter de Windows Server 2019, les nouvelles machines virtuelles que vous
créez sur l’hôte héritent par défaut de la topologie SMT de l’hôte. Par exemple, une
machine virtuelle 9.0 que vous créez sur un hôte avec deux threads SMT par cœur
disposera également de deux threads SMT par cœur.
Vous devez utiliser PowerShell pour activer SMT dans une machine virtuelle invitée.
Aucune interface utilisateur n’est fournie dans le Gestionnaire Hyper-V. Pour activer SMT
dans une machine virtuelle invitée :
1. Ouvrez une fenêtre PowerShell à l’aide d’un compte membre du groupe

Administrateurs Hyper-V ou équivalent.
2. Exécutez Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <n> , où <n>
correspond au nombre de threads SMT par cœur que la machine virtuelle invitée
voit. <n> = 0 définit la valeur HwThreadCountPerCore pour qu’elle corresponde au
nombre de threads SMT de l’hôte par valeur de base.
７ Notes
Dans Windows Server 2019 et ses versions ultérieures, vous pouvez définir
HwThreadCountPerCore = 0 au lieu de mettre en correspondance le nombre de
threads SMT hôte.
La capture d’écran suivante montre les informations système extraites du système

d’exploitation invité s’exécutant dans une machine virtuelle. Il existe deux processeurs
virtuels et SMT activés. Le système d’exploitation invité détecte deux processeurs
logiques appartenant au même cœur.
Configurer le type de planificateur
d’hyperviseur sur Windows Server 2016 Hyper-
V
Hyper-V dans Windows Server 2016 utilise par défaut le modèle de planificateur de
l’hyperviseur classique. Vous pouvez éventuellement configurer l’hyperviseur pour
utiliser le planificateur principal. Le planificateur principal augmente la sécurité en
limitant l’exécution des adresses IP virtuelles invitées sur des paires SMT physiques
correspondantes. Cette configuration prend en charge l’utilisation de machines virtuelles
avec la planification SMT pour leurs adresses IP invitées.
７ Notes
Nous recommandons à tous les clients exécutant Windows Server 2016 Hyper-V de
sélectionner le planificateur principal pour vous assurer que leurs hôtes de
virtualisation sont protégés de manière optimale contre les machines virtuelles
invitées potentiellement malveillantes.
Hyper-V dans Windows Server 2019 utilise par

défaut le planificateur de cœurs.
Pour garantir que les hôtes Hyper-V sont déployés dans la configuration de sécurité
optimale, Windows Server 2019 Hyper-V utilise désormais le modèle de planificateur
d’hyperviseur principal par défaut. L’administrateur hôte peut éventuellement configurer
l’hôte pour utiliser le planificateur classique hérité. Avant de remplacer les paramètres
par défaut, les administrateurs doivent lire, comprendre et prendre en compte les
impacts que chaque type de planificateur a sur la sécurité et les performances des hôtes
de virtualisation. Pour plus d’informations, consultez À propos de la sélection du type de
planificateur d’hyperviseur Hyper-V.
Sélectionner le type de planificateur

d’hyperviseur sur Windows Server
La configuration du planificateur d’hyperviseur est contrôlée par l’entrée BCD
hypervisorschedulertype .
Pour sélectionner un type de planificateur :
1. Ouvrez une invite de commandes avec des privilèges administrateur.

2. Entrez bcdedit /set hypervisorschedulertype type , où type est l’une des options
suivantes :
Classic
Core
Root
Vous devez redémarrer le système pour que toutes vos modifications au type de
planificateur d’hyperviseur soient prises en compte.
７ Notes
Le planificateur racine d’hyperviseur n’est pas pris en charge sur Windows Server
Hyper-V pour l’instant. Les administrateurs Hyper-V ne doivent pas tenter de
configurer le planificateur racine à utiliser avec des scénarios de virtualisation de
serveur.
Déterminer le type de planificateur actuel

Vous pouvez déterminer quel type de planificateur d’hyperviseur utilise actuellement
Hyper-V en examinant le journal système de l’observateur d’événements. Vous pouvez
voir l’ID d’événement de lancement d’hyperviseur le plus récent 2, qui signale le type de
planificateur d’hyperviseur configuré lors du lancement de l’hyperviseur. Vous pouvez
obtenir les événements de lancement d’hyperviseur à partir de l’Observateur
d’événements Windows ou dans PowerShell.
L’événement de lancement de l’hyperviseur avec l’ID 2 indique le type de planificateur
de l’hyperviseur, où :
1 = Planificateur classique, SMT désactivé

2 = Planificateur classique
3 = Planificateur de cœurs
4 = Planificateur racine
Interroger l’événement de lancement du type de
planificateur hyperviseur Hyper-V à l’aide de PowerShell
Pour interroger l’événement de l’hyperviseur avec l’ID 2 en utilisant PowerShell, exécutez
les commandes suivantes à partir d’une invite de commandes PowerShell :
PowerShell
Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-

Hypervisor"; ID=2} -MaxEvents 1
À propos de la sélection du type de
planificateur d’hyperviseur Hyper-V
Article • 11/04/2023
Windows Server, version 1709, Windows Server, version 1803
Ce document décrit les modifications importantes apportées à la valeur par défaut

d’Hyper-V et l’utilisation recommandée des types de planificateurs d’hyperviseur. Ces
changements ont un impact sur la sécurité du système et les performances de
virtualisation. Les administrateurs de l’hôte de virtualisation doivent examiner et
comprendre les modifications et les implications décrites dans ce document, et évaluer
soigneusement les impacts, les conseils de déploiement suggérés et les facteurs de
risque impliqués pour mieux comprendre comment déployer et gérer les hôtes Hyper-V
face à l’évolution rapide du paysage de la sécurité.
） Important
Les vulnérabilités de sécurité de canal latéral actuellement connues dans plusieurs

architectures de processeur peuvent être exploitées par une machine virtuelle
invitée malveillante via le comportement de planification du type de planificateur
classique d’hyperviseur hérité lors de l’exécution sur des hôtes avec le
multithreading simultané (SMT) activé. Si elle est correctement exploitée, une
charge de travail malveillante peut observer des données en dehors de sa limite de
partition. Cette classe d’attaques peut être atténuée en configurant l’hyperviseur
Hyper-V pour utiliser le type de planificateur de cœurs de l’hyperviseur et en
reconfigurant les machines virtuelles invitées. Avec le planificateur de cœurs,
l’hyperviseur empêche les machines virtuelles d’une machine virtuelle invitée de
s’exécuter sur le même cœur de processeur physique, ce qui restreint la capacité de
la machine virtuelle à accéder aux données aux limites du cœur physique sur lequel
elle s’exécute. Il s’agit d’une atténuation très efficace contre ces attaques par canal
latéral, en empêchant la machine virtuelle d’observer les artefacts d’autres
partitions, qu’il s’agisse de la partition racine ou d’une autre partition invitée. Par
conséquent, Microsoft modifie les paramètres de configuration par défaut et
recommandés pour les hôtes de virtualisation et les machines virtuelles invitées.
Contexte
À compter de Windows Server 2016, Hyper-V prend en charge plusieurs méthodes de
planification et de gestion des processeurs virtuels, appelées types de planificateurs
d’hyperviseur. Vous trouverez une description détaillée de tous les types de
planificateurs d’hyperviseur dans Compréhension et utilisation des types de planificateur
d’hyperviseur Hyper-V.
７ Notes
Les nouveaux types de planificateurs d’hyperviseurs ont été introduits pour la

première fois avec Windows Server 2016 et ne sont pas disponibles dans les
versions antérieures. Toutes les versions d’Hyper-V antérieures à Windows
Server 2016 prennent uniquement en charge le planificateur classique. La prise en
charge du planificateur de cœurs n’a été publiée que récemment.
À propos des types de planificateur

d’hyperviseur
Cet article se concentre spécifiquement sur l’utilisation du nouveau type de planificateur
de cœurs d’hyperviseur par rapport au planificateur « classique » hérité, et sur la façon
dont ces types de planificateurs se croisent avec l’utilisation du multithreading
symétrique, ou SMT. Il est important de comprendre les différences entre les
planificateurs de cœurs et classiques, ainsi que la façon dont chacun place le travail à
partir des machines virtuelles invitées sur les processeurs système sous-jacents.
Planificateur classique
Le planificateur classique fait référence à la méthode de tourniquet (round robin)
équitable de planification du travail sur les processeurs virtuels (VP) dans le système, y
compris les VP racines ainsi que les VP appartenant à des machines virtuelles invitées. Le
planificateur classique est le type de planificateur par défaut utilisé sur toutes les
versions d’Hyper-V (jusqu’à Windows Server 2019, comme décrit ici). Les caractéristiques
de performances du planificateur classique sont bien comprises, et le planificateur
classique prend en charge de manière efficace le surabonnement des charges de travail,
c’est-à-dire le surabonnement du ratio VP/LP de l’hôte dans une marge raisonnable
(selon les types de charges de travail virtualisées, l’utilisation globale des ressources,
etc.).
Lors de l’exécution sur un hôte de virtualisation avec SMT activé, le planificateur

classique planifie les machines virtuelles invitées à partir de n’importe quelle machine
virtuelle sur chaque thread SMT appartenant à un cœur indépendamment. Par
conséquent, différentes machines virtuelles peuvent s’exécuter sur le même cœur en
même temps (une machine virtuelle s’exécute sur un thread d’un cœur tandis qu’une
autre machine virtuelle s’exécute sur l’autre thread).
Planificateur de cœurs
Le planificateur de cœurs tire parti des propriétés de SMT pour fournir une isolation des
charges de travail invitées, ce qui a un impact à la fois sur la sécurité et les performances
du système. Le planificateur de cœurs garantit que les machines virtuelles d’une
machine virtuelle sont planifiées sur des threads SMT frères. Cela s’effectue
symétriquement, de sorte que si les fournisseurs de services se trouvent dans des
groupes de deux, les machines virtuelles sont planifiées en groupes de deux, et un cœur
de processeur système n’est jamais partagé entre les machines virtuelles.
En planifiant des adresses virtuelles invitées sur des paires SMT sous-jacentes, le
planificateur de cœurs offre une limite de sécurité forte pour l’isolation des charges de
travail, et peut également être utilisé pour réduire la variabilité des performances pour
les charges de travail sensibles à la latence.
Notez que lorsque le VP est planifié pour une machine virtuelle sans SMT activé, ce VP
consomme l’intégralité du cœur lorsqu’il s’exécute, et le thread SMT frère du cœur est
laissé inactif. Cela est nécessaire pour fournir une isolation correcte de la charge de
travail, mais cela a un impact sur les performances globales du système, d’autant plus
que les fournisseurs de services système deviennent surabonnés, c’est-à-dire lorsque le
ratio VP:LP total dépasse 1:1. Par conséquent, l’exécution de machines virtuelles invitées
configurées sans plusieurs threads par cœur n’est pas optimale.
Avantages de l’utilisation du planificateur de cœurs

Le planificateur de cœurs offre les avantages suivants :
Limite de sécurité forte pour l’isolation des charges de travail invitées : les
machines virtuelles invitées sont contraintes de s’exécuter sur des paires de cœurs
physiques sous-jacentes, ce qui réduit la vulnérabilité aux attaques d’espionnage
par canal latéral.
Variabilité réduite de la charge de travail : la variabilité du débit de la charge de

travail invité est considérablement réduite, ce qui offre une plus grande cohérence
de la charge de travail.
Utilisation de SMT dans les machines virtuelles invitées : le système d’exploitation
et les applications s’exécutant sur la machine virtuelle invitée peuvent utiliser le
comportement et les interfaces de programmation (API) SMT pour contrôler et
distribuer le travail entre les threads SMT, comme ils le feraient lors d’une
exécution non virtualisée.
Le planificateur de cœurs est actuellement utilisé sur les hôtes de virtualisation Azure, en
particulier pour tirer parti de la limite de sécurité forte et de la faible variabilité des
charges de travail. Microsoft estime que le type de planificateur de cœurs doit être et
continuera d’être le type de planification d’hyperviseur par défaut pour la majorité des
scénarios de virtualisation. Par conséquent, pour garantir la sécurité de nos clients par
défaut, Microsoft apporte cette modification pour Windows Server 2019 maintenant.
Impact sur les performances du planificateur de cœurs

sur les charges de travail invitées
Bien qu’il soit nécessaire d’atténuer efficacement certaines classes de vulnérabilités, le
planificateur de cœurs peut également réduire les performances. Les clients pourraient
observer une différence dans les caractéristiques de performances de leurs machines
virtuelles et les impacts sur la capacité de charge de travail globale de leurs hôtes de
virtualisation. Dans les cas où le planificateur de cœurs doit exécuter un VP non SMT, un
seul des flux d’instructions dans le cœur logique sous-jacent s’exécute, tandis que l’autre
doit être laissé inactif. Cela limite la capacité totale de l’hôte pour les charges de travail
invitées.
Ces impacts sur les performances peuvent être réduits en suivant les instructions de
déploiement de ce document. Les administrateurs hôtes doivent examiner
attentivement leurs scénarios de déploiement de virtualisation spécifiques et équilibrer
leur tolérance pour les risques de sécurité et la nécessité d’une densité de charge de
travail maximale, le risque de consolidation excessive des hôtes de virtualisation, etc.
Modifications apportées aux configurations par

défaut et recommandées pour Windows
Server 2016 et Windows Server 2019
Le déploiement d’hôtes Hyper-V avec une posture de sécurité maximale nécessite
l’utilisation du type de planificateur de cœurs de l’hyperviseur. Pour garantir la sécurité
de nos clients par défaut, Microsoft modifie les paramètres par défaut et recommandés
suivants.
７ Notes
Bien que la prise en charge interne de l’hyperviseur pour les types de planificateurs
ait été incluse dans la version initiale de Windows Server 2016, Windows
Server 1709 et Windows Server 1803, des mises à jour sont nécessaires pour
accéder au contrôle de configuration qui permet de sélectionner le type de
planificateur d’hyperviseur. Pour plus d’informations sur ces mises à jour, consultez
Compréhension et utilisation des types de planificateur d’hyperviseur Hyper-V.
Modifications de l’hôte de virtualisation

L’hyperviseur utilise le planificateur de cœurs par défaut à compter de Windows
Server 2019.
Microsoft recommande la configuration du planificateur de cœurs sur Windows

Server 2016. Le type de planificateur de cœurs de l’hyperviseur est pris en charge
dans Windows Server 2016, mais le planificateur classique est utilisé par défaut. Le
planificateur de cœurs est facultatif et doit être explicitement activé par
l’administrateur hôte Hyper-V.
Modifications de configuration de la machine virtuelle

Sur Windows Server 2019, les nouvelles machines virtuelles créées à l’aide de la
machine virtuelle version 9.0 par défaut héritent automatiquement des propriétés
SMT (activées ou désactivées) de l’hôte de virtualisation. Autrement dit, si SMT est
activé sur l’hôte physique, les machines virtuelles nouvellement créées auront
également SMT activé et hériteront de la topologie SMT de l’hôte par défaut, la
machine virtuelle ayant le même nombre de threads matériels par cœur que le
système sous-jacent. Cela se reflète dans la configuration de la machine virtuelle
avec HwThreadCountPerCore = 0, où 0 indique que la machine virtuelle doit
hériter des paramètres SMT de l’hôte.
Les machines virtuelles existantes version 8.2 ou antérieure conservent leur

paramètre de processeur de machine virtuelle d’origine pour
HwThreadCountPerCore, et la valeur par défaut pour les machines virtuelles
invitées version 8.2 est HwThreadCountPerCore = 1. Lorsque ces invités s’exécutent
sur un hôte Windows Server 2019, ils sont traités comme suit :
1. Si la machine virtuelle a un nombre de VP inférieur ou égal au nombre de

cœurs LP, la machine virtuelle est traitée comme une machine virtuelle non
SMT par le planificateur de cœurs. Lorsque le VP invité s’exécute sur un seul
thread SMT, le thread SMT frère du cœur est inactif. Cela n’est pas optimal et
entraîne une réduction globale des performances.
2. Si la machine virtuelle a plus de VP que de cœurs LP, la machine virtuelle est

traitée comme une machine virtuelle SMT par le planificateur de cœurs.
Toutefois, la machine virtuelle n’observe pas d’autres indications indiquant
qu’il s’agit d’une machine virtuelle SMT. Par exemple, l’utilisation de
l’instruction CPUID ou des API Windows pour interroger la topologie du
processeur par le système d’exploitation ou les applications n’indique pas
que SMT est activé.
Lorsqu’une machine virtuelle existante est explicitement mise à jour d’une version
antérieure vers la version 9.0 via l’opération Update-VM, la machine virtuelle
conserve sa valeur actuelle pour HwThreadCountPerCore. SMT n’est pas activé de
force sur la machine virtuelle.
Sur Windows Server 2016, Microsoft recommande d’activer SMT pour les machines
virtuelles invitées. Par défaut, les machines virtuelles créées sur Windows
Server 2016 ont SMT désactivé, c’est-à-dire que HwThreadCountPerCore a la
valeur 1, sauf modification explicite.
７ Notes
Windows Server 2016 ne prend pas en charge la définition de

HwThreadCountPerCore sur 0.
Gestion de la configuration SMT de machine virtuelle

La configuration SMT de la machine virtuelle invitée est définie pour chaque machine
virtuelle. L’administrateur hôte peut inspecter et configurer la configuration SMT d’une
machine virtuelle pour choisir parmi les options suivantes :
1. Configurer des machines virtuelles pour qu’elles s’exécutent comme machines

SMT, en héritant automatiquement de la topologie SMT hôte
2. Configurer des machines virtuelles pour qu’elles s’exécutent en tant que machines
non SMT
La configuration de SMT pour une machine virtuelle s’affiche dans les volets Résumé de
la console du Gestionnaire Hyper-V. La configuration des paramètres SMT d’une
machine virtuelle peut être effectuée à l’aide des paramètres de machine virtuelle ou de
PowerShell.
Configuration des paramètres SMT de machine virtuelle à l’aide de
PowerShell
Pour configurer les paramètres SMT d’une machine virtuelle invitée, ouvrez une fenêtre
PowerShell avec des autorisations suffisantes, puis tapez :
PowerShell
Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore <0, 1, 2>
Où :
0 = Hériter de la topologie SMT de l’hôte (ce paramètre de

HwThreadCountPerCore=0 n’est pas pris en charge sur Windows Server 2016)
1 = Non SMT
Valeurs > 1 = le nombre souhaité de threads SMT par cœur. Ne peut pas dépasser
le nombre de threads SMT physiques par cœur.
Pour lire les paramètres SMT d’une machine virtuelle invitée, ouvrez une fenêtre
PowerShell avec des autorisations suffisantes, puis tapez :
PowerShell
(Get-VMProcessor -VMName <VMName>).HwThreadCountPerCore
Notez que les machines virtuelles invitées configurées avec HwThreadCountPerCore = 0

indiquent que SMT sera activé pour l’invité et exposera le même nombre de threads
SMT à l’invité que sur l’hôte de virtualisation sous-jacent, généralement 2.
Les machines virtuelles invitées pourraient observer des

modifications de topologie du processeur dans les
scénarios de mobilité des machines virtuelles
Le système d’exploitation et les applications d’une machine virtuelle pourraient observer
des modifications apportées aux paramètres de l’hôte et de la machine virtuelle avant et
après les événements de cycle de vie de la machine virtuelle, comme la migration
dynamique ou les opérations d’enregistrement et de restauration. Lors d’une opération
dans laquelle l’état de la machine virtuelle est enregistré et restauré, le paramètre
HwThreadCountPerCore de la machine virtuelle et la valeur réalisée (c’est-à-dire la
combinaison calculée du paramètre de la machine virtuelle et de la configuration de
l’hôte source) sont migrés. La machine virtuelle continue de s’exécuter avec ces
paramètres sur l’hôte de destination. Au moment où la machine virtuelle est arrêtée et
redémarrée, il est possible que la valeur réalisée observée par la machine virtuelle
change. Cela devrait être bénin, car les logiciels de la couche système d’exploitation et
application doivent rechercher des informations de topologie du processeur dans le
cadre de leurs flux de code de démarrage et d’initialisation normaux. Toutefois, étant
donné que ces séquences d’initialisation au démarrage sont ignorées pendant les
opérations de migration dynamique ou d’enregistrement/restauration, les machines
virtuelles qui subissent ces transitions d’état peuvent observer la valeur réalisée calculée
à l’origine jusqu’à ce qu’elles soient arrêtées et redémarrées.
Alertes concernant les configurations de machine

virtuelle non optimales
Les machines virtuelles configurées avec plus de VP qu’il y a de cœurs physiques sur
l’hôte entraînent une configuration non optimale. Le planificateur de l’hyperviseur traite
ces machines virtuelles comme si elles prenaient en charge SMT. Toutefois, le système
d’exploitation et les logiciels d’application dans la machine virtuelle se verront présenter
une topologie d’UC indiquant que SMT est désactivé. Lorsque cette condition est
détectée, le processus Worker Hyper-V enregistre un événement sur l’hôte de
virtualisation, ce qui avertit l’administrateur hôte que la configuration de la machine
virtuelle n’est pas optimale et recommande d’activer SMT pour la machine virtuelle.
Comment identifier les machines virtuelles configurées de manière

non optimale
Vous pouvez identifier les machines virtuelles non SMT en examinant le journal système
dans l’observateur d’événements pour l’ID d’événement 3498 du processus Worker
Hyper-V, qui sera déclenché pour une machine virtuelle chaque fois que le nombre de
VP dans la machine virtuelle est supérieur au nombre de cœurs physiques. Les
événements de processus Worker peuvent être obtenus à partir de l’observateur
d’événements ou via PowerShell.
Interrogation de l’événement de machine virtuelle du processus

Worker Hyper-V à l’aide de PowerShell
Pour interroger l’ID d’événement de processus Worker Hyper-V 3498 à l’aide de
PowerShell, entrez les commandes suivantes à partir d’une invite PowerShell.
PowerShell
Get-WinEvent -FilterHashTable @{ProviderName="Microsoft-Windows-Hyper-V-
Worker"; ID=3498}
Impacts de la configuration SMT invitée sur l’utilisation

des éclairages d’hyperviseur pour les systèmes
d’exploitation invités
L’hyperviseur Microsoft offre plusieurs éclairages, ou conseils, que le système
d’exploitation s’exécutant dans une machine virtuelle invitée peut interroger et utiliser
pour déclencher des optimisations, comme celles qui peuvent améliorer les
performances ou la gestion de diverses conditions lors de l’exécution virtualisée. Un
éclairage récemment introduit concerne la gestion de la planification des processeurs
virtuels et l’utilisation des atténuations du système d’exploitation pour les attaques par
canal latéral qui exploitent SMT.
７ Notes
Microsoft recommande aux administrateurs hôtes d’activer SMT pour les machines
virtuelles invitées afin d’optimiser les performances des charges de travail.
Les détails de cet éclairage invité sont fournis ci-dessous, mais le point à retenir pour les
administrateurs de l’hôte de virtualisation est que les machines virtuelles doivent avoir
HwThreadCountPerCore configuré pour correspondre à la configuration SMT physique
de l’hôte. Cela permet à l’hyperviseur de signaler qu’il n’y a pas de partage de cœur non
architectural. Par conséquent, tout système d’exploitation invité prenant en charge les
optimisations qui nécessitent l’illumination peut être activé. Sur Windows Server 2019,
créez des machines virtuelles et conservez la valeur par défaut HwThreadCountPerCore
(0). Les machines virtuelles plus anciennes migrées à partir d’hôtes Windows Server 2016
peuvent être mises à jour vers la version de configuration de Windows Server 2019.
Après cela, Microsoft recommande de définir HwThreadCountPerCore = 0. Sur Windows
Server 2016, Microsoft recommande de définir HwThreadCountPerCore pour qu’il
corresponde à la configuration de l’hôte (généralement 2).
Détails de l’éclairage NoNonArchitecturalCoreSharing

À partir de Windows Server 2016, l’hyperviseur définit un nouvel éclairage pour décrire
sa gestion de la planification et du placement de VP sur le système d’exploitation invité.
Cet éclairage est défini dans la Spécification fonctionnelle générale de l’hyperviseur
v5.0c.
La feuille CPUID synthétique d’hyperviseur
CPUID.0x40000004.EAX:18[NoNonArchitecturalCoreSharing = 1] indique qu’un
processeur virtuel ne partagera jamais un cœur physique avec un autre processeur
virtuel, à l’exception des processeurs virtuels qui sont signalés en tant que threads SMT
frères. Par exemple, un VP invité ne s’exécutera jamais sur un thread SMT parallèlement
à un VP racine s’exécutant simultanément sur un thread SMT frère sur le même cœur de
processeur. Cette condition n’est possible que lors de l’exécution virtualisée, et
représente donc un comportement SMT non architectural qui a également de sérieuses
implications en matière de sécurité. Le système d’exploitation invité peut utiliser
NoNonArchitecturalCoreSharing = 1 comme indication qu’il est sûr d’activer les
optimisations, ce qui peut l’aider à éviter la surcharge de performances liée à la
définition de STIBP.
Dans certaines configurations, l’hyperviseur n’indique pas

NoNonArchitecturalCoreSharing = 1. Par exemple, si SMT est activé sur un hôte et qu’il
est configuré pour utiliser le planificateur classique de l’hyperviseur,
NoNonArchitecturalCoreSharing aura la valeur 0. Cela peut empêcher les invités éclairés
d’activer certaines optimisations. Par conséquent, Microsoft recommande aux
administrateurs hôtes qui utilisent SMT de s’appuyer sur le planificateur de cœurs de
l’hyperviseur et de s’assurer que les machines virtuelles sont configurées pour hériter de
leur configuration SMT de l’hôte afin de garantir des performances de charge de travail
optimales.
Résumé
Le paysage des menaces de sécurité continue d’évoluer. Pour garantir la sécurité de nos
clients par défaut, Microsoft modifie la configuration par défaut de l’hyperviseur et des
machines virtuelles à partir de Windows Server 2019 Hyper-V, et fournit des conseils et
des recommandations à jour aux clients exécutant Windows Server 2016 Hyper-V. Les
administrateurs de l’hôte de virtualisation doivent :
Lire et comprendre les conseils fournis dans ce document
Évaluer et ajuster soigneusement leurs déploiements de virtualisation pour

s’assurer qu’ils répondent aux objectifs de sécurité, de performances, de densité de
virtualisation et de réactivité de charge de travail pour leurs besoins uniques
Envisager de configurer les hôtes Hyper-V Windows Server 2016 existants pour
tirer parti des avantages de sécurité renforcée offerts par le planificateur de cœurs
de l’hyperviseur
Mettre à jour les machines virtuelles non SMT existantes pour réduire les impacts
sur les performances des contraintes de planification imposées par l’isolation de
VP qui corrigent les vulnérabilités de sécurité matérielle
Gérer les services d’intégration Hyper-V
Article • 14/04/2023
Windows 11. Windows 10
Les services d’intégration Hyper-V améliorent les performances des machines virtuelles
et fournissent des fonctionnalités pratiques en tirant parti de la communication
bidirectionnelle avec l’hôte Hyper-V. Bon nombre de ces services sont pratiques, comme
la copie de fichiers invités, tandis que d’autres sont importants pour les fonctionnalités
de la machine virtuelle, comme les pilotes de périphérique synthétiques. Cet ensemble
de services et de pilotes est parfois appelé composants d’intégration. Vous pouvez
contrôler si les services de commodité individuels fonctionnent ou non pour une
machine virtuelle donnée. Les composants du pilote ne sont pas destinés à être pris en
charge manuellement.
Pour plus d’informations sur chaque service d’intégration, consultez Services

d’integration Hyper-V.
） Important
Chaque service que vous souhaitez utiliser doit être activé à la fois dans l’hôte et
l’invité pour fonctionner. Tous les services d’intégration, à l’exception de l’interface
de service invité Hyper-V , sont activés par défaut sur les systèmes d’exploitation
invités Windows. Les services peuvent être activés et désactivés individuellement.
Les sections suivantes vous montrent comment.
Activer ou désactiver un service d’intégration à

l’aide du Gestionnaire Hyper-V
1. Dans le volet central, cliquez avec le bouton droit sur la machine virtuelle et
sélectionnez Paramètres.
2. Dans le volet gauche de la fenêtre Paramètres, sous Gestion, sélectionnez Services

d’integration.
Le volet Services d’integration répertorie tous les services d’intégration disponibles sur
l’hôte Hyper-V, et indique si l’hôte a activé la machine virtuelle pour les utiliser.
Activer ou désactiver un service d’intégration à l’aide de
PowerShell
Pour ce faire dans PowerShell, utilisez Enable-VMIntegrationService et Disable-
VMIntegrationService.
Les exemples suivants illustrent l’activation et la désactivation du service d’intégration

de copie de fichiers invités pour une machine virtuelle nommée DemoVM.
1. Obtenez une liste des services d’intégration en cours d’exécution :
PowerShell
Get-VMIntegrationService -VMName "DemoVM"
2. La sortie doit ressembler à ceci :
PowerShell
VMName Name Enabled PrimaryStatusDescription

SecondaryStatusDescription
------ ---- ------- ------------------------ --
------------------------
DemoVM Guest Service Interface False OK
DemoVM Heartbeat True OK OK
DemoVM Key-Value Pair Exchange True OK
DemoVM Shutdown True OK
DemoVM Time Synchronization True OK
DemoVM VSS True OK
3. Activez l’interface de services invité :
PowerShell
Enable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service

Interface"
4. Vérifiez que l’interface du service invité est activée :
PowerShell
Get-VMIntegrationService -VMName "DemoVM"
5. Désctivez l’interface de services invité :
PowerShell
Disable-VMIntegrationService -VMName "DemoVM" -Name "Guest Service
Interface"
Vérification de la version des services

d’intégration invité
Certaines fonctionnalités peuvent ne pas fonctionner correctement ou du tout si les
services d’intégration invité ne sont pas à jour. Pour obtenir les informations de version
de Windows, connectez-vous au système d’exploitation invité, ouvrez une invite de
commandes et exécutez cette commande :
REG QUERY "HKLM\Software\Microsoft\Virtual Machine\Auto" /v

IntegrationServicesVersion
Les systèmes d’exploitation invités antérieurs n’auront pas tous les services disponibles.
Par exemple, les invités Windows Server 2008 R2 ne peuvent pas avoir l’interface du
service invité Hyper-V.
Démarrer et arrêter un service d’intégration à

partir d’un invité Windows
Pour qu’un service d’intégration soit entièrement fonctionnel, son service correspondant
doit être exécuté au sein de l’invité en plus d’être activé sur l’hôte. Dans les invités
Windows, chaque service d’intégration est répertorié en tant que service Windows
standard. Vous pouvez utiliser l’applet Services dans Panneau de configuration ou
PowerShell pour arrêter et démarrer ces services.
） Important
La désactivation des services d’intégration peut avoir un impact considérable sur la

capacité de l’hôte à gérer votre machine virtuelle. Pour fonctionner correctement,
chaque service d’intégration que vous souhaitez utiliser doit être activé à la fois sur
l’hôte et l’invité. Il est recommandé de contrôler les services d’intégration à partir
d’Hyper-V uniquement en suivant les instructions ci-dessus. Le service
correspondant dans le système d’exploitation invité s’arrête ou démarre
automatiquement lorsque vous modifiez son état dans Hyper-V. Si vous démarrez
un service dans le système d’exploitation invité, mais qu’il est désactivé dans
Hyper-V, le service s’arrête. Si vous arrêtez un service dans le système d’exploitation
invité activé dans Hyper-V, Hyper-V le redémarrera. Si vous désactivez le service
dans l’invité, Hyper-V ne pourra pas le démarrer.
Utiliser les services Windows pour démarrer ou arrêter un

service d’intégration au sein d’un invité Windows
1. Ouvrez le Gestionnaire de services en exécutant services.msc en tant
qu’administrateur ou en double-cliquant sur l’icône Services dans Panneau de
configuration.
2. Recherchez les services qui commencent par Hyper-V.
3. Cliquez avec le bouton droit sur le service que vous souhaitez démarrer ou arrêter.
Sélectionnez l’action souhaitée.
Utiliser PowerShell pour démarrer ou arrêter un service

d’intégration au sein d’un invité Windows
1. Pour obtenir une liste des services d’intégration, exécutez :
PowerShell
Get-Service -Name vmic* | FT -AutoSize
2. La sortie doit être semblable à ce qui suit :

PowerShell
Status Name DisplayName

------ ---- -----------
Running vmicguestinterface Hyper-V Guest Service Interface
Running vmicheartbeat Hyper-V Heartbeat Service
Running vmickvpexchange Hyper-V Data Exchange Service
Running vmicrdv Hyper-V Remote Desktop Virtualization
Service
Running vmicshutdown Hyper-V Guest Shutdown Service
Running vmictimesync Hyper-V Time Synchronization Service
Stopped vmicvmsession Hyper-V PowerShell Direct Service
Running vmicvss Hyper-V Volume Shadow Copy Requestor
3. Exécutez Start-Service ou Stop-Service. Par exemple, pour désactiver Windows

PowerShell Direct, exécutez :
PowerShell
Stop-Service -Name vmicvmsession
Démarrer et arrêter un service d’intégration à

partir d’un invité Linux
Les services d’intégration Linux sont généralement fournis par le noyau Linux. Le pilote
des services d’intégration Linux est appelé hv_utils.
1. Pour savoir si hv_utils est chargé, utilisez cette commande :
Bash
lsmod | grep hv_utils
Bash
Module Size Used by

hv_utils 20480 0
hv_vmbus 61440 8
hv_balloon,hyperv_keyboard,hv_netvsc,hid_hyperv,hv_utils,hyperv_fb,hv_s
torvsc
3. Pour savoir si les démons requis sont en cours d’exécution, utilisez cette
commande.
Bash
ps -ef | grep hv
Bash
root 236 2 0 Jul11 ? 00:00:00 [hv_vmbus_con]

root 237 2 0 Jul11 ? 00:00:00 [hv_vmbus_ctl]
...
root 252 2 0 Jul11 ? 00:00:00 [hv_vmbus_ctl]
root 1286 1 0 Jul11 ? 00:01:11 /usr/lib/linux-
tools/3.13.0-32-generic/hv_kvp_daemon
root 9333 1 0 Oct12 ? 00:00:00 /usr/lib/linux-
tools/3.13.0-32-generic/hv_kvp_daemon
root 9365 1 0 Oct12 ? 00:00:00 /usr/lib/linux-
tools/3.13.0-32-generic/hv_vss_daemon
user 43774 43755 0 21:20 pts/0 00:00:00 grep --color=auto hv
5. Pour afficher les démons disponibles, exécutez la commande suivante :
Bash
compgen -c hv_
Bash
hv_vss_daemon
hv_get_dhcp_info
hv_get_dns_info
hv_set_ifconfig
hv_kvp_daemon
hv_fcopy_daemon
Les démons de service d’intégration qui peuvent être répertoriés sont les suivants.
S’il en manque, il se peut qu’ils ne soient pas pris en charge sur votre système ou
qu’ils ne soient pas installés. Pour plus d’informations, consultez Machines
virtuelles Linux et FreeBSD prises en charge pour Hyper-V sur Windows.
hv_vss_daemon : ce démon est nécessaire pour créer des sauvegardes

dynamiques de machines virtuelles Linux.
hv_kvp_daemon : ce démon permet de définir et d’interroger des paires clé-
valeur intrinsèques et extrinsèques.
hv_fcopy_daemon : ce démon implémente un service de copie de fichiers
entre l’hôte et l’invité.
Exemples
Ces exemples illustrent l’arrêt et le démarrage du démon KVP, nommé hv_kvp_daemon .
1. Utilisez l’ID de processus (PID) pour arrêter le processus du démon. Pour

rechercher le PID, examinez la deuxième colonne de la sortie ou utilisez pidof . Les
démons Hyper-V s’exécutent en tant que racine, vous avez besoin d’autorisations
racine.
Bash
sudo kill -15 `pidof hv_kvp_daemon`
2. Pour vérifier que tous les processus hv_kvp_daemon ont disparu, exécutez :
Bash
ps -ef | hv
3. Pour redémarrer le démon, exécutez-le en tant que racine :
Bash
sudo hv_kvp_daemon
4. Pour vérifier que le processus hv_kvp_daemon est répertorié avec un nouvel ID de

processus, exécutez :
Bash
ps -ef | hv
Maintenir les services d’intégration à jour

Nous vous recommandons de maintenir les services d’intégration à jour pour obtenir les
meilleures performances et les fonctionnalités les plus récentes pour vos machines
virtuelles. Cela se produit par défaut pour les invités Windows s’ils sont configurés pour
obtenir des mises à jour importantes de Windows Update. Les invités Linux utilisant les
noyaux actuels contiennent des services d’intégration intégrés, mais des mises à jour
facultatives peuvent être disponibles. Vous recevez les derniers composants
d’intégration lorsque vous mettez à jour le noyau. Pour plus d’informations sur les
invités Linux, consultez Machines virtuelles Linux et FreeBSD prises en charge pour
Hyper-V sur Windows.
７ Notes
Le fichier image disque Integration Services (vmguest.iso) n’est pas inclus avec
Hyper-V à partir de Windows Server 2016 et Windows 10, car il n’est plus
nécessaire. Windows Server 2012 et les versions antérieures nécessitent le service
d’intégration Data Exchange. Si le service d’intégration Échange de données ne
peut pas être activé, les services d’intégration pour ces invités sont disponibles à
partir du Centre de téléchargement en tant que fichier cabinet (cab). Les
instructions relatives à l’application d’un cab sont disponibles dans ce billet de blog
Microsoft TechCommunity . Si votre hôte Hyper-V exécute Windows Server 2012
R2 et versions antérieures, consultez la section suivante pour savoir comment
installer ou mettre à jour les services d’intégration.
Installer ou mettre à jour des services

d’intégration pour les hôtes Hyper-V antérieurs
à Windows Server 2016 et Windows 10
７ Notes
Cela n’est pas obligatoire pour Windows Server 2016 et Windows 10 ou versions
ultérieures.
Pour les hôtes Hyper-V antérieurs à Windows Server 2016 et Windows 10, vous devez
installer ou mettre à jour manuellement les services d’intégration dans les systèmes
d’exploitation invités.
Pour installer ou mettre à jour manuellement les services d’intégration :
2. Connectez-vous à la machine virtuelle. Cliquez avec le bouton droit sur la machine

virtuelle, puis sélectionnez Connecter.
3. Dans le menu Action de l’outil Connexion à un ordinateur virtuel, sélectionnez
Insérer le disque d’installation des services d’intégration. Cette action charge le
disque d’installation dans le lecteur de DVD virtuel. Selon le système d’exploitation
invité, vous devrez peut-être démarrer l’installation manuellement à partir de
l’Explorateur de fichiers.
4. Quand l’installation est terminée, les services d’intégration peuvent être utilisés.
Gérer des machines virtuelles Windows
avec PowerShell Direct
Article • 09/03/2023
S’applique à : Windows Server 2022, Windows 10, Windows Server 2016,

Windows Server 2019
PowerShell Direct permet de gérer à distance une machine virtuelle Windows 10,
Windows Server 2016 ou Windows Server 2019 à partir d’un hôte Hyper-V Windows 10,
Windows Server 2016 ou Windows Server 2019. Grâce à PowerShell Direct, vous pouvez
gérer Windows PowerShell dans une machine virtuelle, indépendamment de la
configuration du réseau ou des paramètres de gestion à distance sur l’hôte Hyper-V ou
la machine virtuelle. Pour les administrateurs Hyper-V, cela facilite la génération de
scripts et l’automatisation de la gestion et de la configuration des machines virtuelles.
Vous pouvez exécuter PowerShell Direct de deux manières :
Créer et quitter une session PowerShell Direct à l’aide d’applets de commande

PSSession
Exécuter un script ou une commande avec l’applet de commande Invoke-

Command
Si vous gérez des machines virtuelles plus anciennes, utilisez Connexion à une machine
virtuelle (VMConnect) ou configurez un réseau virtuel pour la machine virtuelle.
Créer et quitter une session PowerShell Direct à

l’aide d’applets de commande PSSession
1. Sur l’hôte Hyper-V, ouvrez Windows PowerShell en tant qu’administrateur.
2. Utilisez l’applet de commande Enter-PSSession pour vous connecter à la machine

virtuelle. Exécutez l’une des commandes suivantes pour créer une session en
utilisant le nom ou le GUID de la machine virtuelle :
Enter-PSSession -VMName <VMName>

Enter-PSSession -VMGUID <VMGUID>
3. Tapez vos informations d’identification pour la machine virtuelle.
4. Exécutez toutes les commandes nécessaires. Ces commandes s’exécutent sur la

machine virtuelle à l’aide de laquelle vous avez créé la session.
5. Lorsque vous avez terminé, utilisez Exit-PSSession pour fermer la session.
Exit-PSSession
Exécuter un script ou une commande avec

l’applet de commande Invoke-Command
Vous pouvez utiliser l’applet de commande Invoke-Command pour exécuter un
ensemble prédéfini de commandes sur la machine virtuelle. L’exemple suivant illustre
l’utilisation de l’applet de commande Invoke-Command, où PSTest est le nom de la
machine virtuelle et où le script à exécuter (foo.ps1) se trouve dans le dossier script sur
le lecteur C:/ :
Invoke-Command -VMName PSTest -FilePath C:\script\foo.ps1
Pour exécuter une commande unique, utilisez le paramètre -ScriptBlock :
Invoke-Command -VMName PSTest -ScriptBlock { cmdlet }
Qu’est-ce qui est nécessaire pour utiliser

PowerShell Direct ?
Pour créer une session PowerShell Direct sur une machine virtuelle :
la machine virtuelle doit être démarrée et s’exécuter localement sur l’hôte ;
vous devez être connecté à l’ordinateur hôte en tant qu’administrateur Hyper-V ;

vous devez fournir des informations d’identification utilisateur valides pour la
machine virtuelle.
Le système d’exploitation hôte doit exécuter au moins Windows 10 ou Windows

Server 2016.
La machine virtuelle doit exécuter au moins Windows 10 ou Windows Server 2016.
Vous pouvez utiliser l’applet de commande Get-VM pour vérifier que les informations
d’identification que vous utilisez ont le rôle d’administrateur Hyper-V et pour obtenir la
liste des machines virtuelles démarrées et exécutées localement sur l’hôte.
Voir aussi
Enter-PSSessionExit-PSSessionInvoke-Command
Configurer le réplica Hyper-V
Article • 09/03/2023
Azure Stack HCI versions 22H2 et 21H2
La réplication Hyper-V fait partie intégrante du rôle Hyper-V. Elle participe à votre
stratégie de reprise d’activité après sinistre en répliquant les machines virtuelles d’un
serveur hôte Hyper-V vers un autre pour maintenir la disponibilité de vos charges de
travail. Le réplica Hyper-V crée une copie d’une machine virtuelle en ligne sur une
machine virtuelle de réplication qui est hors connexion. Notez les points suivants :
Hôtes Hyper-V : les serveurs hôtes principaux et secondaires peuvent être

physiquement colocalisés ou se trouver à des emplacements géographiques
distincts avec une réplication par liaison WAN. Les hôtes Hyper-V peuvent être des
serveurs autonomes, des serveurs en cluster ou une combinaison des deux. Il n’y a
aucune dépendance Active Directory entre les serveurs, et les serveurs n’ont pas
l’obligation d’être membres du domaine.
Réplication et suivi des modifications : lorsque vous activez le réplica Hyper-V

pour une machine virtuelle spécifique, la réplication initiale crée une machine
virtuelle de réplication identique sur un serveur hôte secondaire. Ensuite, le suivi
des modifications du réplica Hyper-V crée et gère un fichier journal qui capture les
modifications sur un disque dur virtuel de la machine virtuelle. Le fichier journal est
lu dans l’ordre inverse sur le disque dur virtuel de réplication selon les paramètres
définis pour la fréquence de réplication. Cela signifie que les modifications les plus
récentes sont stockées et répliquées de manière asynchrone. La réplication peut se
faire via HTTP ou HTTPS.
Réplication (chaînée) étendue : vous pouvez répliquer une machine virtuelle d’un
hôte principal vers un hôte secondaire, puis répliquer l’hôte secondaire vers un
troisième hôte. Notez que vous ne pouvez pas faire cette réplication de l’hôte
principal directement vers le deuxième et le troisième hôtes.
Cette fonctionnalité rend le réplica Hyper-V plus robuste pour la reprise d’activité
après sinistre. En effet, en cas d’interruption, vous avez les moyens de faire une
récupération à la fois à partir du réplica principal et du réplica étendu. Vous pouvez
basculer vers le réplica étendu en cas d’interruption de vos sites (principal et
secondaires). Notez que le réplica étendu ne prend pas en charge la réplication
cohérente avec les applications et qu’il doit utiliser les mêmes disques durs virtuels
que ceux utilisés par le réplica secondaire.
Basculement : en cas d’interruption de votre site principal (ou secondaire pour un
réplica étendu), vous pouvez démarrer manuellement un test ou un basculement
(prévu ou non planifié).
Question Test Prévu Non

planifié
Quand Vérifiez qu’une machine virtuelle Pendant les temps Durant des
dois-je le peut basculer vers le site secondaire d’arrêt et interruptions événements
faire ? et démarrer sur ce site planifiés inattendus
Utile lors des phases de test et
d’apprentissage
Une Oui Non Non

machine
virtuelle
dupliquée
est-elle
créée ?
Où Sur la machine virtuelle de Lancée sur l’ordinateur Sur la

l’opération réplication principal, puis se machine
est-elle termine sur virtuelle de
lancée ? l’ordinateur réplication
secondaire
À quelle Nous vous recommandons de Une fois tous les six Uniquement
fréquence l’exécuter une fois par mois pour les mois ou à une autre en cas de
l’exécuter ? tests fréquence sinistre
conformément aux lorsque la
exigences de machine
conformité virtuelle
principale
n’est pas
disponible
La Oui Oui. Lorsque Non

réplication l’interruption est
de la résolue, la réplication
machine inversée réplique les
virtuelle modifications sur le
principale site principal pour
se garantir la
poursuit- synchronisation entre
elle ? le site principal et les
sites secondaires.
Question Test Prévu Non
planifié
Cela None Aucun. Après le Cela dépend

entraîne-t- basculement, le réplica de
il une Hyper-V réplique le l’événement
perte de dernier ensemble de et des points
données ? modifications suivies de
vers le site principal récupération
pour empêcher toute
perte de données.
Y a-t-il des Aucun. Cela n’impacte pas votre Durée de l’interruption Durée de
temps environnement de production. Une planifiée l’interruption
d’arrêt ? machine virtuelle de test dupliquée non planifiée
est créée durant le basculement.
Une fois le basculement terminé,
vous sélectionnez Basculement sur
la machine virtuelle de réplication et
celle-ci est automatiquement
nettoyée et supprimée.
Points de récupération : lorsque vous configurez les paramètres de réplication

pour une machine virtuelle, vous spécifiez les points de récupération que vous
souhaitez stocker à partir de celle-ci. Les points de récupération représentent un
instantané dans le temps à partir duquel vous pouvez récupérer une machine
virtuelle. Bien sûr, il y a moins de risque de perdre des données quand la
récupération est faite à partir d’un point de récupération très récent. Vous pouvez
accéder aux points de récupération des dernières 24 heures.
Conditions préalables au déploiement

Voici les points à vérifier avant de commencer :
Identifiez les disques durs virtuels à répliquer. En particulier, les disques durs
virtuels qui contiennent des données très variables et non utilisées par le serveur
de réplication après le basculement, comme les disques de fichiers d'échange,
doivent être exclus de la réplication pour économiser la bande passante réseau.
Notez les disques durs virtuels à exclure.
Déterminez la fréquence à laquelle vous avez besoin de synchroniser les

données : les données sur le serveur réplica sont mises à jour et synchronisées
selon la fréquence de réplication que vous configurez (toutes les 30 secondes, 5
minutes ou 15 minutes). Choisissez une fréquence en tenant compte des points
suivants : Les machines virtuelles utilisent-elles des données critiques avec un
objectif de point de récupération (RPO) faible ? Quelles sont les exigences de
bande passante ? Les machines virtuelles hautement critiques nécessitent
évidemment une réplication plus fréquente.
Déterminez le mode de récupération des données : par défaut, le réplica Hyper-V

ne stocke qu’un seul point de récupération, qui correspond à la dernière
réplication envoyée du serveur principal au serveur secondaire. Toutefois, si vous
souhaitez pouvoir récupérer des données à partir d’un point antérieur dans le
temps, vous pouvez spécifier que des points de récupération supplémentaires
doivent être stockés (dans la limite de 24 points par heure). Si vous avez besoin de
points de récupération supplémentaires, notez que cela demande une plus grande
charge sur les ressources de traitement et de stockage.
Identifiez les charges de travail à répliquer : la réplication de réplica Hyper-V

standard maintient la cohérence dans l’état du système d’exploitation de la
machine virtuelle après un basculement, mais pas dans l’état des applications qui
s’exécutent sur la machine virtuelle. Si vous souhaitez pouvoir récupérer l’état des
charges de travail, vous pouvez créer des points de récupération cohérents avec
les applications. Notez que la récupération cohérente avec les applications n’est
pas disponible sur le site du réplica étendu si vous utilisez la réplication (chaînée)
étendue.
Déterminez la méthode à utiliser pour la réplication initiale des données de

machine virtuelle : la réplication commence par la transmission de l’état actuel des
machines virtuelles. Cet état initial peut être transmis directement via le réseau
existant, soit immédiatement soit à un moment ultérieur que vous configurez. Vous
pouvez également utiliser une machine virtuelle restaurée préexistante (par
exemple, si vous avez restauré une sauvegarde antérieure de la machine virtuelle
sur le serveur réplica) comme copie initiale. Vous pouvez également économiser la
bande passante réseau en copiant la copie initiale sur des supports externes, puis
en remettant physiquement les supports sur le site de réplication. Si vous
souhaitez utiliser une machine virtuelle préexistante, supprimez tous les
instantanés précédents qui lui sont associés.
Étapes du déploiement
Étape 1 : Configurer les hôtes Hyper-V

Vous devez prévoir au moins deux hôtes Hyper-V, avec une ou plusieurs machines
virtuelles sur chaque serveur. Consultez Bien démarrer avec Hyper-V. Le serveur hôte sur
lequel vous allez répliquer des machines virtuelles doit être configuré en tant que
serveur réplica.
1. Dans les paramètres Hyper-V du serveur où seront répliquées les machines

virtuelles, dans Configuration de la réplication, sélectionnez Activer cet
ordinateur comme serveur réplica.
2. Vous pouvez faire la réplication via HTTP ou HTTPS (chiffré). Sélectionnez Utiliser
Kerberos (HTTP) ou Utiliser l’authentification basée sur des certificats (HTTPS).
Par défaut, HTTP 80 et HTTPS 443 sont activés en tant qu’exceptions de pare-feu
sur le serveur Hyper-V réplica. Si vous modifiez les paramètres de port par défaut,
vous devez également modifier l’exception de pare-feu. Si vous choisissez la
réplication via HTTPS, vous devez sélectionner un certificat, après vous être assuré
que l’authentification par certificat est configurée.
3. Pour l’autorisation, sélectionnez Autoriser la réplication à partir de n’importe quel

serveur authentifié afin que le serveur réplica accepte le trafic de réplication de
machine virtuelle en provenance de tout serveur principal qui s’est correctement
authentifié. Sélectionnez Autoriser la réplication à partir des serveurs spécifiés
pour accepter uniquement le trafic provenant des serveurs principaux que vous
sélectionnez spécifiquement.
Pour les deux options, vous pouvez spécifier l’emplacement où stocker les disques
durs virtuels répliqués sur le serveur réplica Hyper-V.
4. Cliquez sur OK ou Appliquer.
Étape 2 : Configurer le pare-feu

Pour autoriser la réplication entre les serveurs principaux et secondaires, le trafic doit
passer par le pare-feu Windows (ou tout autre pare-feu tiers). Au moment de
l’installation du rôle Hyper-V sur les serveurs, des exceptions pour HTTP (80) et HTTPS
(443) ont été créées par défaut. Si vous utilisez ces ports standard, il vous suffit d’activer
les règles :
Pour activer les règles sur un serveur hôte autonome :
1. Ouvrez Pare-feu Windows avec fonctions avancées de sécurité, puis cliquez

sur Règles de trafic entrant.
2. Pour activer l’authentification (Kerberos) HTTP, cliquez avec le bouton droit

sur Écouteur HTTP de réplica Hyper-V (TCP-In)>Activer la règle. Pour activer
l’authentification basée sur des certificats HTTPS, cliquez avec le bouton droit
sur Écouteur HTTPS de réplica Hyper-V (TCP-In)>Activer la règle.
Pour activer les règles sur un cluster Hyper-V, ouvrez une session Windows
PowerShell avec Exécuter en tant qu’administrateur, puis exécutez l’une des
commandes suivantes :
Pour HTTP :
get-clusternode | ForEach-Object {Invoke-command -computername $_.name -

scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTP
Listener (TCP-In)"}}
Pour HTTPS :
get-clusternode | ForEach-Object {Invoke-command -computername $_.name -
scriptblock {Enable-Netfirewallrule -displayname "Hyper-V Replica HTTPS

Listener (TCP-In)"}}
Activer la réplication des machines virtuelles

Effectuez les étapes suivantes sur chaque machine virtuelle que vous souhaitez répliquer
:
1. Dans le volet Détails du Gestionnaire Hyper-V, sélectionnez une machine virtuelle

en cliquant dessus. Cliquez avec le bouton droit sur la machine virtuelle
sélectionnée et cliquez sur Activer la réplication pour ouvrir l’Assistant Activation
de la réplication.
2. Dans la page Avant de commencer, cliquez sur Suivant.
3. Dans la page Spécifier le serveur réplica, dans la zone Serveur réplica, entrez le
nom NetBIOS ou FQDN du serveur réplica. Si le serveur réplica fait partie d'un
cluster de basculement, entrez le nom du service Broker de réplication Hyper-V.
Cliquez sur Suivant.
4. Dans la page Spécifier les paramètres de connexion, le réplica Hyper-V récupère

automatiquement les paramètres d’authentification et de port que vous avez
configurés pour le serveur réplica. Si les valeurs ne sont pas récupérées, vérifiez
que le serveur est configuré comme serveur réplica et qu’il est inscrit auprès du
service DNS. Si nécessaire, entrez manuellement les paramètres.
5. Dans la page Choisir les disques durs virtuels de réplication, assurez-vous que les
disques durs virtuels à répliquer sont sélectionnés et décochez les cases à côté des
disques durs virtuels que vous souhaitez exclure de la réplication. Cliquez ensuite
sur Suivant.
6. Dans la page Configurer la fréquence de réplication, spécifiez la fréquence à

laquelle les modifications doivent être synchronisées entre le serveur principal et le
serveur secondaire. Cliquez ensuite sur Suivant.
7. Dans la page Configurer des points de récupération supplémentaires, choisissez

si vous souhaitez conserver uniquement le dernier point de récupération ou créer
des points supplémentaires. Si vous souhaitez récupérer de manière cohérente des
applications et des charges de travail qui ont leurs propres enregistreurs VSS, nous
vous recommandons de sélectionner Fréquence du service VSS (Volume Shadow
Copy Service) et de spécifier la fréquence à laquelle créer des instantanés
cohérents avec les applications. Notez que le service demandeur VMM Hyper-V
doit être exécuté à la fois sur les serveurs Hyper-V principaux et secondaires.
Cliquez ensuite sur Suivant.
8. Dans la page Choisir la méthode de réplication initiale, sélectionnez la méthode

de réplication initiale à utiliser. Le paramètre par défaut pour envoyer la copie
initiale sur le réseau copie le fichier de configuration de la machine virtuelle
principale (VMCX) et les fichiers de disque dur virtuel (VHDX et VHD) que vous
avez sélectionnés sur votre connexion réseau. Vérifiez la disponibilité de la bande
passante réseau si vous envisagez d’utiliser cette option. Si la machine virtuelle
principale est déjà configurée sur le site secondaire comme machine virtuelle de
réplication, il peut être utile de sélectionner Utiliser une machine virtuelle
existante sur le serveur de réplication comme copie initiale. Vous pouvez utiliser
l’exportation Hyper-V pour exporter la machine virtuelle principale et l’importer
comme machine virtuelle de réplication sur le serveur secondaire. Si vous avez des
machines virtuelles de grande taille ou une bande passante limitée, vous pouvez
choisir de démarrer la réplication initiale sur le réseau plus tard, aux heures creuses
que vous définissez ensuite, ou d’envoyer les informations de la réplication initiale
avec un support hors connexion.
Si vous effectuez une réplication hors connexion, vous devez transmettre la copie
initiale au serveur secondaire en utilisant un support de stockage externe tel qu’un
disque dur ou un lecteur USB. Pour cela, vous devez connecter le stockage externe
au serveur principal (ou au nœud propriétaire dans un cluster). Ensuite, quand vous
sélectionnez Envoyer la copie initiale à l’aide d’un support externe, vous pouvez
spécifier un emplacement, localement ou sur votre support externe, où stocker la
copie initiale. Une machine virtuelle d’espace réservé est créée sur le site de
réplication. Après la réplication initiale, le stockage externe peut être transmis au
site de réplication. Vous connectez le support externe au serveur secondaire ou au
nœud propriétaire du cluster secondaire. Ensuite, vous importez le réplica initial à
un emplacement spécifié et vous le fusionnez sur la machine virtuelle d’espace
réservé.
9. Dans la page Fin de l’Assistant Activation de la réplication, passez en revue les

informations contenues dans la section Résumé, puis cliquez sur Terminer. Les
données de la machine virtuelle sont transférées selon les paramètres que vous
avez choisis. Une boîte de dialogue s’affiche pour indiquer que la réplication a bien
été activée.
10. Si vous souhaitez configurer la réplication (chaînée) étendue, ouvrez le serveur

réplica et cliquez avec le bouton droit sur la machine virtuelle à répliquer. Cliquez
sur Réplication>Étendre la réplication et spécifiez les paramètres de réplication.
Exécuter un basculement
Une fois ces étapes de déploiement terminées, votre environnement répliqué est
opérationnel. Vous pouvez maintenant effectuer des basculements selon vos besoins.
Test de basculement : si vous souhaitez tester un basculement, cliquez avec le bouton

droit sur la machine virtuelle de réplication et sélectionnez Réplication>Test de
basculement. Sélectionnez le dernier point de récupération ou tout autre point de
récupération configuré. Une nouvelle machine virtuelle de test est créée et démarrée sur
le site secondaire. Une fois le test terminé, sélectionnez Arrêter le test de basculement
sur la machine virtuelle de réplication pour la nettoyer. Notez que pour une machine
virtuelle, vous ne pouvez lancer qu’un seul test de basculement à la fois. Pour plus
d’informations, consultez Tester le basculement dans le réplica Hyper-V.
Basculement planifié : pour effectuer un basculement planifié, cliquez avec le bouton

droit sur la machine virtuelle principale et sélectionnezRéplication>Basculement
planifié. Le basculement planifié vérifie les prérequis pour éviter toute perte de
données. Il vérifie que la machine virtuelle principale est arrêtée avant de commencer le
basculement. Après le basculement de la machine virtuelle, il démarre la réplication des
modifications sur le site principal disponible. Notez que cela est possible si le serveur
principal a été configuré pour recevoir les données de réplication du serveur secondaire,
ou du service Broker de réplication Hyper-V dans le cas d’un cluster principal. Le
basculement planifié envoie le dernier ensemble de modifications suivies. Pour plus
d’informations, consultez Basculement planifié dans le réplica Hyper-V.
Basculement non planifié : pour effectuer un basculement non planifié, cliquez avec le
bouton droit sur la machine virtuelle de réplication et
sélectionnezRéplication>Basculement non planifié à partir du Gestionnaire Hyper-V ou
du Gestionnaire du cluster de basculement. Vous pouvez faire une récupération à partir
du dernier point de récupération ou d’autres points de récupération précédents si cette
option est activée. Après le basculement, vérifiez que tout fonctionne comme prévu sur
la machine virtuelle basculée, puis cliquez sur Terminer sur la machine virtuelle de
réplication. En savoir plus.
Activer le matériel de monitoring des
performances d’Intel sur une machine
Hyper-V
Article • 09/03/2023
Les processeurs Intel contiennent des composants collectivement appelés matériel de

monitoring des performances (par exemple, PMU, PEBS, LBR). Ces composants sont
utilisés par des logiciels de réglage des performances comme Intel VTune Amplifier pour
analyser les performances des logiciels. Avant Windows Server 2019 et Windows 10
version 1809, ni le système d’exploitation hôte ni les machines virtuelles invitées Hyper-
V ne pouvaient utiliser le matériel de monitoring des performances quand Hyper-V était
activé. À compter de Windows Server 2019 et Windows 10 version 1809, le système
d’exploitation hôte a accès par défaut au matériel de monitoring des performances. Les
machines virtuelles invitées Hyper-V n’y ont pas accès par défaut, mais les
administrateurs Hyper-V peuvent choisir d’accorder l’accès à une ou plusieurs machines
virtuelles invitées. Ce document décrit les étapes nécessaires pour exposer le matériel de
monitoring des performances aux machines virtuelles invitées.
Configuration requise
Pour activer le matériel de monitoring des performances dans une machine virtuelle,
vous avez besoin de ceci :
Un processeur Intel doté de matériel de monitoring des performances (par ex.,

PMU, PEBS, LBR). Reportez-vous à ce document d’Intel pour déterminer le
matériel de monitoring des performances que votre système prend en charge.
Windows Server 2019 ou Windows 10 version 1809 (mise à jour d’octobre 2018) ou
ultérieure
Une machine virtuelle Hyper-V sansvirtualisation imbriquée qui est également à
l’état arrêté
Pour activer le matériel de monitoring des performances Intel Processor Trace (IPT) à
venir dans une machine virtuelle, vous aurez besoin de ceci :
Un processeur Intel qui prend en charge IPT et le composant PT2GPA. [^1]

Reportez-vous à ce document d’Intel pour déterminer le matériel de monitoring
des performances que votre système prend en charge.
Windows Server version 1903 (SAC) ou Windows 10 version 1903 (mise à jour de
mai 2019) ou ultérieure
Une machine virtuelle Hyper-V sansvirtualisation imbriquée qui est également à
l’état arrêté
PMU doit être activé par le biais de la ligne de commande à l’aide de la commande
visible ci-dessous.
[^1] : PT2GPA fait référence à la partie « Intel PT utilise des adresses physiques
invitées ». Cette partie est décrite dans la documentation 25.5.4.1 d’Intel SDM.
Activation des composants de monitoring des

performances dans une machine virtuelle
Pour activer différents composants de monitoring des performances pour une machine
virtuelle invitée spécifique, exécutez l’applet de commande PowerShell Set-VMProcessor
en tant qu’administrateur :
７ Notes
La génération de la machine virtuelle doit être 9.1 ou plus. Si la virtualisation

imbriquée est également proposée à l’invité, alors la génération 9.3 et plus est
nécessaire.
Powershell
# Enable IPT
Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu")
Powershell
# Enable all components

Set-VMProcessor MyVMName -Perfmon @("ipt", "pmu", "lbr", "pebs")
Powershell
# Disable all components

Set-VMProcessor MyVMName -Perfmon @()
７ Notes
Lors de l’activation des composants de monitoring des performances, si "pebs" est

spécifié, alors "pmu" doit également être spécifié.
PEBS est uniquement pris en charge sur le matériel dont la version PMU est
supérieure ou égale à 4.
En outre, toute commande qui tente d’activer "ipt" doit également spécifier
"pmu" .
L’activation d’un composant qui n’est pas pris en charge par les processeurs
physiques de l’hôte entraîne un échec du démarrage de la machine virtuelle.
Effets de l’activation du matériel de monitoring

des performances sur l’enregistrement/la
restauration, l’exportation et la migration
dynamique
Microsoft ne recommande pas d’effectuer une migration dynamique ou d’enregistrer/de
restaurer des machines virtuelles avec du matériel de monitoring des performances
entre des systèmes dotés de matériel Intel différent. Le comportement spécifique du
matériel de monitoring des performances est souvent non architectural et change entre
les systèmes matériels Intel. Le déplacement d’une machine virtuelle en cours
d’exécution entre différents systèmes peut entraîner un comportement imprévisible des
compteurs non architecturaux.
Mode de compatibilité du processeur
dans Hyper-V
Article • 11/04/2023
Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Hyper-V
Server 2019, Hyper-V Server 2016, Hyper-V Server 2012 R2
Hyper-V offre le mode de compatibilité du processeur, une fonctionnalité qui a été

introduite pour la première fois dans Windows Server 2008 R2. Le mode de
compatibilité du processeur vous permet de déplacer un ordinateur virtuel en cours
d’exécution ou d’enregistrer l’état entre les hôtes de virtualisation qui utilisent
différentes générations de processeurs. Cette fonctionnalité désactive de nombreuses
fonctionnalités de processeur modernes, ce qui peut affecter les performances de la
machine virtuelle. Ce document fournit des détails sur le mode de compatibilité du
processeur pour Hyper-V.
À quel moment utiliser le mode de

compatibilité du processeur
Le mode de compatibilité du processeur s’applique à tout scénario de mobilité de
machine virtuelle qui n’implique pas de redémarrage de la machine virtuelle. Il s’agit
notamment de la migration dynamique, de l’enregistrement et de la restauration, et des
points de contrôle de production des machines virtuelles.
Les machines virtuelles ne peuvent pas être migrées en direct, enregistrées et restaurées
sur des hôtes de virtualisation qui utilisent des processeurs de différents fabricants. Par
exemple, vous ne pouvez pas déplacer des machines virtuelles en cours d’exécution ou
des machines virtuelles d’état enregistré à partir d’un ordinateur hôte avec processeurs
Intel vers un ordinateur hôte avec processeurs AMD. Si vous devez déplacer une
machine virtuelle dans ce cas, la machine virtuelle doit d’abord être arrêtée, puis
redémarrée sur le nouvel hôte.
Si vous envisagez de déplacer des machines virtuelles sans les redémarrer, entre des
hôtes de virtualisation qui peuvent utiliser différentes générations de processeurs, vous
devez activer le mode de compatibilité du processeur. Par exemple, vous activez le
mode de compatibilité du processeur pour vous assurer que vous pouvez migrer en
direct vos machines virtuelles entre des nœuds de cluster qui utilisent différents
ensembles de fonctionnalités de processeur. Vous pouvez également utiliser le mode de
compatibilité du processeur pour enregistrer une machine virtuelle et la restaurer sur un
ordinateur hôte qui a un ensemble de fonctionnalités de processeur différent de celui
de l’hôte source.
Pourquoi le mode de compatibilité du

processeur est-il nécessaire
Les extensions ISA (Instruction Set Architecture) sont des optimisations et des
fonctionnalités introduites par les fabricants de processeurs. Ces fonctionnalités
améliorent souvent les performances ou la sécurité en utilisant du matériel spécialisé
pour une tâche particulière. Par exemple, de nombreuses applications multimédias
utilisent des fonctionnalités de processeur afin d’accélérer les calculs de vecteur. Ces
fonctionnalités sont rarement requises pour l’exécution des applications, elles
améliorent simplement les performances.
L’ensemble des fonctionnalités disponibles sur un processeur varie en fonction de sa

marque, de son modèle et de son âge. Les systèmes d’exploitation et les logiciels
d’application énumèrent généralement l’ensemble des fonctionnalités du processeur du
système défini lors de son premier lancement. Le logiciel ne s’attend pas à ce que les
fonctionnalités du processeur soient modifiées au cours de sa durée de vie, et cela ne
peut jamais se produire lors de l’exécution sur un ordinateur physique, car les
fonctionnalités du processeur sont statiques.
Toutefois, les fonctionnalités de mobilité des machines virtuelles permettent de migrer

une machine virtuelle en cours d’exécution vers un nouvel hôte de virtualisation. Si le
logiciel de la machine virtuelle a détecté et a commencé à utiliser une fonctionnalité de
processeur particulière, et que la machine virtuelle est déplacée vers un nouvel hôte de
virtualisation qui ne dispose pas de cette fonctionnalité, le logiciel risque d’échouer. Cela
peut entraîner un incident au niveau de la machine virtuelle.
Pour éviter ces défaillances, Hyper-V effectue des vérifications préliminaires chaque fois
qu’une opération de migration dynamique de machine virtuelle ou d’enregistrement/de
restauration est lancée. Ces vérifications comparent l’ensemble des fonctionnalités du
processeur disponibles pour la machine virtuelle sur l’hôte source par rapport à
l’ensemble des fonctionnalités disponibles sur l’ordinateur hôte cible. Si ces ensembles
de fonctionnalités ne correspondent pas, l’opération de migration ou de restauration est
annulée.
Fonctionnement du mode de compatibilité du
processeur
Le mode de compatibilité du processeur garantit que l’ensemble des fonctionnalités de
processeur disponibles pour les machines virtuelles sur un ensemble disparate d’hôtes
de virtualisation correspond en ne présentant qu’un ensemble limité de fonctionnalités
de processeur à la machine virtuelle. Le mode de compatibilité du processeur masque
les ensembles d’instructions de processeur plus récents, généralement ceux introduits
au cours des 10 dernières années. Toutefois, le fait de masquer ces fonctionnalités
signifie que le système d’exploitation invité et le logiciel d’application ne peuvent pas
tirer parti de ces améliorations apportées au jeu d’instructions du processeur.
Pour obtenir la liste complète des fonctionnalités masquées pour le mode de

compatibilité du processeur, reportez-vous à la section 5.2.11 de la Spécification
fonctionnelle générale de l’hyperviseur.
Ramifications de l’utilisation du mode de

compatibilité du processeur
Il est difficile de quantifier les effets globaux sur les performances du mode de
compatibilité du processeur. La perte de performances dépend principalement de la
charge de travail en cours d’exécution sur la machine virtuelle. Certaines charges de
travail ne sont pas affectées, tandis que d’autres présentent une différence notable. Les
logiciels qui reposent fortement sur les optimisations matérielles (comme le chiffrement,
la compression ou les calculs à virgule flottante intensifs) seront les plus affectés.
L’exemple suivant décrit comment le chiffrement AES est affecté par l’utilisation du
mode de compatibilité du processeur, et il y en a beaucoup d’autres. Si vous êtes
préoccupé par l’impact sur les performances du mode de compatibilité du processeur, il
est préférable de comparer les performances de la charge de travail de machine virtuelle
avec le mode de compatibilité du processeur activé et désactivé.
Exemple : chiffrement AES

Un exemple d’opération qui est affectée par le mode de compatibilité du processeur est
le chiffrement AES (une forme courante de chiffrement). De nombreux processeurs Intel
et AMD récents incluent une extension ISA qui accélère AES à l’aide du matériel. Intel
affirme que cette optimisation offre accélère les performances de 2 à 3 fois, et jusqu’à
10 fois pour certaines implémentations. (Pour plus d’informations, consultez Instructions
Advanced Encryption Standard d’Intel .)
Les applications qui chiffrent ou déchiffrent une grande quantité de données bénéficient
de cette fonctionnalité de processeur. Par conséquent, sa désactivation en activant le
mode de compatibilité du processeur aura un impact sur les performances de ces
opérations spécifiques.
Utiliser le mode de compatibilité du processeur

Il existe des concepts importants à comprendre lors de l’utilisation du mode de
compatibilité du processeur dans Hyper-V :
Les machines virtuelles en cours d’exécution ne peuvent être migrées qu’entre des
hôtes de virtualisation qui utilisent des processeurs du même fabricant.
Vous devez arrêter la machine virtuelle avant de pouvoir activer ou désactiver le

mode de compatibilité du processeur.
Le mode de compatibilité du processeur n’est pas nécessaire pour les

déplacements de machine virtuelle qui impliquent un arrêt et un redémarrage de
la machine virtuelle.
Chaque fois qu’une machine virtuelle est redémarrée, le système d’exploitation

invité énumère les compatibilités du processeur disponibles sur le nouvel
ordinateur hôte.
７ Notes
Dans Windows Server, Microsoft recommande d’activer le mode de compatibilité

du processeur uniquement avant les scénarios de migration de machine virtuelle,
puis de le désactiver une fois la migration terminée.
Activer le mode de compatibilité du processeur

avec le gestionnaire Hyper-V
Pour activer le mode de compatibilité du processeur pour une machine virtuelle à l’aide
du Gestionnaire Hyper-V :
1. Arrêtez la machine virtuelle.
2. Cliquez sur Démarrer, pointez sur Outils d'administration, puis cliquez sur
3. Sélectionnez le serveur exécutant Hyper-V et la machine virtuelle souhaitée.
4. Si la machine virtuelle est en cours d’exécution, vous devez l’arrêter pour activer le
paramètre de mode de compatibilité du processeur.
5. Dans le volet Action, cliquez sur Paramètres, puis sur Processeur.
6. Développez Processeur, puis cliquez sur Compatibilité.
7. Sélectionnez Migrer vers un ordinateur physique avec un autre processeur, puis

cliquez sur OK.
8. Redémarrez la machine virtuelle.
Désactiver le mode de compatibilité du

processeur avec le gestionnaire Hyper-V
Pour désactiver le mode de compatibilité du processeur pour une machine virtuelle à
l’aide du Gestionnaire Hyper-V :
1. Arrêtez la machine virtuelle.

2. Cliquez sur Démarrer, pointez sur Outils d'administration, puis cliquez sur
3. Sélectionnez le serveur exécutant Hyper-V et la machine virtuelle souhaitée.
4. Si la machine virtuelle est en cours d’exécution, vous devez l’arrêter pour

désactiver le paramètre de mode de compatibilité du processeur.
5. Dans le volet Action, cliquez sur Paramètres, puis sur Processeur.
6. Développez Processeur, puis cliquez sur Compatibilité.
7. Décochez Migrer vers un ordinateur physique avec un autre processeur, puis

cliquez sur OK.
8. Redémarrez la machine virtuelle.
Activer le mode de compatibilité du processeur

avec PowerShell
Pour activer le mode de compatibilité du processeur pour une machine virtuelle à l’aide
de PowerShell, arrêtez la machine virtuelle et exécutez la cmdlet Set-VMProcessor , en
définissant CompatibilityForMigrationEnabled sur $true :
PowerShell
get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true
Ensuite, redémarrez la machine virtuelle.
２ Avertissement
Vous pourriez voir des paramètres supplémentaires pour Set-VMProcessor destinés

à être utilisés avec Azure Stack HCI. N’essayez pas de les utiliser avec Windows
Server, ou vous obtiendrez un message d’erreur. Le CompatibilityForMigrationMode
par défaut et le seul disponible pour Windows Server est MinimumFeatureSet .
Découvrez le mode de compatibilité du processeur dynamique dans Azure Stack
HCI.
Désactiver le mode de compatibilité du
processeur avec PowerShell
Pour désactiver le mode de compatibilité du processeur pour une machine virtuelle à
l’aide de PowerShell, arrêtez la machine virtuelle et exécutez la cmdlet Set-VMProcessor ,
en définissant CompatibilityForMigrationEnabled sur $false :
PowerShell
get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $false
Ensuite, redémarrez la machine virtuelle.
Étapes suivantes
Voir aussi :
Mode de compatibilité du processeur dynamique dans Azure Stack HCI

Vue d’ensemble de la migration
dynamique
Article • 14/04/2023
La migration dynamique est une fonctionnalité Hyper-V dans Windows Server. Elle vous
permet de déplacer de façon transparente des machines virtuelles en cours d’exécution
d’un hôte Hyper-V vers un autre, sans qu’un temps d’arrêt soit perçu. Le principal
avantage de la migration dynamique est la flexibilité dans la mesure où les machines
virtuelles en cours d’exécution ne sont pas liées à un seul ordinateur hôte. Ceci permet
des actions comme le drainage d’un hôte de machines virtuelles spécifique avant de
désaffecter ou de mettre à niveau l’hôte. Associée au clustering de basculement
Windows, la migration dynamique permet de créer des systèmes à tolérance de panne
et à haute disponibilité.
Technologies et documentation associées

La migration dynamique est souvent utilisée conjointement avec quelques technologies
associées, comme le clustering de basculement et System Center Virtual Machine
Manager. Si vous utilisez la migration dynamique via ces technologies, voici des liens
vers leur documentation la plus récente :
Clustering de basculement (Windows Server 2016)

System Center Virtual Machine Manager (System Center 2016)
Si vous utilisez des versions antérieures de Windows Server ou si vous avez besoin de
détails sur des fonctionnalités introduites dans les versions antérieures de Windows
Server, voici des liens vers la documentation de l’historique :
Migration dynamique (Windows Server 2008 R2)

Clustering de basculement (Windows Server 2012 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
Migration dynamique dans Windows

Server 2016
Dans Windows Server 2016, il existe moins de restrictions sur le déploiement de la
migration dynamique. Elle fonctionne désormais sans le clustering de basculement. Les
autres fonctionnalités restent inchangées par rapport aux versions précédentes de la
migration dynamique. Pour plus d’informations sur la configuration et l’utilisation de la
migration dynamique sans le clustering de basculement :

Utiliser la migration dynamique sans le clustering de basculement pour déplacer
Vue d’ensemble de la migration
dynamique
Article • 14/04/2023
La migration dynamique est une fonctionnalité Hyper-V dans Windows Server. Elle vous
permet de déplacer de façon transparente des machines virtuelles en cours d’exécution
d’un hôte Hyper-V vers un autre, sans qu’un temps d’arrêt soit perçu. Le principal
avantage de la migration dynamique est la flexibilité dans la mesure où les machines
virtuelles en cours d’exécution ne sont pas liées à un seul ordinateur hôte. Ceci permet
des actions comme le drainage d’un hôte de machines virtuelles spécifique avant de
désaffecter ou de mettre à niveau l’hôte. Associée au clustering de basculement
Windows, la migration dynamique permet de créer des systèmes à tolérance de panne
et à haute disponibilité.
Technologies et documentation associées

La migration dynamique est souvent utilisée conjointement avec quelques technologies
associées, comme le clustering de basculement et System Center Virtual Machine
Manager. Si vous utilisez la migration dynamique via ces technologies, voici des liens
vers leur documentation la plus récente :
Clustering de basculement (Windows Server 2016)

System Center Virtual Machine Manager (System Center 2016)
Si vous utilisez des versions antérieures de Windows Server ou si vous avez besoin de
détails sur des fonctionnalités introduites dans les versions antérieures de Windows
Server, voici des liens vers la documentation de l’historique :

Migration dynamique dans Windows

Server 2016
Dans Windows Server 2016, il existe moins de restrictions sur le déploiement de la
migration dynamique. Elle fonctionne désormais sans le clustering de basculement. Les
autres fonctionnalités restent inchangées par rapport aux versions précédentes de la
migration dynamique. Pour plus d’informations sur la configuration et l’utilisation de la
migration dynamique sans le clustering de basculement :

Utiliser la migration dynamique sans le clustering de basculement pour déplacer
Configurer des hôtes une migration
dynamique sans clustering de
basculement
Article • 11/04/2023

Cet article vous montre comment configurer des hôtes qui ne sont pas en cluster afin de
pouvoir effectuer des migrations actives entre eux. Suivez ces instructions si vous n’avez
pas configuré la migration dynamique lorsque vous avez installé Hyper-V, ou si vous
souhaitez modifier les paramètres. Pour configurer des hôtes en cluster, utilisez des
outils pour le cluster de basculement.
Conditions requises pour la configuration de la

migration dynamique
Pour configurer des hôtes qui n’appartiennent pas à un cluster pour la migration
dynamique, vous avez besoin des éléments suivants :
Un compte d’utilisateur avec l’autorisation d’effectuer les différentes étapes.

L’appartenance au groupe Administrateurs Hyper-V local ou au groupe
Administrateurs sur les ordinateurs source et cible répond à cette exigence, sauf si
vous configurez la délégation contrainte. L’appartenance au groupe
Administrateurs de domaine est requise pour configurer la délégation contrainte.
sur les serveurs source et cible. Vous pouvez effectuer une migration dynamique
entre des hôtes exécutant Windows Server 2016 et Windows Server 2012 R2 si la
machine virtuelle est au moins une version 5.
Installer le rôle Hyper-V sur Windows Server.
Les ordinateurs source et cible qui appartiennent au même domaine Active

Directory ou à des domaines qui se font confiance mutuellement.
cible et que vous les exécutez à partir du serveur.
Envisagez les options d’authentification et de

mise en réseau
Réfléchissez à la façon dont vous souhaitez configurer les éléments suivants :
Authentification : quel protocole sera utilisé pour authentifier le trafic de

migration dynamique entre les serveurs source et cible ? Le choix détermine si
vous devez vous connecter au serveur source avant de commencer une migration
dynamique :
Kerberos vous permet d’éviter d’avoir à vous connecter au serveur, mais

nécessite la configuration de la délégation contrainte. Pour obtenir des
instructions, voir ci-dessous.
CredSSP vous permet d’éviter la configuration de la délégation contrainte, mais

vous oblige à vous connecter au serveur source. Vous pouvez le faire via une
session de console locale, une session Bureau à distance ou une session de
Windows PowerShell à distance.
CredSPP nécessite une connexion pour les cas qui ne sont pas évidents. Par
exemple, si vous vous connectez à TestServer01 pour déplacer un ordinateur
virtuel vers TestServer02 et que vous voulez ensuite ramener l’ordinateur virtuel
vers TestServer01, vous devrez vous connecter à TestServer02 avant d’essayer de
ramener l’ordinateur virtuel vers TestServer01. Si vous ne le faites pas, la
tentative d’authentification échoue, une erreur se produit et le message suivant
s’affiche :
« Échec de l’opération de migration d’ordinateur virtuel à l’emplacement source

de la migration. Échec de l’établissement d’une connexion avec l’hôte nom de
l’ordinateur : aucune information d’identification n’est disponible dans le
package de sécurité 0x8009030E."
Performances : Est-il judicieux de configurer les options de performances ? Ces

options peuvent réduire l’utilisation du réseau et du processeur, et accélérer les
migrations actives. Tenez compte de vos besoins et de votre infrastructure, et
testez différentes configurations pour vous aider à décider. Les options sont
décrites à la fin de la deuxième étape.
Préférence de réseau : Souhaitez-vous autoriser le trafic de migration dynamique à
traverser tout réseau disponible ou voulez-vous isoler le trafic dans des réseaux
spécifiques ? Pour des raisons de sécurité, il est conseillé d’isoler le trafic sur des
réseaux privés approuvés, car le trafic de migration dynamique n’est pas chiffré
lorsqu’il est envoyé sur le réseau. L’isolation du réseau peut être obtenue via un
réseau isolé physiquement ou une autre technologie de mise en réseau approuvée
comme les réseaux locaux virtuels.
Étape 1 : Configurer la délégation contrainte

(facultative)
Si vous avez décidé d’utiliser Kerberos pour authentifier le trafic de migration
dynamique, configurez la délégation contrainte à l’aide d’un compte membre du groupe
Administrateurs de domaine.
Utiliser le composant logiciel enfichable Utilisateurs et

ordinateurs pour configurer la délégation contrainte
1. Ouvrez le composant logiciel enfichable Utilisateurs et ordinateurs Active
Directory. (Dans Gestionnaire de serveur, sélectionnez le serveur si ce n’est pas fait,
cliquez sur Outils>>Utilisateurs et ordinateurs Active Directory).
2. Dans le volet de navigation dans Utilisateurs et ordinateurs Active Directory,

sélectionnez le domaine et double-cliquez sur le dossier Ordinateurs.
3. Dans le dossier Ordinateurs, cliquez avec le bouton droit sur le compte

d’ordinateur du serveur source, puis cliquez sur Propriétés.
4. Dans Propriétés, cliquez sur l’onglet Délégation.
5. Sous l’onglet Délégation, sélectionnez Faire confiance à cet ordinateur

uniquement pour la délégation aux services spécifiés puis sélectionnez Utiliser
tout protocole d’authentification.
6. Cliquez sur Add.
7. Dans Ajouter des services, cliquez sur Utilisateurs ou ordinateurs.
8. Dans Sélectionner des utilisateurs ou des ordinateurs, tapez le nom du serveur

cible. Cliquez sur Vérifier les noms, puis sur OK.
9. Dans Ajouter des services, dans la liste des services disponibles, procédez comme
suit, puis cliquez sur OK.
Pour déplacer le stockage de l’ordinateur virtuel, sélectionnez cifs. Ceci est

requis si vous souhaitez déplacer le stockage avec l’ordinateur virtuel ou si
vous voulez déplacer uniquement le stockage d’un ordinateur virtuel. Si le
serveur est configuré pour utiliser le stockage SMB pour Hyper-V, cela doit
être déjà sélectionné.
Pour déplacer les ordinateurs virtuels, sélectionnez Service de migration de

système virtuel Microsoft.
10. Dans l’onglet Délégation de la boîte de dialogue Propriétés, vérifiez que les
services que vous avez sélectionnés à l’étape précédente sont répertoriés comme
les services auxquels l’ordinateur de destination peut présenter les informations
d’identification déléguées. Cliquez sur OK.
11. Dans le dossier Computers, sélectionnez le compte d’ordinateur du serveur de

destination et répétez le processus. Dans la boîte de dialogue Sélectionner des
utilisateurs ou des ordinateurs, veillez à spécifier le nom du serveur source.
Les modifications de configuration prennent effet après les deux événements suivants :
Réplication des modifications sur les contrôleurs de domaine auxquels les serveurs
exécutant Hyper-V sont connectés.
Le contrôleur de domaine émet un nouveau ticket Kerberos.
Étape 2 : Configurer les ordinateurs source et

cible pour la migration dynamique
Cette étape comprend le choix des options d’authentification et de mise en réseau. Pour
des raisons de sécurité, il est conseillé de sélectionner des réseaux spécifiques à utiliser
pour le trafic de migration dynamique, comme indiqué plus tôt. Cette étape vous
montre également comment choisir l’option de performances.
Utiliser le Gestionnaire Hyper-V pour configurer les

3. Dans le volet Action, cliquez sur Paramètres Hyper-V>>Migrations dynamiques.
4. Dans le volet Migrations dynamiques, sélectionnez Activer les migrations

dynamiques entrantes et sortantes.
5. Sous Migrations dynamiques simultanées, spécifiez un chiffre différent si vous ne

voulez pas utiliser la valeur par défaut 2.
6. Sous Migrations dynamiques entrantes, si vous voulez utiliser des connexions

réseau spécifiques pour accepter le trafic de migration dynamique, cliquez sur
Ajouter pour taper les informations d’adresse IP. Dans le cas contraire, cliquez sur
Utiliser n’importe quel réseau disponible pour la migration dynamique. Cliquez
sur OK.
7. Pour choisir Kerberos et les options de performances, développez Migrations

dynamiques, puis sélectionnez Fonctionnalités avancées.
Si vous avez configuré la délégation contrainte, sous Protocole

d’authentification, sélectionnez Kerberos.
Sous Options de performances, passez en revue les détails et choisissez une
autre option si elle convient à votre environnement.
8. Cliquez sur OK.
9. Sélectionnez l’autre serveur dans le Gestionnaire Hyper-V et répétez les étapes.
Utiliser Windows PowerShell pour configurer les

Trois applets de commande sont disponibles pour la configuration de la migration
dynamique sur des hôtes qui n’appartiennent pas au cluster : Enable-VMMigration, Set-
VMMigrationNetwork et Set-VMHost. Cet exemple utilise les trois et effectue les
opérations suivantes :
Configure la migration dynamique sur l’hôte local

Autorise le trafic de migration entrant uniquement sur un réseau spécifique
Choisit Kerberos comme protocole d’authentification
Chaque ligne représente une commande distincte.

PowerShell
PS C:\> Enable-VMMigration
PS C:\> Set-VMMigrationNetwork 192.168.10.1
PS C:\> Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Set-VMHost vous permet également de choisir une option de performances (et de

nombreux autres paramètres de l’hôte). Par exemple, pour choisir SMB mais laisser le
protocole d’authentification défini sur la valeur par défaut credSSP, tapez :
PowerShell
PS C:\> Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Ce tableau décrit le fonctionnement des options de performances.
Option Description
TCP/IP La mémoire de l’ordinateur virtuel est copiée sur le serveur cible via une
connexion TCP/IP.
Compression Compresse le contenu de mémoire de la machine virtuelle avant de le copier sur

le serveur cible via une connexion TCP/IP. Note : Il s’agit du paramètre par défaut.
SMB Le contenu de la mémoire de l’ordinateur virtuel est copié sur le serveur cible via
une connexion SMB 3.0.
- SMB Direct est utilisé quand les cartes réseau sur les serveurs source et cible
disposent de fonctionnalités Accès direct à la mémoire à distance (RDMA).
- SMB Multichannel détecte et utilise automatiquement plusieurs connexions
quand une configuration SMB Multichannel correcte est identifiée.
Pour plus d’informations, voir Améliorer les performances d’un serveur de fichiers
avec SMB Direct.
Étapes suivantes
Après avoir configuré les hôtes, vous êtes prêt à effectuer une migration dynamique.
Pour obtenir des instructions, consultez Utiliser la migration dynamique sans cluster de
basculement pour déplacer une machine virtuelle.
Utiliser la migration dynamique sans le
clustering de basculement pour
déplacer une machine virtuelle
Article • 14/04/2023
Cet article vous montre comment déplacer une machine virtuelle en effectuant une
migration dynamique sans utiliser le clustering de basculement. Une migration
dynamique déplace les machines virtuelles en cours d’exécution entre les hôtes Hyper-V
sans qu’aucun temps mort ne soit perçu.
Pour ce faire, vous aurez besoin de ceci :
Un compte d’utilisateur qui est membre du groupe Administrateurs Hyper-V local

ou du groupe Administrateurs sur les ordinateurs source et cible.
sur les serveurs source et cible et configuré pour les migrations dynamiques. Vous
pouvez effectuer une migration dynamique entre des hôtes exécutant Windows
Server 2016 et Windows Server 2012 R2 si la machine virtuelle est au moins une
version 5.

Configurer des hôtes pour la migration dynamique.

cible et que vous les exécutez à partir de là.
Utiliser le Gestionnaire Hyper-V pour déplacer

une machine virtuelle en cours d’exécution
3. Dans le volet Machines Virtuelles, cliquez avec le bouton droit sur la machine
virtuelle, puis cliquez sur Déplacer. Ceci ouvre l’Assistant de déplacement.
4. Utilisez les pages de l’Assistant pour choisir le type de déplacement, le serveur de

destination et les options.
5. Dans la page Résumé, passez vos choix en revue, puis cliquez sur Terminer.
Utiliser Windows PowerShell afin de déplacer

L’exemple suivant utilise l’applet de commande Move-VM pour déplacer une machine
virtuelle nommée LMTest vers un serveur de destination nommé TestServer02 et déplace
les disques durs virtuels et d’autres fichiers (tels que les points de contrôle et les fichiers
de pagination intelligente) vers le répertoire D:\LMTest sur le serveur de destination.
PS C:\> Move-VM LMTest TestServer02 -IncludeStorage -DestinationStoragePath

D:\LMTest
Dépannage
Échec de l'établissement d'une connexion

Si vous n’avez pas configuré la délégation contrainte, vous devez vous connecter au
serveur source avant de pouvoir déplacer une machine virtuelle. Si vous ne le faites pas,
la tentative d’authentification échoue, une erreur se produit et ce message s’affiche :
« Échec de l’opération de migration d’ordinateur virtuel à l’emplacement source de la

migration. Échec de l’établissement d’une connexion avec l’hôte nom de l’ordinateur :
aucune information d’identification n’est disponible dans le package de sécurité
0x8009030E. »
Pour résoudre ce problème, connectez-vous au serveur source et réessayez le

déplacement. Pour éviter d’avoir à se connecter à un serveur source avant d’effectuer
une migration dynamique, configurez la délégation contrainte. Vous aurez besoin
d’informations d’identification d’administrateur de domaine pour configurer la
délégation contrainte. Pour obtenir des instructions, consultez Configurer des hôtes
pour la migration dynamique.
Échec, car le matériel hôte n’est pas compatible

Si la compatibilité du processeur n’est pas activée sur une machine virtuelle et qu’elle a
un ou plusieurs instantanés, le déplacement échoue si les hôtes ont des versions de
processeur différentes. Une erreur se produit et ce message s’affiche :
La machine virtuelle ne peut pas être déplacée vers l’ordinateur de destination. Le

matériel sur l’ordinateur de destination n’est pas compatible avec la configuration
matérielle requise de cette machine virtuelle.
Pour résoudre ce problème, arrêtez la machine virtuelle et activez le paramètre de

compatibilité du processeur.
1. Dans le Gestionnaire Hyper-V, dans la section Machines virtuelles, cliquez avec le

bouton droit sur la machine virtuelle, puis cliquez sur Paramètres.
2. Dans le volet de navigation, développez Processeurs et cliquez sur Compatibilité.
3. Cochez Migrer vers un ordinateur ayant une autre version de processeur.
4. Cliquez sur OK.
Pour utiliser Windows PowerShell, utilisez l’applet de commande Set-VMProcessor

:
PS C:\> Set-VMProcessor TestVM -CompatibilityForMigrationEnabled $true

Optimisation des performances pour les
serveurs Hyper-V
Article • 30/08/2023
Hyper-V joue le rôle de serveur de virtualisation dans Windows Server 2016. Les
serveurs de virtualisation peuvent héberger plusieurs machines virtuelles isolées les unes
des autres mais partager les ressources matérielles sous-jacentes en virtualisant les
processeurs, la mémoire et les périphériques d’E/S. En consolidant les serveurs sur une
seule machine, la virtualisation peut améliorer l’utilisation des ressources et l’efficacité
énergétique et réduire les coûts d’exploitation et de maintenance des serveurs. De plus,
les machines virtuelles et les API de gestion offrent plus de flexibilité pour la gestion des
ressources, l’équilibrage de la charge et les systèmes d’approvisionnement.
Terminologie Hyper-V
Architecture Hyper-V
Configuration du serveur Hyper-V
Performances du processeur Hyper-V
Performances de la mémoire Hyper-V
Performances E/S du stockage Hyper-V
Performances E/S du réseau Hyper-V
Détecter les goulots d’étranglement dans un environnement virtualisé
Ordinateurs virtuels Linux

Article • 14/04/2023
Cette rubrique fournit une vue d’ensemble du commutateur virtuel Hyper-V, qui vous
permet de connecter des machines virtuelles à des réseaux externes à l’hôte Hyper-V, y
compris l’intranet de votre organisation et Internet.
Vous pouvez également vous connecter à des réseaux virtuels sur le serveur qui exécute
Hyper-V lorsque vous déployez la mise en réseau définie par logiciel (SDN).
７ Notes
Outre cette rubrique, la documentation suivante du commutateur virtuel Hyper-V

est également disponible.

RDMA (Remote Direct Memory Access) et SET (Switch Embedded Teaming)
Applets de commande d’équipe du commutateur réseau dans Windows
PowerShell
Nouveautés de VMM 2016
Configurer l’infrastructure de mise en réseau VMM
Forum Hyper-V
Hyper-V : L’extension de commutateur virtuel WFP doit être activée si elle
est requise par les extensions tierces
Pour plus d’informations sur les autres technologies de mise en réseau, consultez
Mise en réseau dans Windows Server 2016.
Le commutateur virtuel Hyper-V désigne un commutateur réseau Ethernet de couche 2

logiciel disponible dans le Gestionnaire Hyper-V lorsque vous installez le rôle serveur
Hyper-V.
Le commutateur offre des fonctionnalités gérées par programme et extensibles pour

connecter des machines virtuelles aux réseaux virtuels et au réseau physique à la fois.
Qui plus est, le commutateur virtuel Hyper-V assure l’application de la stratégie de
sécurité et d’isolement, ainsi que des niveaux de service.
７ Notes
Le commutateur virtuel Hyper-V ne prend en charge qu’Ethernet et pas les autres

technologies de réseau local (LAN) câblé, comme Infiniband et Fibre Channel.
Le commutateur virtuel Hyper-V inclut l’isolation des locataires, la mise en forme du

trafic, la protection contre les ordinateurs virtuels malveillants et la résolution simplifiée
des problèmes.
Grâce à sa prise en charge intégrée des pilotes de filtre de l’API NDIS (Network Device
Interface Specification) et des pilotes de légende WFP (Windows Filtering Platform), le
commutateur virtuel Hyper-V permet aux éditeurs de logiciels indépendants de créer
des plug-ins extensibles (« extensions de commutateur virtuel ») pouvant offrir une mise
en réseau et des fonctions de sécurité améliorées. Les extensions de commutateur
virtuel que vous ajoutez au commutateur virtuel Hyper-V sont répertoriées dans la
fonctionnalité Gestionnaire de commutateur virtuel du Gestionnaire Hyper-V.
L’illustration qui suit dévoile un ordinateur virtuel doté d’une carte réseau virtuelle
connecté au commutateur virtuel Hyper-V via un port commuté.
Les capacités du commutateur virtuel Hyper-V vous offrent un plus grand nombre
d’options pour l’application de l’isolement des locataires, la mise en forme et le contrôle
du trafic réseau, ainsi que l’emploi de mesures de protection contre les ordinateurs
virtuels malveillants.
７ Notes
Dans Windows Server 2016, une machine virtuelle avec une carte réseau virtuelle
affiche avec précision le débit maximal de la carte réseau virtuelle. Pour afficher la
vitesse de la carte réseau virtuelle dans Connexions réseau, cliquez avec le bouton
droit sur l’icône de carte réseau virtuelle souhaitée, puis cliquez sur État. La boîte
de dialogue État de la carte réseau virtuelle s’ouvre. Dans Connexion, la valeur
vitesse correspond à la vitesse de la carte réseau physique installée sur le serveur.
Utilisations du commutateur virtuel Hyper-V

Voici quelques scénarios d’utilisation pour le commutateur virtuel Hyper-V.
Affichage de statistiques : un développeur chez un fournisseur de solutions de cloud

hébergées implémente un package de gestion qui affiche l’état du commutateur virtuel
Hyper-V. Le package de gestion peut demander les statistiques sur les fonctionnalités
actuelles, les paramètres de configuration et des ports spécifiques sur tout le
commutateur à l’aide de WMI. L’état du commutateur est ensuite affiché pour offrir aux
administrateurs une vue d’ensemble.
Suivi des ressources : un fournisseur d’hébergement propose des services facturés en

fonction de l’abonnement souscrit. Les différents niveaux d’abonnement offrent
plusieurs niveaux de performance réseau. L’administrateur attribue des ressources pour
respecter les contrats SLA de sorte que la disponibilité du réseau soit équilibrée.
L’administrateur effectue le suivi par programme des informations, telles que l’usage en
cours de la bande passante affectée et le nombre d’ordinateurs virtuels, que ce soit les
files d’attente d’ordinateurs virtuels (VMQ) ou les canaux IOV. Le même programme
enregistre en outre périodiquement les ressources utilisées en plus de celles assignées
par ordinateur virtuel pour le suivi à double entrée ou pour les ressources.
Gestion de l’ordre des extensions du commutateur : une entreprise a installé des

extensions sur leur hôte Hyper-V pour contrôler le trafic et signaler la détection
d’intrusions. Lors de la maintenance, des extensions peuvent être mises à jour ce qui est
susceptible de modifier l’ordre des extensions. Un simple script est exécuté pour rétablir
l’ordre des extensions après leur mise à jour.
Extension de transfert gérant l’ID du réseau local virtuel : une société importante
spécialisée dans la commutation met au point une extension de transfert qui applique
toutes les stratégies de mise en réseau. Un des éléments gérés correspond aux ID de
réseau local virtuel. Le commutateur virtuel cède le contrôle du réseau local virtuel à
l’extension de transfert. L’installation de l’entreprise de commutation appelle par
programme une interface de programmation d’applications (API) de WMI (Windows
Management Instrumentation) qui active la transparence, indiquant ainsi au
commutateur virtuel Hyper-V de passer et de n’entreprendre aucune action avec les
étiquettes VLAN.
Fonctionnalité du commutateur virtuel Hyper-V
Voici certaines des fonctionnalités principales incluses dans le commutateur virtuel
Hyper-V :
Protection contre l’empoisonnement (usurpation d’identité) du cache ARP/ND :

offre une protection contre tout ordinateur virtuel malveillant susceptible
d’usurper une identité par empoisonnement du cache ARP (Address Resolution
Protocol) dans le but de subtiliser les adresses IP d’autres ordinateurs virtuels. Il
fournit une protection contre les attaques pouvant être lancées contre IPv6 par
usurpation ND (Neighbor Discovery).
Protection DHCP : protège contre tout ordinateur virtuel malicieux se présentant

comme un serveur DHCP (Dynamic Host Configuration Protocol) pour des
attaques d’intercepteur (« man-in-the-middle »).
Listes de contrôle d’accès des ports : permet un filtrage du trafic basé sur les
adresses/plages MAC (Media Access Control) ou IP (Internet Protocol), ce qui
permet de configurer l’isolement du réseau virtuel.
Mode Jonction à un ordinateur virtuel : permet aux administrateurs de configurer

un ordinateur virtuel spécifique sous forme d’appareil virtuel, puis de diriger le
trafic des différents réseaux locaux virtuels vers l’ordinateur virtuel en question.
Analyse du trafic réseau : permet aux administrateurs d’examiner le trafic qui

transite par le commutateur réseau.
Réseau local virtuel isolé (privé) : permet aux administrateurs de scinder le trafic
sur plusieurs réseaux locaux virtuels afin d’établir plus facilement des
communautés isolées de locataires.
La liste suivante récapitule les fonctionnalités qui améliorent l’utilisation du

commutateur virtuel Hyper-V :
Prise en charge de la limitation de la bande passante et des pics d’activité

réseau : le minimum de bande passante assure une bande passante réservée. La
bande passante maximale limite son exploitation par une machine virtuelle.
Prise en charge du marquage ECN : le marquage ECN (Explicit Congestion

Notification), également connu sous le nom de « protocole TCP de centre de
données » (DCTCP), permet au commutateur physique et au système d’exploitation
de réguler le trafic afin que les ressources de la mémoire tampon du commutateur
ne soient pas surchargées, ce qui se traduit par un débit supérieur du trafic.
Diagnostics : les diagnostics permettent un suivi simple des événements et des
paquets qui transitent par le commutateur virtuel.
Exigences liées aux réseaux d’hôtes pour Azure
Stack HCI
Article • 18/04/2023
S’applique à : Azure Stack HCI, versions 22H2 et 21H2
Cette rubrique traite des exigences et considérations relatives à la mise en réseau hôte pour Azure
Stack HCI. Pour plus d’informations sur les architectures de centre de données et les connexions
physiques entre les serveurs, consultez Configurations requises des réseaux virtuels.
Pour plus d'informations sur la façon de simplifier la mise en réseau des hôtes à l'aide de Network ATC,
consultez Simplifier la mise en réseau des hôtes avec Network ATC.
Types de trafic réseau

Le trafic réseau Azure Stack HCI peut être classé selon son rôle prévu :
Trafic de gestion : trafic à destination ou en provenance de l’extérieur du cluster local. Il s’agit par
exemple du trafic du réplica de stockage ou du trafic utilisé par l’administrateur pour la gestion
du cluster comme Bureau à distance, Windows Admin Center, Active Directory, etc.
Trafic de calcul : trafic en provenance ou à destination d’une machine virtuelle (VM).
Trafic de stockage : Trafic utilisant le protocole SMB, par exemple pour les
espaces de stockage direct ou la migration dynamique basée sur SMB. Ce trafic est de couche 2
et n’est pas routable.
） Important
Le réplica de stockage utilise un trafic SMB non basé sur RDMA. Ceci et la nature directionnelle du
trafic (Nord-Sud) entraînent un alignement étroit sur le trafic de « gestion » listé ci-dessus,
similaire à celui d’un partage de fichiers traditionnel.
Sélectionner une carte réseau

Les cartes réseau sont qualifiées par les types de trafic réseau (voir ci-dessus) qu’ils sont pris en charge
pour une utilisation. Lorsque vous passez en revue le catalogue Windows Server , la certification
Windows Server 2022 indique maintenant un ou plusieurs des rôles suivants. Avant d’acheter un
serveur pour Azure Stack HCI, vous devez disposer au minimum d’un adaptateur qualifié pour la
gestion, le calcul et le stockage, car les trois types de trafic sont requis sur Azure Stack HCI. Vous
pouvez ensuite utiliser Network ATC pour configurer vos adaptateurs pour les types de trafic
appropriés.
Pour plus d’informations sur cette qualification de carte réseau basée sur les rôles, consultez ce lien .
） Important
L’utilisation d’un adaptateur en dehors de son type de trafic qualifié n’est pas prise en charge.
Level Rôle de gestion Rôle de calcul Rôle de stockage
Distinction basée sur les rôles Gestion Standard de calcul Calcul et stockage
Récompense maximale Non applicable Calcul Premium Stockage Premium
７ Notes
La qualification la plus élevée pour n’importe quel adaptateur de notre écosystème contiendra les
qualifications Gestion, Calcul Premium et Stockage Premium.
Configuration requise des pilotes

Les pilotes de boîte de réception ne sont pas pris en charge pour une utilisation avec Azure Stack HCI.
Pour identifier si votre adaptateur utilise un pilote de boîte de réception, exécutez l’applet de
commande suivante. Un adaptateur utilise un pilote de boîte de réception si la propriété
DriverProvider est Microsoft.
Powershell
Get-NetAdapter -Name <AdapterName> | Select *Driver*
Vue d’ensemble des principales fonctionnalités des

cartes réseau
Les principales fonctionnalités des cartes réseau utilisées par Azure Stack HCI comprennent :
File d’attente multiple de machines virtuelles dynamique (Dynamic VMMQ, ou d.VMMQ)

Accès direct à la mémoire à distance (RDMA, Remote Direct Memory Access)
RDMA invité
SET (Switch Embedded Teaming)
Dynamic VMMQ
Toutes les cartes réseau avec la qualification Compute (Premium) prennent en charge VMMQ
dynamique. Cette technologie impose d’utiliser la fonctionnalité Switch Embedded Teaming.
Types de trafic applicables : calcul
Certifications requises : Calcul (Premium)
Dynamic VMMQ est une technologie intelligente côté réception. Il s’appuie sur ses prédécesseurs, File
d’attente d’ordinateurs virtuels (VMQ), Mise à l’échelle côté réception virtuelle (vRSS) et VMMQ, pour
offrir trois améliorations principales :
optimisation de l’efficacité des hôtes en utilisant moins de cœurs de processeur ;

réglage automatique du traitement du trafic réseau sur les cœurs de processeur, permettant ainsi
aux machines virtuelles de respecter et de maintenir le débit attendu ;
possibilité pour les charges de travail « en rafale » de recevoir le volume de trafic attendu.
Pour plus d’informations sur la fonctionnalité Dynamic VMMQ, consultez le billet de blog Accélérations
synthétiques .
RDMA
RDMA est un déchargement de la pile réseau vers la carte réseau. Cela permet au trafic de stockage
SMB de contourner le système d’exploitation pour traitement.
La fonctionnalité RDMA permet une mise en réseau à débit élevé et faible latence avec une utilisation
minimale des ressources de processeur hôte. Ces ressources peuvent alors servir à exécuter des
machines virtuelles ou des conteneurs supplémentaires.
Types de trafic applicables : stockage hôte
Certifications requises : Stockage (Standard)
Tous les adaptateurs avec qualification Stockage (Standard) ou Stockage (Premium) prennent en
charge RDMA côté hôte. Pour plus d’informations sur l’utilisation de RDMA avec des charges de travail
invitées, consultez la section « RDMA invité » plus loin dans cet article.
Azure Stack HCI prend en charge RDMA avec les implémentations de protocole Internet Wide Area
RDMA Protocol (iWARP) ou RDMA over Converged Ethernet (RoCE).
） Important
Les adaptateurs RDMA fonctionnent uniquement avec d’autres adaptateurs RDMA qui
implémentent le même protocole RDMA (iWARP ou RoCE).
Toutes les cartes réseau des fournisseurs ne prennent pas en charge la fonctionnalité RDMA. Le
tableau suivant répertorie les fournisseurs (par ordre alphabétique) qui proposent des adaptateurs
RDMA certifiés. Toutefois, il existe des fabricants de matériel qui ne figurent pas dans cette liste et
prennent également en charge la fonctionnalité RDMA. Consultez le catalogue Windows Server pour
trouver des adaptateurs avec la qualification Stockage (Standard) ou Stockage (Premium) qui
nécessitent la prise en charge de RDMA.
７ Notes
InfiniBand (IB) n’est pas pris en charge avec Azure Stack HCI.
Fournisseur de cartes réseau iWARP RoCE
Broadcom Non Oui
Intel Oui Oui (certains modèles)
Marvell (Qlogic) Oui Oui
Nvidia Non Oui
Pour plus d’informations sur le déploiement de RDMA pour l’hôte, nous vous recommandons vivement
d’utiliser Network ATC. Pour plus d’informations sur le déploiement manuel, consultez le dépôt GitHub
SDN .
iWARP
iWARP utilise le protocole TCP (Transmission Control Protocol) et peut éventuellement être amélioré
avec les standards PFC (Priority-based Flow Control) et ETS (Enhanced Transmission Service).
Utilisez iWARP si :
Vous n’avez pas d’expérience dans la gestion des réseaux RDMA.

Vous ne gérez pas ou n’êtes pas à l’aise de gérer vos commutateurs toR (top-of-rack).
Vous n’êtes pas la personne qui gère la solution après le déploiement.
Vous avez déjà effectué des déploiements utilisant iWARP.
Vous ne savez pas quelle option choisir.
RoCE
RoCE utilise le protocole UDP (User Datagram Protocol) et demande à PFC et ETS d’assurer sa fiabilité.
Utilisez RoCE si :
Votre centre de données comporte déjà des déploiements avec RoCE.

Vous êtes à l’aise avec la gestion de la configuration réseau DCB requise.
RDMA invité
La fonctionnalité RDMA invité permet aux charges de travail SMB pour machines virtuelles de
bénéficier des avantages offerts par la technologie RDMA sur les hôtes.
Types de trafic applicables : stockage basé sur l’invité
Certifications requises : Calcul (Premium)
Voici les principaux avantages de la fonctionnalité RDMA invité :
Déchargement du processeur sur la carte d’interface réseau pour le traitement du trafic réseau.
Latence extrêmement faible.
Débit élevé.
Pour plus d’informations, téléchargez le document depuis le Référentiel SDN GitHub .
SET
SET (Switch Embedded Teaming ) est une technologie d’association basée sur des logiciels qui a été
intégrée dans le système d’exploitation Windows Server depuis la version Windows Server 2016. SET
nécessite un adaptateur de calcul (Standard) ou de calcul (Premium).
Types de trafic applicables : calcul, stockage et gestion
Certifications requises : Calcul (Standard) ou Calcul (Premium)
La fonctionnalité SET est la seule technologie d’association prise en charge par Azure Stack HCI. La
fonctionnalité SET fonctionne avec le trafic de calcul, de stockage et de gestion.
） Important
Azure Stack HCI ne prend pas en charge l’association de cartes réseau avec l’ancien LBFO (Load
Balancing/Failovering). Pour plus d’informations sur la technologie LBFO dans Azure Stack HCI,
consultez le billet de blog Association dans Azure Stack HCI .
La technologie SET est importante pour Azure Stack HCI, car il s’agit de la seule technologie
d’association qui donne accès aux fonctionnalités suivantes :
Association d’adaptateurs RDMA (si nécessaire).

RDMA invité.
Dynamic VMMQ.
Autres fonctionnalités clés d’Azure Stack HCI (voir Association dans Azure Stack HCI ).
SET nécessite l’utilisation d’adaptateurs symétriques (identiques). Les cartes réseau symétriques sont
celles qui présentent les mêmes caractéristiques :
Marque (fournisseur)
Modèle (version)
Vitesse (débit)
configuration
Dans 22H2, Network ATC détecte automatiquement et vous informe si les cartes que vous avez
choisies sont asymétriques. Le moyen le plus simple d’identifier manuellement si les adaptateurs sont
symétriques est de savoir si les vitesses et les descriptions d’interface correspondent exactement . Ils
ne peuvent différer que par le chiffre indiqué dans la description. Utilisez la cmdlet Get-
NetAdapterAdvancedProperty pour vérifier que la configuration signalée présente les mêmes valeurs
de propriété.
Dans le tableau suivant figure un exemple de descriptions d’interface qui ne diffèrent que par le
chiffre :
Nom Description de l’interface Vitesse de liaison
NIC1 Carte réseau 1 25 Gbits
７ Notes
SET prend uniquement en charge la configuration indépendante du commutateur à l’aide des

algorithmes d’équilibrage de charge Port Hyper-V ou Dynamic. Pour bénéficier de performances
optimales, nous vous recommandons d’utiliser Port Hyper-V sur toutes les cartes réseau qui
opèrent à 10 Gbits/s ou plus. Network ATC effectue toutes les configurations requises pour SET.
Considérations relatives au trafic RDMA

Si vous implémentez DCB, vous devez vous assurer que la configuration PFC et ETS est correctement
implémentée sur chacun des ports réseau, notamment les commutateurs réseau. Les standards DCB
sont obligatoires pour le protocole RoCE et facultatifs pour le protocole iWARP.
Pour plus d’informations sur le déploiement de la fonctionnalité RDMA, téléchargez le document

depuis le Référentiel GitHub SDN .
Les implémentations d’Azure Stack HCI basées sur le protocole RoCE nécessitent la configuration de
trois classes de trafic PFC, notamment la classe de trafic par défaut, sur l’ensemble de la structure et
des hôtes.
Classe de trafic de cluster
Cette classe de trafic garantit une bande passante réservée suffisante pour les pulsations de cluster :
Obligatoire : oui
Compatible avec PFC : non
Priorité de trafic recommandée : Priorité 7
Réservation de bande passante recommandée :
Réseaux RDMA de 10 GbE ou moins = 2 pour cent
Réseaux RDMA de 25 GbE ou moins = 1 pour cent
Classe de trafic RDMA

Cette classe de trafic garantit une bande passante réservée suffisante pour les communications RDMA
sans perte en utilisant SMB Direct :
Obligatoire : oui
Compatible avec PFC : oui
Priorité de trafic recommandée : Priorité 3 ou 4
Réservation de bande passante recommandée : 50 pour cent
Classe de trafic par défaut
Cette classe de trafic couvre tous les autres types de trafic non définis dans le cluster ni dans les
classes de trafic RDMA, notamment le trafic des machines virtuelles et le trafic de gestion :
Requis : Par défaut (aucune configuration nécessaire sur l’hôte)

Compatible avec PFC (contrôle de flux prioritaire) : non
Classe de trafic recommandée : Par défaut (Priorité 0)
Réservation de bande passante recommandée : Par défaut (aucune configuration nécessaire sur
l’hôte)
Modèles de trafic de stockage

En tant que protocole de stockage pour Azure Stack HCI, le protocole SMB offre de nombreux
avantages, notamment SMB Multichannel. SMB Multichannel n’est pas discuté dans cette rubrique.
Cependant, il est important de comprendre que le trafic est multiplexé sur chacune des liaisons
possibles utilisées par SMB Multichannel.
７ Notes
Nous vous recommandons d’utiliser plusieurs sous-réseaux et réseaux VLAN pour séparer le trafic
de stockage dans Azure Stack HCI.
Prenons l’exemple d’un cluster à quatre nœuds. Chaque serveur possède deux ports de stockage (à
gauche et à droite). Étant donné que chaque adaptateur se trouve sur le même sous-réseau et le
même réseau VLAN, SMB Multichannel répartit les connexions entre toutes les liaisons disponibles. Par
conséquent, le port situé à gauche sur le premier serveur (192.168.1.1) établit une connexion avec le
port de gauche du deuxième serveur (192.168.1.2). Le port qui se trouve à droite sur le premier serveur
(192.168.1.12) établit une connexion avec le port de droite du deuxième serveur. Des connexions
similaires sont établies pour le troisième et le quatrième serveurs.
Cela crée toutefois des connexions inutiles et provoque une congestion au niveau de l’interlien
(groupe d’agrégation de liens à plusieurs châssis ou MC-LAG) qui connecte les commutateurs ToR
(marqués par des X). Consultez le diagramme suivant :

L’approche recommandée consiste à utiliser des sous-réseaux et des réseaux VLAN distincts pour
chaque ensemble d’adaptateurs. Dans le diagramme suivant, les ports de droite utilisent désormais le
sous-réseau 192.168.2.x /24 et VLAN2. Cela permet au trafic des ports de gauche de rester sur TOR1 et
à celui des ports de droite de rester sur TOR2.

Allocation de bande passante au trafic

Le tableau suivant donne des exemples d’allocations de bande passante de différents types de trafic,
avec des vitesses d’adaptateur courantes, dans Azure Stack HCI. Notez qu’il s’agit d’un exemple d’une
solution convergée dans laquelle tous les types de trafic (calcul, stockage et gestion) s’exécutent sur les
mêmes adaptateurs physiques et sont associés à l’aide de la fonctionnalité SET.
Puisque ce cas d’usage est celui qui impose le plus de contraintes, il constitue une bonne ligne de
base. Toutefois, en prenant en compte les permutations du nombre d’adaptateurs et des vitesses, il
doit être considéré comme un exemple et non comme une configuration requise pour la prise en
charge.
Cet exemple repose sur les hypothèses suivantes :
Il existe deux adaptateurs par équipe.
Le trafic SBL (Storage Bus Layer), le trafic de Volume partagé de cluster (CSV) et le trafic Hyper-V
(Migration dynamique) :
utilisent les mêmes adaptateurs physiques ;
utilisent le protocole SMB.
SMB reçoit une allocation de bande passante de 50 % en utilisant DCB.
SBL/CSV est la trafic à la priorité la plus élevée et reçoit 70 % de la réservation de bande
passante SMB.
La Migration dynamique (LM) est limitée en utilisant la cmdlet Set-SMBBandwidthLimit et reçoit
29 % de la bande passante restante.
Si la bande passante disponible pour la Migration dynamique est >= 5 Gbits/s et que les
cartes réseau sont compatibles, optez pour la fonctionnalité RDMA. Utilisez pour cela la
cmdlet suivante :
Powershell
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Si la bande passante disponible pour la Migration dynamique est < 5 Gbits/s, appliquez une
compression pour réduire les durées d’indisponibilité. Utilisez pour cela la cmdlet suivante :
Powershell
Set-VMHost -VirtualMachineMigrationPerformanceOption Compression
Si vous utilisez la fonctionnalité RDMA avec la trafic de Migration dynamique, assurez-vous que
le trafic de Migration dynamique ne peut pas utiliser toute la bande passante allouée à la classe
de trafic RDMA grâce à une limite de bande passante SMB. Soyez prudent, car cette cmdlet
prend une entrée en octets par seconde (octets/s), tandis que les cartes réseau sont répertoriées
en bits par seconde (bits/s). Utilisez la cmdlet suivante pour définir une limite de bande passante
de 6 Gbit/s, par exemple :
Powershell
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MB
７ Notes
750 Mbits/s dans cet exemple équivaut à 6 Gbit/s.
Voici le tableau d’allocation des exemples de bande passante :
Vitesse de Bande Réservation % Bande % Bande % Bande

la carte passante de bande SBL/CSV passante Migration passante pulsations passante
réseau associée passante SBL/CSV dynamique Migration des
SMB** dynamique pulsations
maximale
10 Gbits/s 20 Gbits/s 10 Gbits/s 70 % 7 Gbits/s ** 200 Mbits/s
25 Gbits 50 Gbit/s 25 Gbits 70 % 17,5 29 % 7,25 Gbit/s 1% 250 Mbit/s

Gbit/s
Vitesse de Bande Réservation % Bande % Bande % Bande
la carte passante de bande SBL/CSV passante Migration passante pulsations passante
réseau associée passante SBL/CSV dynamique Migration des
SMB** dynamique pulsations
maximale
40 Gbits/s 80 Gbit/s 40 Gbits/s 70 % 28 Gbit/s 29 % 11,6 Gbit/s 1% 400 Mbit/s
50 Gbit/s 100 Gbits/s 50 Gbit/s 70 % 35 Gbit/s 29 % 14,5 Gbit/s 1% 500 Mbits/s
100 Gbits/s 200 Gbits/s 100 Gbits/s 70 % 70 Gbit/s 29 % 29 Gbit/s 1% 1 Gbit/s
200 Gbits/s 400 Gbit/s 200 Gbits/s 70 % 140 Gbit/s 29 % 58 Gbit/s 1% 2 Gbit/s
Utilisez la compression plutôt que la fonctionnalité RDMA, car l’allocation de bande passante pour le
trafic de Migration dynamique est < 5 Gbits/s.
** 50 % est un exemple de réservation de bande passante.
Clusters étendus
Les clusters étendus offrent une récupération d’urgence couvrant plusieurs centres de données. Dans
sa forme la plus simple, un réseau en cluster Azure Stack HCI étendu se présente ainsi :
Exigences des clusters étendus

Les clusters étendus présentent les exigences et caractéristiques suivantes :
La fonctionnalité RDMA est limitée à un seul site et n’est pas prise en charge sur différents sites
ou sous-réseaux.
Les serveurs du même site doivent se trouver dans le même rack et la même limite de couche 2.
La communication d’hôte entre les sites doit franchir une limite de couche 3 ; les topologies de
couche 2 étendues ne sont pas prises en charge.
Disposez d’une bande passante suffisante pour exécuter les charges de travail sur l’autre site. En
cas de basculement, l’autre site doit exécuter tout le trafic. Nous vous recommandons
d’approvisionner les sites à 50 % de leur capacité réseau disponible. Ce n’est toutefois pas une
exigence si vous pouvez tolérer un niveau de performance inférieur au cours d’un basculement.
La réplication entre les sites (trafic nord/sud) peut utiliser les mêmes cartes réseau physiques que
le stockage local (trafic est/ouest). Si vous utilisez les mêmes adaptateurs physiques, ils doivent
être associés à SET. Les adaptateurs doivent aussi disposer de cartes réseau virtuelles
supplémentaires provisionnées pour le trafic routable entre les sites.
Les adaptateurs utilisés pour la communication entre sites présentent les caractéristiques
suivantes :
Ils peuvent être physiques ou virtuels (carte réseau virtuelle hôte). Si les adaptateurs sont
virtuels, vous devez approvisionner une carte d’interface réseau virtuelle dans son propre
sous-réseau et son propre réseau VLAN par carte d’interface réseau physique.
Ils doivent se trouver sur leur propre sous-réseau et leur propre réseau VLAN qui peuvent être
acheminés entre les sites.
La fonctionnalité RDMA doit être désactivée en utilisant la cmdlet Disable-NetAdapterRDMA .

Nous vous recommandons de demander explicitement au réplica de stockage d’utiliser des
interfaces spécifiques en utilisant la cmdlet Set-SRNetworkConstraint .
Ils doivent satisfaire à toutes les exigences supplémentaires liées au réplica de stockage.
Exemple de cluster étendu

L’exemple suivant montre une configuration de cluster étendu. Pour vous assurer qu’une carte réseau
virtuelle spécifique est mappée à un adaptateur physique spécifique, utilisez la cmdlet Set-
VMNetworkAdapterTeammapping.

L’exemple suivant montre les détails de l’exemple de configuration du cluster étendu.
７ Notes
Votre configuration exacte, notamment les noms de cartes d’interface réseau, les adresses IP et les
réseaux VLAN, peut être différente de ce qui est indiqué. Il s’agit uniquement d’une configuration
de référence pouvant être adaptée à votre environnement.
SiteA – Réplication locale, fonctionnalité RDMA activée, non routable entre

sites
Nom du Nom de la carte d’interface Carte d’interface réseau VLAN IP et sous- Étendue du
nœud réseau virtuelle physique (mappée) réseau trafic
NodeA1 vSMB01 pNIC01 711 192.168.1.1/24 Site local

uniquement

uniquement

uniquement

uniquement
SiteB – Réplication locale, fonctionnalité RDMA activée, non routable entre

sites
NodeB1 vSMB01 pNIC01 711 192.168.1.1/24 Site local

uniquement

uniquement

uniquement

uniquement
SiteA – Réplication étendue, fonctionnalité RDMA désactivée, routable entre

sites
Nom du Nom de la carte d’interface Carte d’interface réseau IP et sous- Étendue du

NodeA1 Stretch1 pNIC01 173.0.0.1/8 Routable

entre sites

entre sites

entre sites

entre sites
SiteB : réplication étendue, RDMA désactivé, routable entre les sites

NodeB1 Stretch1 pNIC01 175.0.0.1/8 Routable

entre sites

entre sites

entre sites

entre sites
Étapes suivantes
Pour plus d’informations sur les exigences liées aux commutateurs réseau et aux réseaux
physiques, consultez Exigences liées aux réseaux physiques.
Apprenez à simplifier la mise en réseau des hôtes à l’aide de Network ATC. Consultez Simplifier la
mise en réseau des hôtes avec Network ATC.
Rafraîchissez vos connaissances sur les Notions de base sur les réseaux de clustering de
basculement .
Pour le déploiement, consultez Création d’un cluster avec Windows Admin Center.
Pour le déploiement, consultez Création d’un cluster avec Windows PowerShell.
Article • 09/03/2023
Vous pouvez utiliser cette rubrique pour accéder au contenu de gestion des
commutateurs virtuels Hyper-V.
Cette section contient les rubriques suivantes :
Configurer des réseaux locaux virtuels (VLAN) sur des ports de commutateurs
virtuels Hyper-V
Créer des stratégies de sécurité avec des listes de contrôle d’accès de ports
étendues
Créer des stratégies de sécurité avec les
listes de contrôle d’accès de ports
étendues
Article • 17/04/2023
Cette rubrique fournit des informations sur les listes de contrôle d’accès (ACL) de ports
étendus dans Windows Server 2016. Vous pouvez configurer les listes de contrôle
d’accès étendues sur le commutateur virtuel Hyper-V pour autoriser et bloquer le trafic
réseau depuis et vers les ordinateurs virtuels (VM) qui sont connectés au commutateur
via les cartes réseau virtuelles.
Cette rubrique contient les sections suivantes.
Règles ACL détaillées
Règles ACL avec état
Règles ACL détaillées

Les listes de contrôle d’accès (ACL) étendues du commutateur virtuel Hyper-V
permettent de créer des règles détaillées que vous pouvez appliquer à des cartes réseau
d’ordinateur virtuel individuelles connectées au commutateur virtuel Hyper-V. La
possibilité de créer des règles détaillées permet aux fournisseurs de services d’entreprise
et Cloud de répondre aux menaces de sécurité sur le réseau dans un environnement
serveur partagé mutualisé.
Grâce aux listes de contrôle d’accès étendues, au lieu de créer des règles qui bloquent
ou autorisent tout le trafic de tous les protocoles depuis et vers un ordinateur virtuel,
vous pouvez désormais bloquer ou autoriser individuellement le trafic réseau de chaque
protocole qui s’exécute sur les ordinateurs virtuels. Vous pouvez créer des règles de
listes de contrôle d’accès étendues dans Windows Server 2016 qui comprennent les
ensembles de paramètres 5-tuple suivants : adresse IP source, adresse IP de destination,
protocole, port source et port de destination. De plus, chaque règle peut indiquer le
sens du trafic réseau (entrant ou sortant) et l’action prise en charge par la règle
(autoriser ou bloquer le trafic).
Par exemple, vous pouvez configurer des listes de contrôle d’accès de port pour un
ordinateur virtuel qui autorisent tout le trafic HTTP et HTTPS entrant et sortant sur le
port 80, et bloquent le trafic réseau de tous les autres protocoles sur tous les ports.
La possibilité de pouvoir identifier le trafic du protocole qui peut ou ne peut pas être
reçu par les ordinateurs virtuels clients vous offre davantage de flexibilité lors de la
configuration des stratégies de sécurité.
Configuration de règles ACL avec Windows PowerShell

Pour configurer une ACL étendue, vous devez utiliser la commande Windows PowerShell
Add-VMNetworkAdapterExtendedAcl. Cette commande utilise quatre syntaxes
distinctes, avec une utilisation spécifique pour chaque syntaxe :
1. Ajouter une ACL étendue à toutes les cartes réseau d’un ordinateur virtuel nommé
- spécifié par le premier paramètre, -VMName. Syntaxe :
７ Notes
Si vous souhaitez ajouter une ACL étendue à une carte réseau plutôt qu’à
toutes les cartes réseau, vous pouvez spécifier la carte réseau avec le
paramètre -VMNetworkAdapterName.
Add-VMNetworkAdapterExtendedAcl [-VMName] <string[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow | Deny}
[-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-
RemotePort] <string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-VMNetworkAdapterName
<string>] [-ComputerName <string[]>] [-WhatIf] [-Confirm]
[<CommonParameters>]
2. Ajouter une ACL étendue à une carte réseau virtuelle spécifique sur un ordinateur
virtuel spécifique. Syntaxe :
Add-VMNetworkAdapterExtendedAcl [-VMNetworkAdapter]
<VMNetworkAdapterBase[]> [-Action]
<VMNetworkAdapterExtendedAclAction> {Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound |
Outbound} [[-LocalIPAddress] <string>] [[-RemoteIPAddress]
<string>] [[-LocalPort] <string>] [[-RemotePort]
<string>] [[-Protocol] <string>] [-Weight] <int> [-Stateful <bool>]
[-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-WhatIf] [-Confirm] [<CommonParameters>]
3. Ajoutez une ACL étendue à toutes les cartes réseau virtuelles qui sont réservées à
une utilisation par le système d’exploitation de gestion hôte Hyper-V.
７ Notes
Si vous souhaitez ajouter une ACL étendue à une carte réseau plutôt qu’à
toutes les cartes réseau, vous pouvez spécifier la carte réseau avec le
paramètre -VMNetworkAdapterName.
Add-VMNetworkAdapterExtendedAcl [-Action]
<VMNetworkAdapterExtendedAclAction> {Allow | Deny} [-Direction]
<VMNetworkAdapterExtendedAclDirection> {Inbound | Outbound} [[-
LocalIPAddress] <string>] [[-RemoteIPAddress]
<string>] [[-LocalPort] <string>] [[-RemotePort] <string>] [[-
Protocol] <string>] [-Weight] <int> -ManagementOS
[-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID <int>]
[-Passthru] [-VMNetworkAdapterName <string>]
[-ComputerName <string[]>] [-WhatIf] [-Confirm]
[<CommonParameters>]
4. Ajouter une ACL étendue à un objet ordinateur virtuel que vous avez créé dans
Windows PowerShell, par exemple $vm = get-vm "my_vm". Dans la prochaine
ligne de code, vous pouvez exécuter cette commande pour créer une ACL étendue
avec la syntaxe suivante :
Add-VMNetworkAdapterExtendedAcl [-VM] <VirtualMachine[]> [-Action]

<VMNetworkAdapterExtendedAclAction> {Allow |
Deny} [-Direction] <VMNetworkAdapterExtendedAclDirection> {Inbound
| Outbound} [[-LocalIPAddress] <string>]
[[-RemoteIPAddress] <string>] [[-LocalPort] <string>] [[-
RemotePort] <string>] [[-Protocol] <string>] [-Weight]
<int> [-Stateful <bool>] [-IdleSessionTimeout <int>] [-IsolationID
<int>] [-Passthru] [-VMNetworkAdapterName
<string>] [-WhatIf] [-Confirm] [<CommonParameters>]
Exemples de règle ACL détaillée
Vous trouverez ci-dessous plusieurs exemples d’utilisation de la commande Add-
VMNetworkAdapterExtendedAcl pour configurer les ACL de port étendues et pour
créer des stratégies de sécurité pour les ordinateurs virtuels.
Mettre en œuvre une sécurité au niveau de l’application
Mettre en œuvre une sécurité au niveau de l’application et de l’utilisateur
Fournir une prise en charge de la sécurité pour une application non-TCP/UDP
７ Notes
Les valeurs pour le paramètre de règle Direction dans les tableaux ci-dessous sont
basées sur le flux de trafic depuis et vers l’ordinateur virtuel pour lequel vous créez
la règle. Si l’ordinateur virtuel reçoit du trafic, le trafic est entrant ; si l’ordinateur
virtuel envoie du trafic, le trafic est sortant. Par exemple, si vous appliquez une
règle à un ordinateur virtuel qui bloque le trafic entrant, la direction du trafic
entrant s’entend des ressources externes vers l’ordinateur virtuel. Si vous appliquez
une règle qui bloque le trafic sortant, la direction du trafic sortant s’entend de
l’ordinateur virtuel local vers les ressources externes.

Dans la mesure où de nombreux serveurs d’applications utilisent les ports TCP/UDP
standard avec des ordinateurs clients, il est facile de créer des règles qui bloquent ou
autorisent l’accès à un serveur d’applications en filtrant le trafic qui arrive et qui part du
port indiqué à l’application.
Par exemple, vous voulez autoriser un utilisateur à se connecter à un serveur

d’applications dans votre centre de données en utilisant une connexion Bureau à
distance (RDP, Remote Desktop Connection). Dans la mesure où RDP utilise le port
TCP 3389, vous pouvez rapidement créer la règle suivante :
IP IP de Protocol Port Port de Sens Action

Source destination source destination
* * TCP * 3389 Dans Autoriser
Vous trouverez ci-dessous deux exemples de création de règles avec des commandes
Windows PowerShell. Le premier exemple de règle bloque tout le trafic vers l’ordinateur
virtuel nommé « ApplicationServer ». Le deuxième exemple de règle, qui est appliqué à
la carte réseau de l’ordinateur virtuel nommé « ApplicationServer », autorise
uniquement le trafic RDP entrant vers l’ordinateur virtuel.
７ Notes
Quand vous créez des règles, vous pouvez utiliser le paramètre -Weight pour
déterminer l’ordre de traitement des règles par le commutateur virtuel Hyper-V. Les
valeurs pour -Weight sont des entiers ; les règles avec un nombre entier plus élevé
sont traitées avant les autres. Par exemple, si vous avez appliqué deux règles à une
carte réseau d’ordinateur virtuel, une avec une pondération de 1 et l’autre avec une
pondération de 10, la règle avec la pondération de 10 est appliquée en premier.
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -

Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow"
-Direction "Inbound" -LocalPort 3389 -Protocol "TCP" -Weight 10

et de l’utilisateur
Dans la mesure où une règle peut correspondre à un paquet IP 5-tuple (IP source, IP de
destination, protocole, port source et port de destination), la règle peut mettre en
œuvre une stratégie de sécurité plus détaillée qu’une ACL de port.
Par exemple, si vous voulez fournir un service DHCP à un nombre limité d’ordinateurs
clients en utilisant un ensemble spécifique de serveurs DHCP, vous pouvez configurer
les règles suivantes sur le l’ordinateur Windows Server 2016 qui exécute Hyper-V, sur
lequel les ordinateurs virtuels utilisateur sont hébergés :
IP Source IP de Protocol Port Port de Sens Action

destination source destination
* 255.255.255.255 UDP * 67 Sortie Autoriser
* 10.175.124.0/25 UDP * 67 Sortie Autoriser
10.175.124.0/25 * UDP * 68 Dans Autoriser
Vous trouverez ci-dessous des exemples de création de ces règles avec des commandes
Windows PowerShell.
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Deny" -
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Outbound" -RemoteIPAddress 255.255.255.255 -RemotePort 67 -
Protocol "UDP"-Weight 10
Direction "Outbound" -RemoteIPAddress 10.175.124.0/25 -RemotePort 67 -
Direction "Inbound" -RemoteIPAddress 10.175.124.0/25 -RemotePort 68 -
Fournir une prise en charge de la sécurité pour une

application non-TCP/UDP
Bien que la grande majorité du trafic réseau dans un centre données utilise TCP et UDP,
d’autres protocoles peuvent être utilisés. Par exemple, si vous voulez autoriser un
groupe de serveurs à exécuter une application de multidiffusion IP qui utilise le
protocole IGMP (Internet Group Management Protocol), vous pouvez créer la règle
suivante.
７ Notes
Le numéro de protocole IP de IGMP est 0x02.
IP IP de Protocol Port Port de Sens Action

Source destination source destination
* * 0x02 * * Dans Autoriser
* * 0x02 * * Sortie Autoriser
Vous trouverez ci-dessous un exemple de création de ces règles avec des commandes
Windows PowerShell.

Direction "Inbound" -Protocol 2 -Weight 20
Direction "Outbound" -Protocol 2 -Weight 20
Règles ACL avec état
Les ACL étendues permettent désormais de configurer des règles avec état. Une règle
avec état filtre les paquets en fonction de cinq attributs dans un paquet : IP source, IP de
destination, protocole, port source et port de destination.
Les règles avec état ont les particularités suivantes :
Elles autorisent toujours le trafic et ne sont pas utilisées pour bloquer le trafic.
Si vous indiquez que la valeur du paramètre Direction est entrant et que le trafic
correspond à la règle, le commutateur virtuel Hyper-V crée dynamiquement une
règle correspondante qui autorise l’ordinateur virtuel à envoyer le trafic sortant en
réponse à la ressource externe.
Si vous indiquez que la valeur du paramètre Direction est sortant et que le trafic
correspond à la règle, le commutateur virtuel Hyper-V crée dynamiquement une
règle correspondante qui autorise la réception du trafic entrant de la ressource
externe par l’ordinateur virtuel.
Elles comprennent un attribut de délai d’attente en secondes. Quand un paquet

réseau arrive sur le commutateur et que le paquet correspond à une règle avec
état, le commutateur virtuel Hyper-V crée un état afin que tous les paquets
suivants dans les deux directions du flux soient autorisés. L’état expire si aucun
trafic ne se produit dans l’une ou l’autre direction pendant la période de temps
spécifiée par la valeur de délai d’attente.
Voici un exemple de l’utilisation des règles avec état.
Autoriser le trafic serveur distant entrant uniquement

après avoir été contacté par le serveur local
Dans certains cas, une règle avec état doit être utilisée, car elle seule peut suivre une
connexion établie connue et distinguer cette connexion des autres connexions.
Par exemple, si vous voulez autoriser un serveur d’applications VM à initier des

connexions sur le port 80 vers les services Web sur Internet, et que vous voulez que les
serveurs Web distants puissent répondre au trafic VM, vous pouvez configurer une règle
avec état qui autorise le trafic sortant initial de l’ordinateur virtuel vers les services Web ;
la règle étant avec état, le trafic retourné de l’ordinateur virtuel à partir des serveurs
Web est également autorisé. Pour des raisons de sécurité, vous pouvez bloquer tout le
reste du trafic entrant vers l’ordinateur virtuel.
Pour obtenir cette configuration de règle, vous pouvez utiliser les paramètres du tableau
ci-dessous.
７ Notes
En raison de limitations de mise en forme et de la quantité d’informations

présentée dans le tableau ci-dessous, les informations ne sont pas affichées comme
dans les précédents tableaux de ce document.
Paramètre Règle 1 Règle 2 Règle 3
IP Source * * *
IP de destination * * *
Protocol * * TCP
Port source * * *
Port de destination * * 80
Sens Dans Sortie Sortie
Action Deny Deny Autoriser
Avec état Non Non Oui
Délai d’attente (en secondes) N/A N/A 3600
La règle avec état autorise la connexion du serveur d’applications VM au serveur Web

distant. Quand le premier paquet est envoyé, le commutateur virtuel Hyper-V crée
dynamiquement deux états de flux pour autoriser tous les paquets envoyés au serveur
Web distant et retournés par lui. Quand le flux de paquets entre les serveurs s’arrête, les
états de flux dépassent le délai d’attente de 3 600 secondes, ou une heure.
Vous trouverez ci-dessous un exemple de création de ces règles avec des commandes
Windows PowerShell.

Direction "Inbound" -Weight 1
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow"
-Direction "Outbound" 80 "TCP" -Weight 100 -Stateful -Timeout 3600

Windows Server Virtualization

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Windows Server Virtualization

Transféré par

Droits d'auteur :

Formats disponibles

Parlez-nous de l’expérience de téléchargement de PDF.

Documentation sur la virtualisation

À propos des conteneurs Windows

Conteneurs ou machines virtuelles

Hyper-V sur Windows 10

Vue d’ensemble d’Hyper-V sur Windows 10

À propos d’Hyper-V sur Windows 10

Création d'une machine virtuelle

Hyper-V sur Windows Server

Hyper-V sur Windows Server

Vue d’ensemble de la technologie Hyper-V

Configuration requise pour Hyper-V sur Windows Server

Commutateur virtuel Hyper-V

Commutateur virtuel Hyper-V

Gérer le commutateur virtuel Hyper-V

Utiliser une infrastructure protégée afin de fournir un environnement

Structure protégée et machines virtuelles dotées d’une protection maximale

Vidéos, blog et rubrique de vue d’ensemble sur

Rubriques traitant du déploiement

Rubrique opérations et gestion

Le rôle Hyper-V dans Windows Server vous permet de créer un environnement

Ressources Hyper-V pour les professionnels de

- Présentation de la technologie Hyper-V

Planifier pour Hyper-V

- Dois-je créer une machine virtuelle de génération 1 ou 2 dans Hyper-V ?

Bien démarrer avec Hyper-V

- Télécharger et installer Windows Server 2019

Option d’installation minimale ou avec interface graphique de Windows Server 2019

- Installer le rôle Hyper-V sur Windows Server

Mettre à niveau des ordinateurs hôtes et des machines virtuelles Hyper-V

- Mettre à niveau des nœuds de cluster Windows Server

Configurer et gérer Hyper-V

- Configurer des hôtes une migration dynamique sans clustering de basculement

Consultez les dernières publications des responsables de programme, des chefs de

Forum et groupes de discussion

- Communauté Windows Server

Client Technologie de virtualisation incluse avec Windows 8, Windows 8.1 et Windows 10

S’applique à : Windows Server 2022, Windows Server 2016, Microsoft Hyper-V

Hyper-V est le produit de virtualisation de matériel de Microsoft. Il vous permet de créer

Comment Hyper-V peut vous aider

Établir ou développer un environnement de nuage privé. Fournir des services

Établir ou développer une infrastructure VDI (Virtual Desktop Infrastructure).

Rendre le développement et les tests plus efficaces. Reproduire différents

Hyper-V et les autres produits de virtualisation

Quelles sont les fonctionnalités d’Hyper-V ?

Environnement informatique : une machine virtuelle Hyper-V comprend les mêmes

Récupération d’urgence et sauvegarde : pour la récupération d’urgence, le réplica

Optimisation : chaque système d’exploitation invité pris en charge dispose d’un

Portabilité : des fonctionnalités comme la migration dynamique, la migration du

Connectivité à distance : Hyper-V inclut la connexion de machine virtuelle, un outil de

Sécurité : le démarrage sécurisé et les machines virtuelles protégées permettent de se

Comment obtenir Hyper-V

Systèmes d’exploitation pris en charge

En quoi consiste Hyper-V ?

Différentes technologies de stockage : volumes partagés de cluster, SMB 3.0, espaces de

Les conteneurs Windows offrent une autre approche de la virtualisation. Consultez la

S’applique à : Windows Server 2022, Windows Server 2019, Microsoft Hyper-V

Cet article explique les nouveautés et les modifications apportées au fonctionnement

Windows Server, version 1903

Ajouter le Gestionnaire Hyper-V aux installations Server

Pour plus d’informations, consultez Fonctionnalité à la demande de compatibilité des

Windows Server 2019

Le mode hors connexion vous permet de continuer à démarrer vos machines

Améliorations de la résolution des problèmes