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

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

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

ｅ VUE D’ENSEMBLE

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

ｅ VUE D’ENSEMBLE

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 • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ 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 s’exécutant 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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Vue d’ensemble de la technologie
Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
and 22H2

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
Client Hyper-V

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Vue d’ensemble de la technologie
Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
and 22H2

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
Client Hyper-V

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Nouveautés de Windows Server 2022
Article • 10/07/2024 • S’applique à: ✅ Windows Server 2022

Cet article décrit certaines des nouvelles fonctionnalités de Windows Server 2022.
Windows Server 2022 repose sur les bases solides de Windows Server 2019 et apporte
de nombreuses innovations dans trois domaines clés : la sécurité, l'intégration et la
gestion hybrides Azure, et la plateforme d'applications.

Édition Azure
Windows Server 2022 Datacenter: Azure Edition vous permet de tirer parti des
avantages du cloud en maintenant vos machines virtuelles à jour tout en réduisant les
temps d'arrêt. Cette section décrit certaines des nouvelles fonctionnalités de Windows
Server 2022 Datacenter: Azure Edition. En savoir plus sur la façon dont Azure
Automanage pour Windows Server intègre ces nouvelles fonctionnalités à Windows
Server Azure Edition dans l’article Azure Automanage pour les services Windows Server.

Windows Server 2022 Datacenter: Azure Edition s’appuie sur Datacenter Edition pour
fournir un système d’exploitation uniquement de machine virtuelle qui permet d’utiliser
les avantages du cloud, avec des fonctionnalités avancées telles que SMB sur QUIC,
Hotpatch et Azure Extended Networking. Cette section décrit certaines de ces nouvelles
fonctionnalités.

Comparez les différentes éditions de Windows Server 2022. Vous pouvez également en
savoir plus sur la façon dont Azure Automanage pour Windows Server intègre ces
nouvelles fonctionnalités à Windows Server Azure Edition dans l’article Azure
Automanage pour les services Windows Server.

Avril 2023

Mise à jour corrective à chaud

Windows Server 2022 Datacenter : Azure Edition Hotpatching est désormais disponible
en préversion publique pour l’expérience de bureau dans Azure et en tant que machine
virtuelle invitée prise en charge sur Azure Local version 22H2.

Septembre 2022
Cette section répertorie les fonctionnalités et améliorations qui sont désormais
disponibles dans Windows Server Datacenter: Azure Edition à compter de la mise à jour
cumulative 2022-09 pour le système d’exploitation serveur Microsoft version 21H2 pour
les systèmes x64 (KB5017381 ). Une fois la mise à jour cumulative installée, le numéro
de build du système d’exploitation sera 20348.1070 ou une version ultérieure.

Compression du réplica de stockage pour le transfert de données

Cette mise à jour inclut la compression du réplica de stockage pour les données
transférées entre les serveurs source et de destination. Cette nouvelle fonctionnalité
compresse les données de réplication à partir du système source, qui sont envoyées sur
le réseau, décompressées et enregistrées sur la destination. La compression entraîne
moins de paquets réseau pour transférer la même quantité de données, ce qui permet
d’augmenter le débit et de réduire l’utilisation du réseau. Un débit de données plus
élevé doit également réduire le temps de synchronisation pour le moment où vous en
avez besoin, par exemple dans un scénario de récupération d’urgence.

Les nouveaux paramètres PowerShell du réplica de stockage sont disponibles pour les
commandes existantes, consultez la référence Windows PowerShell StorageReplica pour
en savoir plus. Pour plus d’informations sur le réplica de stockage, consultez la Vue
d’ensemble du réplica de stockage.

Prise en charge d’Azure Local

Avec cette version, vous pouvez exécuter Windows Server 2022 Datacenter : Azure
Edition en tant que machine virtuelle invitée prise en charge sur Azure Local version
22H2. Avec Azure Edition s’exécutant sur Azure Local, vous pourrez utiliser toutes les
fonctionnalités existantes, notamment hotpatch pour Server Core et SMB sur QUIC à vos
emplacements de centre de données et de périphérie.

Commencez à déployer Windows Server 2022 Datacenter : Azure Edition en utilisant

Déployer depuis le Marketplace Azure sur Azure Local activé par Arc (aperçu) ou à l’aide
d’un fichier ISO. Vous pouvez télécharger l’ISO ici :

ISO Windows Server 2022 Datacenter: Azure Edition (EN-US)

ISO Windows Server 2022 Datacenter: Azure Edition (ZH-CN)

Votre abonnement Azure vous permet d’utiliser Windows Server Datacenter : Azure
Edition sur toutes les instances de machine virtuelle s’exécutant sur Azure Local. Pour
plus d’informations, consultez les conditions d’utilisation de votre produit Conditions
d’utilisation du produit .
En savoir plus sur les dernières fonctionnalités locales d’Azure dans notre article
Nouveautés d’Azure Local, version 22H2.

Déploiement à partir d'Azure Marketplace sur Azure Local

compatible avec Arc (prévisualisation)
Windows Server 2022 Datacenter : les images Azure Edition seront disponibles dans le
Marketplace Azure pour Azure Local habilité par Arc, ce qui rend facile l’essai, l’achat et
le déploiement via des images certifiées Azure.

En savoir plus sur l’intégration de la Place de marché Azure pour les fonctionnalités
azure Locales compatibles avec Azure Arc dans notre article Nouveautés d’Azure Local
version 22H2.

Azure Edition (version initiale)

Cette section répertorie les fonctionnalités et améliorations disponibles dans Windows
Server Datacenter: Azure Edition avec la version de septembre 2021.

Azure Automanage - Hotpatch

La mise à jour corrective à chaud, qui fait partie d’Azure Automanage, est une nouvelle
façon d’installer les mises à jour sur les nouvelles machines virtuelles Windows Server
Azure Edition, qui ne nécessite pas de redémarrage après l’installation. Pour plus
d'informations, consultez la documentation relative à Azure Automanage.

SMB sur QUIC

SMB sur QUIC met à jour le protocole SMB 3.1.1 pour utiliser le protocole QUIC au lieu
de TCP dans Windows Server 2022 Datacenter: Azure Edition, Windows 11 et versions
ultérieures et les clients tiers s’ils le prennent en charge. Lorsqu'ils utilisent SMB sur
QUIC avec TLS 1.3, les utilisateurs et les applications disposent d'un accès sécurisé et
fiable aux données des serveurs de fichiers Edge exécutés dans Azure. Les utilisateurs
mobiles et les télétravailleurs n'ont plus besoin d'un VPN pour accéder à leurs serveurs
de fichiers via SMB sous Windows. Pour plus d’informations, consultez la documentation
SMB sur QUIC et Gestion SMB sur QUIC avec les meilleures pratiques de machine
Automanage.

Pour en savoir plus sur QUIC, consultez RFC 9000 .

Réseau étendu pour Azure

Le réseau étendu Azure vous permet d’étirer un sous-réseau local dans Azure pour
permettre aux machines virtuelles locales de conserver leurs adresses IP privées locales
d’origine lors de la migration vers Azure. Pour en savoir plus, consultez Réseau étendu
Azure.

Toutes les éditions

Cette section décrit certaines des nouvelles fonctionnalités de Windows Server 2022
dans toutes les éditions. Pour en savoir plus sur les différentes éditions, consultez
l’article Comparaison des éditions Standard, Datacenter et Datacenter : éditions Azure
de Windows Server 2022.

Sécurité
Les nouvelles fonctionnalités de sécurité de Windows Server 2022 combinent d'autres
fonctionnalités de sécurité de Windows Server dans différents domaines afin de fournir
une défense en profondeur contre les menaces avancées. La sécurité multicouche
avancée de Windows Server 2022 offre la protection complète dont les serveurs ont
actuellement besoin.

Serveur Secured-core

Un matériel de serveur à noyau sécurisé certifié provenant d’un partenaire OEM fournit
des protections de sécurité supplémentaires qui sont utiles contre les attaques
sophistiquées. Un matériel de serveur à noyau sécurisé peut fournir des garanties
supplémentaires lors du traitement de données critiques dans certains secteurs
sensibles. Un serveur à noyau sécurisé utilise des fonctions de matériel, de
microprogramme et de pilote pour activer les fonctionnalités avancées de sécurité
Windows Server. La plupart de ces fonctionnalités sont disponibles dans les PC à noyau
sécurisé Windows et sont désormais également disponibles avec le matériel de serveur à
noyau sécurisé et Windows Server 2022. Pour plus d’informations sur les serveurs à
noyau sécurisé, consultez Serveur à noyau sécurisé.

Racine de confiance matérielle

Utilisées par des fonctionnalités comme le chiffrement de lecteur BitLocker, les puces de
processeur de chiffrement sécurisé du module de plateforme sécurisée 2.0 (TPM 2.0)
fournissent un magasin matériel sécurisé pour les clés de chiffrement et les données
sensibles, y compris des mesures de l’intégrité des systèmes. TPM 2.0 peut vérifier que
le serveur a été démarré avec du code légitime et qu’il peut être approuvé pour
l’exécution du code qui vient après cela, ce qui est connu sous le nom de « racine de
confiance matérielle ».

Protection des microprogrammes

Le microprogramme s’exécute avec des privilèges élevés et est souvent invisible pour les
solutions antivirus classiques, ce qui a entraîné une augmentation du nombre d’attaques
basées sur le microprogramme. Les serveurs à cœurs sécurisés mesurent et vérifient les
processus de démarrage avec la Technologie DRTM (Dynamic Root of Trust for
Measurement). Les serveurs à cœurs sécurisés peuvent également isoler l’accès des
pilotes à la mémoire avec la Protection d’accès direct à la mémoire (DMA).

Démarrage sécurisé UEFI

Le démarrage sécurisé UEFI est une norme de sécurité qui protège vos serveurs contre
les rootkits malveillants. Le démarrage sécurisé garantit que le serveur démarre
uniquement les microprogrammes et logiciels approuvés par le fabricant du matériel.
Lorsque le serveur est démarré, le microprogramme vérifie la signature de chaque
composant de démarrage, y compris les pilotes du microprogramme et le système
d’exploitation. Si les signatures sont valides, le serveur démarre et le microprogramme
donne le contrôle au système d’exploitation.

Sécurité basée sur la virtualisation (VBS)

Les serveurs à noyau sécurisé prennent en charge la sécurité basée sur la virtualisation
(VBS) et l’intégrité du code appliquée par l’hyperviseur (HVCI). VBS utilise des
fonctionnalités de virtualisation matérielle pour créer et isoler une région sécurisée de
mémoire du système d’exploitation normal, en assurant une protection contre toute une
classe de vulnérabilités utilisée dans les attaques d’exploration de la cryptomonnaie. VBS
permet également l’utilisation de Credential Guard, où les informations d’identification
de l’utilisateur et les secrets sont stockés dans un conteneur virtuel auquel le système
d’exploitation ne peut pas accéder directement.

HVCI utilise VBS pour renforcer considérablement l’application de la stratégie d’intégrité

du code. L’intégrité du mode noyau empêche le chargement de pilotes ou de fichiers
système en mode noyau non signés dans la mémoire système.

La protection des données du noyau (KDP, kernel data protection) fournit une
protection en lecture seule de la mémoire du noyau contenant des données non
exécutables où les pages mémoire sont protégées par l’hyperviseur. KDP protège les
structures clés du runtime Windows Defender System Guard de la falsification.
Connectivité sécurisée

Transport : HTTPS et TLS 1.3 activés par défaut sur Windows

Server 2022

Les connexions sécurisées sont au cœur des systèmes interconnectés d’aujourd'hui.

Transport Layer Security (TLS) 1.3 est la dernière version du protocole de sécurité le plus
déployé sur Internet, qui chiffre les données pour fournir un canal de communication
sécurisé entre deux points de terminaison. HTTPS et TLS 1.3 sont désormais activés par
défaut sur Windows Server 2022, protégeant ainsi les données des clients qui se
connectent au serveur. Ils éliminent les algorithmes de chiffrement obsolètes, améliorent
la sécurité par rapport aux anciennes versions, et visent à chiffrer la plus grande partie
possible de la négociation. Découvrez-en plus sur les versions prises en charge de TLS
ainsi que sur les suites de chiffrement prises en charge.

Même si TLS 1.3 dans la couche de protocole est maintenant activé par défaut, les
applications et services doivent également le prendre en charge activement. Le blog sur
la Sécurité Microsoft est plus détaillé dans le billet Taking Transport Layer Security (TLS)
to the next level with TLS 1.3 .

DNS sécurisé : demandes de résolution de noms DNS chiffrées

avec DNS-over-HTTPS

Le client DNS de Windows Server 2022 prend désormais en charge DNS-over-HTTPS

(DoH) qui chiffre les requêtes DNS à l'aide du protocole HTTPS. DoH permet de
préserver autant que possible la confidentialité de votre trafic en empêchant l’écoute
clandestine et la manipulation de vos données DNS. Pour plus d'informations, consultez
Configurer le client DNS pour utiliser DoH.

Server Message Block (SMB) : chiffrement SMB AES-256 pour les

plus soucieux de la sécurité

Windows Server prend désormais en charge les suites de chiffrement AES-256-GCM et

AES-256-CCM pour le chiffrement SMB. Windows négocie automatiquement cette
méthode de chiffrement plus avancée lors de la connexion à un autre ordinateur qui la
prend aussi en charge, et elle peut également être imposée via une stratégie de groupe.
Windows Server prend toujours en charge AES-128 pour la compatibilité descendante.
La signature AES-128-GMAC accélère désormais aussi les performances de signature.

SMB : contrôles de chiffrement SMB est-ouest pour les

communications internes aux clusters
Les clusters de basculement Windows Server prennent désormais en charge le contrôle
précis du chiffrement et de la signature des communications de stockage intra-nœud
pour les volumes partagés de cluster (CSV) et la couche de bus de stockage (SBL). Lors
de l’utilisation des espaces de stockage direct, vous pouvez maintenant décider de
chiffrer ou de signer les communications est-ouest au sein du cluster lui-même pour
une sécurité accrue.

Chiffrement SMB Direct et RDMA

SMB Direct et RDMA fournissent une bande passante élevée ainsi qu’une infrastructure
réseau à faible latence pour les charges de travail comme celles relatives aux espaces de
stockage direct, aux réplicas de stockage, à Hyper-V, aux serveurs de fichiers avec
montée en puissance parallèle et à SQL Server. Dans Windows Server 2022, SMB Direct
prend désormais en charge le chiffrement. Auparavant, l’activation du chiffrement SMB
désactivait le placement direct des données. Ceci était intentionnel, mais impactait
sérieusement les performances. Désormais, les données sont chiffrées avant leur
placement, ce qui entraîne une dégradation bien moins importante des performances,
tout en ajoutant la confidentialité des paquets protégés par AES-128 et AES-256.

Pour plus d’informations sur le chiffrement SMB, l’accélération de signature, la

fonctionnalité RDMA sécurisée et la prise en charge des clusters, consultez
Améliorations en matière de sécurité SMB.

Fonctionnalités hybrides Azure

Vous pouvez accroître votre efficacité et votre agilité grâce aux fonctionnalités hybrides
intégrées dans Windows Server 2022, et celles-ci vous permettent d'étendre plus
facilement que jamais vos centres de données à Azure.

Serveurs Windows avec Azure Arc

Les serveurs avec Azure Arc dotés de Windows Server 2022 permettent de transférer les
serveurs Windows locaux et multiclouds vers Azure avec Azure Arc. Cette expérience de
gestion a été conçue pour être cohérente avec la façon dont vous gérez les machines
virtuelles Azure natives. Quand une machine hybride est connectée à Azure, elle devient
une machine connectée et est traitée comme une ressource dans Azure. Pour plus
d'informations, consultez la documentation relative aux serveurs avec Azure Arc.

Ajouter des serveurs Windows

À partir de la mise à jour KB5031364 , vous pouvez désormais ajouter des serveurs
Windows avec un processus simple et facile.

Pour ajouter de nouveaux serveurs Windows, accédez à l’icône Azure Arc dans le coin
inférieur droit de la barre des tâches et lancez le programme d’installation d’Azure Arc
pour installer et configurer un agent de machine connecté à Azure. Une fois installé,
vous pouvez utiliser l’agent de machine connecté à Azure sans frais supplémentaires
pour votre compte Azure. Une fois que vous avez activé Azure Arc sur votre serveur,
vous pouvez voir les informations d’état dans l’icône de la barre des tâches.

Pour plus d’informations, consultez Connecter des machines Windows Server à Azure via
le programme d’installation d’Azure Arc.

Windows Admin Center

Parmi les améliorations apportées à Windows Admin Center pour gérer Windows
Server 2022 figurent des fonctionnalités qui permettent à la fois de signaler l'état actuel
des fonctionnalités Secured-core mentionnées ci-dessus et, le cas échéant, d'autoriser
les clients à activer ces fonctionnalités. Pour plus d'informations sur ces améliorations
ainsi que sur de nombreuses autres améliorations apportées à Windows Admin Center,
consultez la documentation relative à Windows Admin Center.

Plateforme d’application
Plusieurs améliorations de plateforme ont été apportées pour les instances de Windows
Container, notamment la compatibilité des applications et l'expérience Windows
Container avec Kubernetes.

Voici certaines des nouvelles fonctionnalités :

Réduction de la taille de l’image de conteneur Windows de jusqu’à 40 %, ce qui

permet un démarrage 30 % plus rapide et offre de meilleures performances.

Les applications peuvent désormais utiliser Azure Active Directory avec des
comptes de services administrés de groupe (gMSA) sans joindre l’hôte de
conteneur au domaine. Les conteneurs Windows prennent désormais également
en charge MSDTC (Microsoft Distributed Transaction Control) et MSMQ (Microsoft
Message Queuing).

Des bus simples peuvent désormais être affectés à conteneurs Windows Server
isolés des processus. Les applications qui s’exécutent dans des conteneurs et qui
doivent communiquer par le biais de SPI, I2C, GPIO et UART/COM sont désormais
en mesure de le faire.
 Nous avons activé la prise en charge de l’accélération matérielle des API DirectX
dans les conteneurs Windows pour des scénarios comme l’inférence du Machine
Learning en utilisant le matériel du processeur graphique (GPU) local. Pour plus
d'informations, consultez le billet de blog Intégration de l'accélération GPU dans
les conteneurs Windows .

Plusieurs autres améliorations simplifient l'expérience Windows Container avec

Kubernetes. Parmi ces améliorations figurent la prise en charge des conteneurs
hôte-processus pour la configuration des nœuds, IPv6, et l'implémentation
cohérente de la stratégie réseau avec Calico.

Windows Admin Center a été mis à jour pour faciliter la conteneurisation des
applications .NET. Une fois l'application dans un conteneur, vous pouvez l'héberger
sur Azure Container Registry pour ensuite la déployer sur d'autres services Azure,
comme Azure Kubernetes Service.

Grâce à la prise en charge des processeurs Intel Ice Lake, Windows Server 2022
prend en charge les applications critiques et à grande échelle qui nécessitent
jusqu’à 48 To de mémoire et 2 048 cœurs logiques exécutés sur 64 sockets
physiques. L'informatique confidentielle avec Intel Secured Guard Extension (SGX)
sur Intel Ice Lake améliore la sécurité des applications en les isolant les unes des
autres avec une mémoire protégée.

Pour en savoir plus sur les nouvelles fonctionnalités, consultez Nouveautés des
conteneurs Windows dans Windows Server 2022.

Autres fonctionnalités clés

Virtualisation IP des services Bureau à distance

À partir de la mise à jour KB5030216 , vous pouvez désormais utiliser la virtualisation

IP des services Bureau à distance.

La virtualisation IP des services Bureau à distance simule un bureau à utilisateur unique

en prenant en charge la virtualisation IP des services Bureau à distance par session et
par programme pour les applications Winsock. Pour plus d’informations, consultez
Virtualisation IP des services Bureau à distance dans Windows Server.

Planificateur de tâches et Gestionnaire Hyper-V pour les

installations Server Core
Nous avons ajouté deux outils de gestion au package de fonctionnalités de
compatibilité des applications à la demande de cette version : le Planificateur de tâches
(taskschd.msc) et le Gestionnaire Hyper-V (virtmgmt.msc). Pour plus d’informations,
consultez Fonctionnalité à la demande de compatibilité des applications Server Core.

Virtualisation imbriquée pour les processeurs AMD

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. Windows Server 2022 prend en charge
la virtualisation imbriquée à l'aide de processeurs AMD, offrant ainsi plus de choix de
matériel pour vos environnements. Pour plus d'informations, consultez la
documentation relative à la virtualisation imbriquée.

Navigateur Microsoft Edge

Microsoft Edge est inclus dans Windows Server 2022, en remplacement d'Internet
Explorer. Il repose sur Chromium open source et s'appuie sur la sécurité et l'innovation
de Microsoft. Il peut être utilisé avec les options d’installation Serveur avec Expérience
utilisateur. Pour plus d'informations, consultez la documentation relative à Microsoft
Edge Enterprise. Le support de Microsoft Edge, contrairement au reste de Windows
Server, suit le cycle de vie moderne. Pour plus d'informations, consultez la
documentation relative au cycle de vie de Microsoft Edge.

Performances réseau

Améliorations des performances UDP

UDP est en train de devenir un protocole répandu qui transporte de plus en plus de
trafic réseau en raison de la popularité croissante des protocoles de streaming et de jeu
(UDP) RTP et personnalisés. Le protocole QUIC, basé sur UDP, mets les performances
d’UDP au même niveau que TCP. Point important : Windows Server 2022 comprend le
déchargement segmentation UDP (USO). Le déchargement segmentation UDP transfère
la majeure partie du travail nécessaire pour envoyer des paquets UDP du processeur
vers le matériel spécialisé de la carte réseau. La fonctionnalité UDP RSC (Receive Side
Coalescing) vient en complément du déchargement segmentation UDP. Celle-ci permet
de fusionner les paquets et de réduire l’utilisation du processeur pour le traitement UDP.
En outre, nous avons également apporté plusieurs centaines d’améliorations au chemin
des données UDP, aussi bien au niveau de la transmission que de la réception.
Windows Server 2022 et Windows 11 disposent tous les deux de cette nouvelle
fonctionnalité.
Améliorations des performances de TCP

Windows Server 2022 utilise TCP HyStart++ pour réduire la perte de paquets pendant
le démarrage de la connexion (surtout dans les réseaux à haut débit), et RACK pour
réduire les délais d’attente de retransmission (RTO). Ces fonctionnalités sont activées par
défaut dans la pile de transport, et elles fournissent un flux de données réseau plus
régulier, avec de meilleures performances à des débits élevés. Windows Server 2022 et
Windows 11 disposent tous les deux de cette nouvelle fonctionnalité.

Améliorations apportées au commutateur virtuel Hyper-V

Dans Hyper-V, les commutateurs virtuels ont été améliorés à l’aide d’une nouvelle
fonctionnalité RSC (Receive Segment Coalescing). RSC permet au réseau de l’hyperviseur
de fusionner les paquets et de les traiter comme un seul segment plus grand. Le nombre
de cycles processeur est réduit et les segments resteront fusionnés pour l’ensemble du
chemin de données, jusqu’à ce qu’ils soient traités par l’application prévue. RSC
améliore les performances du trafic réseau envoyé par un hôte externe et reçu par une
carte réseau virtuelle ainsi que le trafic envoyé par une carte réseau virtuelle et reçu par
une autre carte réseau virtuelle présente sur le même hôte.

Dans vSwitch, RSC peut également regrouper plusieurs segments TCP en un segment
plus important avant que les données ne traversent le vSwitch. Cette modification
améliore également les performances de mise en réseau pour les charges de travail
virtuelles. RSC est activé par défaut sur les commutateurs virtuels externes.

Détection des anomalies de disque d’Insights système

Insights système a une autre fonctionnalité via Windows Admin Center, la détection des
anomalies de disque.

La détection des anomalies de disque est une nouvelle fonctionnalité qui signale quand
les disques se comportent de manière inhabituelle. Si ce qui est inhabituel n’est pas
nécessairement une mauvaise chose, il peut être utile de voir ces situations anormales
lors de la résolution de problèmes sur vos systèmes. Cette fonctionnalité est également
disponible pour les serveurs exécutant Windows Server 2019.

Améliorations de la restauration des mises à jour Windows

Les serveurs peuvent désormais reprendre automatiquement leur activité après des
échecs du démarrage en supprimant les mises à jour si ces échecs se sont manifestés
après l'installation récente de mises à jour qualité de Windows ou de pilotes. Lorsqu'un
appareil ne démarre pas correctement après l'installation récente de mises à jour qualité
ou de pilote, Windows désinstalle désormais automatiquement ces mises à jour pour
que l'appareil soit à nouveau opérationnel et fonctionne normalement.

Cette fonctionnalité exige que le serveur utilise l'option d'installation Server Core avec
une partition d'environnement de récupération Windows.

Stockage
Windows Server 2022 inclut les mises à jour suivantes pour le stockage. Le stockage est
également concerné par les mises à jour de la détection d'anomalies des disques System
Insights et de Windows Admin Center.

Service de migration de stockage

Les améliorations apportées au service de migration du stockage dans Windows

Server 2022 facilitent la migration du stockage vers Windows Server ou Azure depuis un
plus grand nombre d'emplacements sources. Les fonctionnalités disponibles lors de
l'exécution de l'orchestrateur du serveur de migration du stockage sur Windows
Server 2022 sont les suivantes :

Migrer des groupes et utilisateurs locaux vers le nouveau serveur

Migrer le stockage à partir de clusters de basculement, migrer vers des clusters de
basculement, et migrer entre des serveurs autonomes et des clusters de
basculement
Migrer le stockage à partir d'un serveur Linux qui utilise Samba
Synchroniser plus facilement des partages migrés dans Azure à l’aide d’Azure File
Sync
Migrer vers de nouveaux réseaux comme Azure
Migrer des serveurs CIFS NetApp entre des groupes NetApp FAS et des serveurs et
clusters Windows

Vitesse de réparation du stockage réglable

La vitesse de réparation du stockage ajustable par l’utilisateur est une nouvelle

fonctionnalité des espaces de stockage direct qui offre un meilleur contrôle sur le
processus de resynchronisation des données. La vitesse de réparation du stockage
ajustable vous permet d’allouer des ressources pour réparer des copies de données
(résilience) ou pour exécuter des charges de travail actives (performances). Le contrôle
de la vitesse de réparation contribue à améliorer la disponibilité et vous permet de gérer
vos clusters d’une façon plus flexible et plus efficace.
Réparation et resynchronisation plus rapides
La réparation et la resynchronisation du stockage après des événements tels que les
redémarrages de nœuds et les défaillances de disque sont maintenant deux fois plus
rapides. Les durées des réparations varient moins pour vous permettre de mieux savoir
le temps qu’elles vont prendre, ce qui a été accompli en ajoutant plus de précision dans
le suivi des données. Les réparations déplacent maintenant seulement les données qui
doivent être déplacées, réduisant ainsi les ressources système utilisées et le temps
nécessaire.

Cache de bus de stockage avec espaces de stockage sur des

serveurs autonomes

Le cache de bus de stockage est désormais disponible pour les serveurs autonomes. Il
améliore considérablement les performances de lecture et d'écriture, tout en
maintenant l'efficacité du stockage et en réduisant les coûts opérationnels. À l'instar de
son implémentation pour espaces de stockage direct, cette fonctionnalité associe des
supports plus rapides (par exemple, NVMe ou SSD) à des supports plus lents (par
exemple, HDD) pour créer des niveaux. Une partie du niveau le plus rapide est réservée
au cache. Pour plus d'informations, consultez Activer le cache de bus de stockage avec
espaces de stockage sur des serveurs autonomes.

Instantanés au niveau du fichier ReFS

Le système ReFS (Resilient File System) de Microsoft offre désormais la possibilité de

faire des instantanés de fichiers avec une opération de métadonnées rapide. Les
instantanés sont différents du clonage de blocs ReFS en cela que les clones sont
accessibles en écriture, tandis que les instantanés sont en lecture seule. Cette
fonctionnalité est particulièrement utile dans les scénarios de sauvegarde de machines
virtuelles avec les fichiers VHD/VHDX. Les instantanés ReFS sont uniques parce qu’ils
prennent le même temps, quelle que soit la taille des fichiers. La prise en charge des
instantanés est disponible dans ReFSUtil ou en tant qu’API.

Compression SMB
L'amélioration de SMB sur Windows Server 2022 et Windows 11 permet à un utilisateur
ou à une application de compresser les fichiers lors de leur transfert sur le réseau. Les
utilisateurs n'ont plus à compresser manuellement les fichiers afin de les transférer plus
rapidement sur les réseaux lents ou encombrés. Pour plus d'informations, consultez
Compression SMB.
conteneurs
Windows Server 2022 comprend les modifications suivantes apportées aux conteneurs
Windows.

Réduction de la taille de l’image Server Core

Nous avons réduit la taille des images Server Core. Cette taille d’image plus petite vous
permet de déployer des applications conteneurisées plus rapidement. Dans Windows
Server 2022, la couche d’image de base Server Core au moment du lancement général
(GA) atteint 2,76 Go non compressés sur le disque. Comparé à la couche Windows
Server 2019 RTM au moment du lancement général (GA), qui atteint 3,47 Go non
compressés sur le disque, cela représente une réduction de 33 % de l’empreinte sur
disque pour cette couche. Bien que vous ne deviez pas vous attendre à ce que la taille
totale de l’image soit réduite de 33 %, une taille de couche RTM plus petite signifie
généralement que la taille totale de l’image sera plus petite.

７ Notes

Les images de base de conteneurs Windows sont fournies avec deux couches : une
couche RTM et une couche de correctifs contenant les dernières corrections de
sécurité pour les bibliothèques et binaires du système d’exploitation, qui sont
superposées à la couche RTM. La taille de la couche de correctifs change au cours
du cycle de support de l’image du conteneur en fonction du nombre de
modifications apportées aux binaires. Lorsque vous récupérez une image de base
de conteneur sur un nouvel hôte, vous devez récupérer les deux couches.

Cycle de prise en charge plus long pour toutes les images

conteneurs Windows

Les images de Windows Server 2022 comme Server Core, Nano Server et l’image de
serveur , bénéficient de cinq ans de support principal et de cinq ans de support
étendu. Ce cycle de support plus long vous assure d’avoir le temps de mettre en œuvre,
d’utiliser, et de mettre à niveau ou de migrer lorsque cela est approprié pour votre
organisation. Pour plus d’informations, consultez Cycles de vie de la maintenance des
images de base Windows et Cycles de vie Windows Server 2022.

Fuseau horaire virtualisé

Avec Windows Server 2022, les conteneurs Windows peuvent désormais maintenir une
configuration de fuseau horaire virtualisée distincte de celle de l’hôte. Toutes les
configurations généralement utilisées par le fuseau horaire de l’hôte sont maintenant
virtualisées et instanciées pour chaque conteneur. Pour configurer le fuseau horaire du
conteneur, vous pouvez utiliser l'utilitaire de commande tzutil ou la cmdlet PowerShell
Set-TimeZone. Pour plus d’informations, consultez Fuseau horaire virtualisé.

Améliorations de la scalabilité pour la prise en charge de la

superposition de réseaux

Windows Server 2022 intègre plusieurs améliorations de performances et d’évolutivité

qui étaient déjà présentes dans quatre versions précédentes en canal semi-annuel (SAC)
de Windows Server et qui n’avaient pas été rétroportées dans Windows Server 2019 :

Résolution du problème de saturation des ports lors de l’utilisation de centaines de

services et de pods Kubernetes sur le même nœud.
Amélioration des performances du transfert de paquets dans le commutateur
virtuel Hyper-V (vSwitch).
Amélioration de la fiabilité des redémarrages de l’interface CNI dans Kubernetes.
Améliorations au niveau du plan de contrôle HNS (Host Networking Service) et du
plan de données utilisé par les conteneurs Windows Server et les
réseaux Kubernetes.

Pour en savoir plus sur les améliorations des performances et de la scalabilité au niveau
de la prise en charge de la superposition des réseaux, consultez Kubernetes Overlay
Networking for Windows .

Routage du retour direct du serveur pour la superposition et les

réseaux l2bridge

Direct Server Return (DSR) est une distribution de charge réseau asymétrique dans les
systèmes de répartition de charge qui fait que le trafic de demande et de réponse utilise
des chemins réseau différents. L’utilisation de chemins réseau différents aide à éviter les
sauts supplémentaires et réduit la latence, accélérant le temps de réponse entre le client
et le service et retirant la charge supplémentaire du répartiteur de charge. Le retour
direct du serveur améliore de manière évidente les performances réseau des
applications, en ne nécessitant que peu de modifications d’infrastructure, voire aucune.

Pour plus d’informations, consultez DSR in Introduction to Windows support in

Kubernetes .
Améliorations gMSA
Vous pouvez utiliser des comptes de service administrés de groupe (gMSA) avec des
conteneurs Windows pour faciliter l’authentification Active Directory (AD). Lorsqu’ils
sont apparus pour la première fois dans Windows Server 2019, les comptes gMSA
nécessitaient que l’utilisateur joigne l’hôte de conteneur à un domaine pour récupérer
les informations d’identification gMSA à partir d’Active Directory. Dans Windows Server
2022, gMSA pour les conteneurs avec un hôte non rejoint à un domaine utilise une
identité utilisateur portable au lieu d’une identité d’hôte pour récupérer les informations
d’identification gMSA. Ainsi, la jonction manuelle des nœuds Worker Windows à un
domaine n’est plus nécessaire. Après l’authentification, Kubernetes enregistre l’identité
utilisateur en tant que secret. Un gMSA pour conteneurs avec un hôte qui n’est pas joint
à un domaine offre la flexibilité de créer des conteneurs avec gMSA sans joindre le
nœud hôte au domaine.

Pour en savoir plus sur les améliorations apportées aux comptes gMSA, consultez Créer
des comptes de service administré de groupe pour des conteneurs Windows.

Prise en charge d’IPv6

Kubernetes sous Windows prend désormais en charge la pile double IPv6 dans les
réseaux basés sur L2bridge sous Windows Server. IPv6 dépend du CNI utilisé par
Kubernetes, et nécessite également la version Kubernetes 1.20 ou ultérieure pour activer
la prise en charge IPv6 de bout en bout. Pour plus d’informations, consultez IPv4/IPv6 -
Introduction à la prise en charge de Windows dans Kubernetes .

Prise en charge de plusieurs sous-réseaux pour les nœuds Worker

Windows avec Calico pour Windows
Le service réseau hôte (HNS) permet désormais d’utiliser des sous-réseaux plus
restrictifs, tels que des sous-réseaux avec une longueur de préfixe plus longue, et
également plusieurs sous-réseaux pour chaque nœud de travail Windows. Auparavant,
HNS restreignait les configurations de point de terminaison de conteneur Kubernetes à
utiliser uniquement la longueur de préfixe du sous-réseau sous-jacent. La première
interface CNI qui utilise cette fonctionnalité est Calico pour Windows . Pour plus
d’informations, consultez Prise en charge de plusieurs sous-réseaux dans Host
Networking Service.

Conteneurs HostProcess pour la gestion des nœuds

Les conteneurs HostProcess sont un nouveau type de conteneur qui s’exécute
directement sur l’hôte et étend le modèle de conteneur Windows pour permettre une
plus large gamme de scénarios de gestion pour les clusters Kubernetes. Avec les
conteneurs HostProcess, les utilisateurs peuvent empaqueter et distribuer des
opérations de gestion qui nécessitent un accès à l’hôte tout en conservant le versioning
et les méthodes de déploiement fournies par les conteneurs. Vous pouvez utiliser des
conteneurs Windows pour une variété de scénarios de gestion des périphériques, du
stockage et du réseau dans Kubernetes.

Les conteneurs HostProcess présentent les avantages suivants :

Les utilisateurs du cluster n’ont plus besoin de se connecter et de configurer

individuellement chaque nœud Windows pour les tâches administratives et la
gestion des services Windows.
Les utilisateurs peuvent utiliser le modèle de conteneur pour déployer la logique
de gestion sur autant de clusters que nécessaire.
Les utilisateurs peuvent créer des conteneurs HostProcess sur la base des images
de base de Windows Server 2019 ou ultérieures existantes, les gérer à l’aide de
l’exécution de conteneurs Windows, et les exécuter en tant qu’utilisateur
disponible dans le domaine de la machine hôte.
Les conteneurs HostProcess constituent le meilleur moyen de gérer des nœuds
Windows dans Kubernetes.

Pour plus d’informations, consultez Conteneurs HostProcess Windows .

Améliorations de Windows Admin Center

Windows Server 2022 développe l'extension Containers ajoutée à Windows Admin

Center pour conteneuriser les applications Web existantes basées sur ASP.NET de .NET
Framework. Vous pouvez utiliser des dossiers statiques ou des solutions Visual Studio
provenant de votre développeur.

Windows Admin Center comprend les améliorations suivantes :

L’extension Containers prend désormais en charge les fichiers de déploiement

Web, ce qui vous permet d’extraire l’application et sa configuration à partir d’un
serveur en cours d’exécution, puis de conteneuriser l’application.
Vous pouvez valider l’image localement, puis envoyer (push) cette image à Azure
Container Registry.
Le Registre de conteneurs Azure et l’Instance de conteneur Azure disposent
désormais de fonctionnalités de gestion de base. Vous pouvez désormais utiliser
l’interface utilisateur du Centre d’administration Windows pour créer et supprimer
 des registres, gérer des images, et démarrer et arrêter de nouvelles instances de
conteneurs.

Outils de conteneurisation des applications Azure Migrate

Azure Migrate App Containerization est une solution complète qui conteneurise et
déplace les applications web existantes vers le service Azure Kubernetes. Vous pouvez
évaluer les serveurs web existants, créer une image de conteneur, pousser l’image vers
le Registre de conteneurs Azure, créer un déploiement Kubernetes, et enfin le déployer
vers le service Azure Kubernetes.

Pour plus d’informations sur l’outil de conteneurisation des applications Azure Migrate,
veuillez consulter la section Conteneurisation d’applications ASP.NET et migration vers
le service Azure Kubernetes et Conteneurisation et migration d’applications Web Java
vers le service Azure Kubernetes.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Configuration système requise pour
Hyper-V sur Windows Server
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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 les exigences pour Hyper-V dépassent les exigences minimales générales
pour Windows Server parce qu'un environnement de virtualisation nécessite plus 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 avez besoin d’un matériel
plus récent pour utiliser des machines virtuelles protégées ou une attribution d’appareil
discrète. 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. 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.

Exigences générales
Quelles que soient les fonctionnalités Hyper-V que vous souhaitez utiliser, vous avez
besoin des éléments suivants :

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. Découvrez comment vérifier la configuration requise pour Hyper-V afin
de déterminer si votre processeur dispose d’une SLAT.

Extensions de mode du moniteur d’ordinateur virtuel

Assez de mémoire. Planifiez au moins 4 Go de RAM. Une quantité supérieure de

mémoire est préférable. Vous avez besoin de suffisamment de mémoire pour
l’hôte et toutes les machines virtuelles 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. Ceci est disponible dans les processeurs

qui incluent une option de virtualisation ; processeurs spécifiquement avec la
technologie Intel Virtualization Technology (Intel VT) ou AMD Virtualization
(AMD-V).

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 Configuration requise pour Hyper-V pour passer en
revue le rapport.

Configuration requise pour des fonctionnalités

spécifiques
Cette section énumère la configuration requise pour l'attribution d'appareils discrets et
les machines virtuelles protégées.
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 appareils ont besoin d’un GPU ou d’une mémoire nonvolatile express (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 la façon de l’utiliser et des considérations, consultez l’affectation
d’appareils discrets - Description et arrière-plan dans le blog de 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é

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Systèmes d’exploitation invités Windows
pris en charge pour Hyper-V sur
Windows Server and Azure Stack HCI.
Article • 25/10/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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, veuillez consulter les sections suivantes et Services
d’intégration.

Les composants configurables des systèmes d’exploitation invités sont confinés en

fonction du système d’exploitation hôte. Pour en savoir plus sur les composants
configurables maximum dans Hyper-V, veuillez consulter la section Planification de la
scalabilité de Hyper-V dans Windows Server.

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.

ﾉ Agrandir le tableau
Système Nombre maximal Integration Services Notes
d’exploitation de processeurs
invité (serveur) virtuels

Windows Server 2,048 pour la Intégré Hébergé sur Windows

2025 génération 2 ; Server 2025 et versions
64 pour la ultérieures
génération 1 ;
2,048 disponibles
pour le système
d’exploitation hôte
(partition racine)

Windows 1,024 pour la Intégré Hébergé sur Windows

Server 2022 génération 2 ; Server 2019 et les
64 pour la versions ultérieures,
génération 1 ; Azure Stack HCI, version
1,024 disponibles 20H2 et les versions
pour le système ultérieures.
d’exploitation hôte
(partition racine)

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
d’exploitation hôte
(partition racine)

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
d’exploitation hôte
(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 à jour Windows critiques Entreprise, Standard et
avec Service Pack 1 après avoir configuré le Web.
(SP1)
 Système Nombre maximal Integration Services Notes
d’exploitation de processeurs
invité (serveur) virtuels

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 après avoir configuré le Web (32 bits et 64 bits).
(SP2) système d’exploitation
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.

ﾉ Agrandir le tableau

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 et les versions
ultérieures.

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 du Professionnel (32 bits et
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.

ﾉ Agrandir le tableau

Système d'exploitation de Article

l'ordinateur hôte

Windows 10, 11 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 .

Liens connexes
 Machines virtuelles Linux et FreeBSD sur Hyper-V

Systèmes d’exploitation invités pris en charge pour Hyper-V client dans Windows

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Machines virtuelles Linux et FreeBSD
prises en charge pour Hyper-V sur
Windows Server et Windows
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Machines virtuelles CentOS et Red Hat Enterprise Linux
prises en charge sur Hyper-V
Article • 27/09/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

Série 8.x de RHEL/CentOS

Série 7.x de RHEL/CentOS

Série 6.x de RHEL/CentOS

Série 5.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

Série 9.x de RHEL/CentOS

 ﾉ Expand table

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 ✔ Note 2
Azure 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 ✔
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
Azure Stack HCI

Sauvegarde dynamique de machine virtuelle Windows Server 2022, 2019, 2016, 2012 R2 ✔ Note 5
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

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 ✔ Note 9, 10
Azure Stack HCI

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

Redimensionnement de la mémoire d’exécution Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI
Fonctionnalité Système d’exploitation hôte 9.x

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 ✔ Note 14,
Azure Stack HCI 17

Démarrage sécurisé Windows Server 2022, 2019, 2016 ✔

Azure Stack HCI

Série 8.x de RHEL/CentOS

ﾉ Expand table

Fonctionnalité Système d’exploitation hôte 8.1-8.6+ 8.0

Disponibilité LIS Intégré Intégré

Core 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 ✔ Note 2 ✔ Note 2
Azure Stack HCI

vRSS Windows Server 2022, 2019, 2016, 2012 R2 ✔ ✔

Azure Stack HCI
Fonctionnalité Système d’exploitation hôte 8.1-8.6+ 8.0

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 ✔ Note 3 ✔ Note 3
Azure Stack HCI

Sauvegarde dynamique de machine virtuelle Windows Server 2022, 2019, 2016, 2012 R2 ✔ Note 5 ✔ Note 5
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

Prise en charge du noyau PAE Windows Server 2022, 2019, 2016, 2012 R2 N/A N/A
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 ✔ Note 9, 10 ✔ Note 9, 10
Azure Stack HCI

Mémoire dynamique – Ballooning Windows Server 2022, 2019, 2016, 2012 R2 ✔ Note 9, 10 ✔ Note 9, 10
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

Ordinateurs virtuels de génération 2

Démarrage en mode UEFI Windows Server 2022, 2019, 2016, 2012 R2 ✔ Note 14, 17 ✔ Note 14
 Fonctionnalité Système d’exploitation hôte 8.1-8.6+ 8.0

Azure Stack HCI

Démarrage sécurisé Windows Server 2022, 2019, 2016 ✔ ✔

Azure Stack HCI

Série 7.x de RHEL/CentOS

Cette série comprend uniquement des noyaux 64 bits.

ﾉ Expand table

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

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,
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

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

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
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

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

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
 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

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

Série 6.x de RHEL/CentOS

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.

ﾉ Expand table

Fonctionnalité Système 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.6, 6.7 6.5 6.4
d’exploitation hôte 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 2016 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 Windows Server ✔ Note 1 ✔ Note 1 ✔ Note 1 ✔ Note 1 ✔ Note 1 ✔ Note 1 ✔ Note 1
réseaux locaux virtuels 2022, 2019, 2016,
Fonctionnalité Système 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.6, 6.7 6.5 6.4
d’exploitation hôte 6.8

2012 R2
Azure Stack HCI

Migration dynamique Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022, 2019, 2016,
2012 R2
Azure Stack HCI

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

vRSS Windows Server ✔ ✔ ✔ ✔ ✔

2022, 2019, 2016,
2012 R2
Azure Stack HCI

Segmentation TCP et Windows Server ✔ ✔ ✔ ✔ ✔

déchargements de somme 2022, 2019, 2016,
de contrôle 2012 R2
Azure Stack HCI

SR-IOV Windows
Server 2022, 2019,
2016
Azure Stack HCI

Stockage

Redimensionnement de Windows Server ✔ ✔ ✔ ✔ ✔ ✔

VHDX 2022, 2019, 2016,
2012 R2
Azure Stack HCI

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

Sauvegarde dynamique de Windows Server ✔ Note 5 ✔ Note 5 ✔ Note 5 ✔ ✔ Note 4, ✔ Note 4, ✔ Note 4,
machine virtuelle 2022, 2019, 2016, Note 4, 5 5 5, 6 5, 6
2012 R2
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

Prise en charge du noyau Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔

PAE 2022, 2019, 2016,
2012 R2
Azure Stack HCI

Configuration de l’écart Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔

MMIO 2022, 2019, 2016,
2012 R2
Azure Stack HCI
Fonctionnalité Système 6.7-6.10 6.4-6.6 6.0-6.3 6.10, 6.9, 6.6, 6.7 6.5 6.4
d’exploitation hôte 6.8

Mémoire dynamique – Windows Server ✔ Note 7, ✔ Note 7, ✔ Note 7, ✔ ✔ Note 7, ✔ Note 7,

Ajout à chaud 2022, 2019, 2016, 9, 10 9, 10 9, 10 Note 7, 8, 9, 10 8, 9, 10
2012 R2 9, 10
Azure Stack HCI

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

Redimensionnement de la Windows
mémoire d’exécution Server 2022, 2019,
2016
Azure Stack HCI

Vidéo

Appareil vidéo spécifique à Windows Server ✔ ✔ ✔ ✔ ✔ ✔

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

Divers

Paire clé-valeur Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022, 2019, 2016, Note 12 Note 12 Note 12, Note 12,
2012 R2 13 13
Azure Stack HCI

Interruption non Windows Server ✔ ✔ ✔ ✔ ✔ ✔ ✔

masquable 2022, 2019, 2016,
2012 R2
Azure Stack HCI

Copie de fichiers de l’hôte Windows Server ✔ ✔ ✔ ✔ ✔

vers l’invité 2022, 2019, 2016, Note 12 Note 12
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, Note 14 Note 14 Note 14 Note 14
2012 R2
Azure Stack HCI

Démarrage sécurisé Windows

Server 2022, 2019,
2016
Azure Stack HCI
Série 5.x de RHEL/CentOS
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.

ﾉ Expand table

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, 5,
2012 R2 6
Azure Stack HCI

Prise en charge de TRIM Windows Server 2022, 2019, 2016,

2012 R2
Azure Stack HCI
Fonctionnalité Système d’exploitation hôte 5.2-5.11 5.2-5.11 5.9-5.11

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

Mémoire dynamique – Ballooning Windows Server 2022, 2019, 2016, ✔ Note 7, 9, 10, ✔ Note 7, 9,
2012 R2 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

Ordinateurs virtuels de génération 2

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 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.

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

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

Certification matérielle Red Hat

Machines virtuelles Debian prises en
charge sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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é disponible

(vide) : fonctionnalité non disponible

ﾉ Agrandir le tableau

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 ✔ ✔

Fonctionnalité Version de 11 10.0-10.3
Windows Server (Bullseye) (Buster)

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 2019, 2016, 2012 R2 ✔ Note 2 ✔ Note 2

virtuelle

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 ✔ ✔

Fonctionnalité Version de 11 10.0-10.3
Windows Server (Bullseye) (Buster)

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

Ordinateurs virtuels de génération 2

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

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

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
 Machines virtuelles CentOS et Red Hat Enterprise Linux prises en charge sur Hyper-
V

Machines virtuelles Oracle Linux prises en charge sur Hyper-V

Machines virtuelles SUSE Linux Enterprise Server (SLES) 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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Machines virtuelles Oracle Linux prises
en charge sur Hyper-V
Article • 27/09/2023

S’applique à : Azure Stack HCI, Windows Server 2022, Windows 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

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

Série 8.x d’Oracle Linux
Série 7.x d’Oracle Linux
Série 6.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.

✔ : fonctionnalité disponible

(vide) : fonctionnalité non disponible

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

Série 9.x d’Oracle Linux

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 ✔

Ordinateurs virtuels de génération 2

Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 12

Démarrage sécurisé 2019, 2016 ✔

Série 8.x d’Oracle Linux

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
Fonctionnalité Version de 8.0-8.5
Windows Server (RHCK)

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 ✔

Ordinateurs virtuels de génération 2

Démarrage en mode UEFI 2019, 2016, 2012 R2 ✔ Note 12

 Fonctionnalité Version de 8.0-8.5
Windows Server (RHCK)

Démarrage sécurisé 2019, 2016 ✔

Série 7.x d’Oracle Linux

Cette série comprend uniquement des noyaux 64 bits.

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

Étiquetage 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

Ordinateurs virtuels
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

Série 6.x d’Oracle Linux

Cette série comprend uniquement des noyaux 64 bits.

Fonctionnalité Version de 6.8-6.10 6.8-6.10

Windows Server (RHCK) (UEK4)

Disponibilité LIS 4.3 Intégré

Fonctionnalité Version de 6.8-6.10 6.8-6.10
Windows Server (RHCK) (UEK4)

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 2019, 2016, 2012 R2 ✔ Note 5 ✔ Note 5

virtuelle

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, 8, ✔ Note 6, 8,

9 9

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

9 9

Redimensionnement de la mémoire de 2019, 2016

runtime
Fonctionnalité Version de 6.8-6.10 6.8-6.10
Windows Server (RHCK) (UEK4)

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 ✔ ✔

Ordinateurs virtuels de génération 2

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 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.

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

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.

Voir aussi

Set-VMFirmware

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 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
Machines virtuelles SUSE Linux Enterprise
Server (SLES) prises en charge sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows
à: Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions 23H2 and 22H2

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.

✔ : fonctionnalité disponible

(vide) : fonctionnalité non disponible

SLES12+ est disponible pour les systèmes 64 bits uniquement.

ﾉ Agrandir le tableau

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
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
Azure Stack HCI

Heure exacte WS/Hyper-V ✔ ✔ ✔ ✔

Windows 2022,2019,2016
Server 2016
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
SP4 SP3-
SP5

Mise en réseau

Trames Jumbo WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

Marquage et WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
jonction de réseaux 2022,2019,2016,2012
locaux virtuels Azure Stack HCI

Migration WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique 2022,2019,2016,2012
Azure Stack HCI

Injection WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
d’adresses IP 2022,2019,2016,2012 Note 1 Note 1 Note 1 Note 1 Note 1 Note 1 Note 1
statiques Azure Stack HCI

vRSS WS/Hyper-V ✔ ✔ ✔ ✔ ✔
2022,2019,2016,2012
Azure Stack HCI

Segmentation TCP WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

et déchargements 2022,2019,2016,2012
de somme de Azure Stack HCI
contrôle

SR-IOV WS/Hyper-V ✔ ✔ ✔ ✔
2022,2019,2016,2012
Azure Stack HCI

Stockage

Redimensionnement WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
de VHDX 2022,2019,2016,2012
Azure Stack HCI

Fibre Channel virtuel WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

Sauvegarde WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
dynamique de 2022,2019,2016,2012 Note 2, Note 2, Note 2, Note 2, Note 2, Note 2, Note 2,
machine virtuelle Azure Stack 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
Azure Stack HCI
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
SP4 SP3-
SP5

WWN SCSI WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI

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
Azure Stack HCI

Configuration de WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔
l’écart MMIO 2022,2019,2016,2012
Azure Stack 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 Azure Stack 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 Azure Stack 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 Azure Stack HCI

Divers

Paire clé/valeur WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

2022,2019,2016,2012 Note 7 Note 7
Azure Stack HCI

Interruption non WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔ ✔

masquable 2022,2019,2016,2012
Azure Stack HCI

Copie de fichiers de WS/Hyper-V ✔ ✔ ✔ ✔ ✔ ✔

l’hôte vers l’invité 2022,2019,2016,2012
Azure Stack HCI

Commande lsvmbus WS/Hyper-V ✔ ✔ ✔ ✔

2022,2019,2016,2012
Azure Stack HCI
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
SP4 SP3-
SP5

Sockets Hyper-V WS/Hyper-V ✔ ✔ ✔

2022,2019,2016

Pass-through WS/Hyper-V ✔ ✔ ✔ ✔ ✔
PCI/DDA 2022,2019,2016

Ordinateurs virtuels
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
Azure Stack 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).

4. Les opérations de mémoire dynamique peuvent échouer si la mémoire du système

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

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

Voir aussi
Set-VMFirmware

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 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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Machines virtuelles Ubuntu prises en
charge sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

Le mappage de distribution des fonctionnalités suivant indique les fonctionnalités

disponibles dans chaque version. Les problèmes connus et les solutions de
contournement pour chaque distribution sont répertoriés après le tableau.

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é disponible

(vide) : fonctionnalité non disponible

ﾉ Agrandir le tableau

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 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Heure exacte Windows 2022, 2019, 2016 ✔ ✔ ✔ ✔

Server 2016

Mise en réseau
Fonctionnalité Version du système 22.04 20.04 18.04 LTS LTS 16.04
d’exploitation LTS LTS
Windows Server

Trames Jumbo 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Marquage et jonction de 2022, 2019, 2016, ✔ ✔ ✔ ✔

réseaux locaux virtuels 2012 R2

Migration dynamique 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Injection d’adresses IP 2022, 2019, 2016, ✔ ✔ Note 1 ✔ Note 1 ✔ Note 1

statiques 2012 R2 Note 1

vRSS 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Segmentation TCP et 2022, 2019, 2016, ✔ ✔ ✔ ✔

déchargements de somme 2012 R2
de contrôle

SR-IOV 2022, 2019, 2016 ✔ ✔ ✔ ✔

Stockage

Redimensionnement de 2022, 2019, 2016, ✔ ✔ ✔ ✔

VHDX 2012 R2

Fibre Channel virtuel 2022, 2019, 2016, ✔ ✔ Note 2 ✔ Note 2 ✔ Note 2

2012 R2 Note 2

Sauvegarde dynamique de 2022, 2019, 2016, ✔ ✔ ✔ ✔

machine virtuelle 2012 R2 Note 3, Note 3, Note 3, Note 3,
4, 5 4, 5 4, 5 4, 5

Prise en charge de TRIM 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

WWN SCSI 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Mémoire

Prise en charge du noyau 2022, 2019, 2016, ✔ ✔ ✔ ✔

PAE 2012 R2

Configuration de l’écart 2022, 2019, 2016, ✔ ✔ ✔ ✔

MMIO 2012 R2
Fonctionnalité Version du système 22.04 20.04 18.04 LTS LTS 16.04
d’exploitation LTS LTS
Windows Server

Mémoire dynamique – 2022, 2019, 2016, ✔ ✔ ✔ ✔

Ajout à chaud 2012 R2 Note 6, Note 6, Note 6, Note 6,
7, 8 7, 8 7, 8 7, 8

Mémoire dynamique - 2022, 2019, 2016, ✔ ✔ ✔ ✔

Gonflage 2012 R2 Note 6, Note 6, Note 6, Note 6,
7, 8 7, 8 7, 8 7, 8

Redimensionnement de la 2022, 2019, 2016 ✔ ✔ ✔ ✔

mémoire d’exécution

Vidéo

Appareil vidéo Hyper-V 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Divers

Paire clé/valeur 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2 Note 5, Note 5, 9 Note 5, 9 Note 5, 9
9

Interruption non 2022, 2019, 2016, ✔ ✔ ✔ ✔

masquable 2012 R2

Copie de fichiers de l’hôte 2022, 2019, 2016, ✔ ✔ ✔ ✔

vers l’invité 2012 R2

Commande lsvmbus 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2

Sockets Hyper-V 2022, 2019, 2016 ✔ ✔ ✔ ✔

Pass-through PCI/DDA 2022, 2019, 2016 ✔ ✔ ✔ ✔

Ordinateurs virtuels de
génération 2

Démarrage en mode UEFI 2022, 2019, 2016, ✔ ✔ ✔ ✔

2012 R2 Note 10, Note 10, Note 10,
11 11 11

Démarrage sécurisé 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 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, 20.04 et 22.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.

7. Les opérations de mémoire dynamique peuvent échouer si la mémoire du système

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

Set-VMFirmware -VMName "VMname" -EnableSecureBoot Off

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
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

Descriptions des fonctionnalités pour les machines virtuelles Linux et FreeBSD sur
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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Machines virtuelles FreeBSD prises en
charge sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

Le mappage de distribution des fonctionnalités suivant indique les fonctionnalités

disponibles dans chaque version. Les problèmes connus et les solutions de
contournement pour chaque distribution sont répertoriés après le tableau.

Légende du tableau
Intégré : BIS (FreeBSD Integration Service) est inclus dans cette version de
FreeBSD.

✔ : fonctionnalité disponible

(vide) : fonctionnalité non disponible

ﾉ Agrandir le tableau

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, ✔ ✔ ✔ ✔

VLAN 2012 R2
Fonctionnalité Version du 13.0-13.1 12.0-12.3 11.2-11.4 10.4
système
d’exploitation
Windows Server

Migration dynamique 2019, 2016, 2012 ✔ ✔ ✔ ✔

R2

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
Fonctionnalité Version du 13.0-13.1 12.0-12.3 11.2-11.4 10.4
système
d’exploitation
Windows Server

Mémoire dynamique - 2019, 2016, 2012

Ballooning R2

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, ✔ ✔ ✔ ✔

masquable 2012 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 ✔ ✔ ✔

Ordinateurs virtuels de
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
Descriptions des fonctionnalités pour les machines virtuelles Linux et FreeBSD sur
Hyper-V
Bonnes pratiques pour l’exécution de FreeBSD sur Hyper-V

Commentaires
Cette page a-t-elle été utile ?
 Yes  No
Descriptions des fonctionnalités pour
les machines virtuelles Linux et FreeBSD
sur Hyper-V
Article • 27/09/2023

S’applique à : Azure Stack HCI, Windows Server 2022, 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

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
ﾉ Expand table

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 de Cette fonctionnalité garantit que l’heure conservée à l’intérieur d’une

l’heure machine 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

Windows Server 2016 exacte Windows Server 2016 précision, qui améliore la synchronisation
de l’heure avec 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
intégrée de la souris d’une machine virtuelle et l’utiliser en toute facilité entre le bureau
Windows Server et la console Hyper-V pour la machine virtuelle.
Fonctionnalité Description

Périphérique de Cette fonctionnalité accorde un accès hautes performances aux

stockage spécifique périphériques de stockage attachés à une machine virtuelle.
Hyper-V

Périphérique réseau Cette fonctionnalité accorde un accès hautes performances aux cartes
spécifique Hyper-V réseau attachées à une machine virtuelle.

Mise en réseau
ﾉ Expand table

Fonctionnalité Description

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 jonction Cette fonctionnalité vous permet de configurer le trafic de réseau local
de réseaux locaux virtuel (VLAN) pour les machines virtuelles.
virtuels

Migration dynamique Avec cette fonctionnalité, vous pouvez migrer une machine virtuelle
d’un hôte vers un autre hôte. Pour plus d’informations, voir Vue
d’ensemble de la migration dynamique de la machine virtuelle.

Injection d’adresses IP Avec cette fonctionnalité, vous pouvez répliquer l’adresse IP statique
statiques d’une machine virtuelle après son basculement vers son réplica sur un
autre hôte. 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 à l’échelle Répartit la charge à partir d’une carte réseau virtuelle sur plusieurs
côté réception processeurs virtuels d’une machine virtuelle. Pour plus d’informations,
virtuelle) consultez Mise à l’échelle côté réception virtuelle dans Windows Server
2012 R2.

Segmentation TCP et Transfère la segmentation et la somme de contrôle du processeur invité

déchargements de vers le commutateur virtuel hôte ou la carte réseau pendant les
somme de contrôle transferts de données réseau.

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
réception (LRO) importante, ce qui réduit la surcharge du processeur.

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
Fonctionnalité Description

des pilotes de fonction physique (PF) à jour sur les pilotes de fonction
hôte et de fonction virtuelle (VF) sur l’invité.

Stockage
ﾉ Expand table

Fonctionnalité Description

Redimensionnement de Avec cette fonctionnalité, un administrateur peut redimensionner un

VHDX fichier .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 dynamique Cette fonctionnalité facilite la sauvegarde sans temps d’arrêt des
de machine virtuelle machines virtuelles actives.
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
ﾉ Expand table
Fonctionnalité Description

Prise en charge du La technologie PAE (Physical Address Extension) permet à un noyau 32

noyau PAE bits 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é

dynamique - Ajout à de 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é

dynamique - de 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
Fonctionnalité Description

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
ﾉ Expand table

Fonctionnalité Description

Appareil vidéo Cette fonctionnalité fournit des graphiques hautes performances et une
spécifique à Hyper-V résolution supérieure pour les machines virtuelles. Cet appareil ne fournit
pas de fonctionnalités de mode de session amélioré ou RemoteFX.
Divers
ﾉ Expand table

Fonctionnalité Description

Échange KVP Cette fonctionnalité fournit un service d’échange clé/valeur (KVP) pour les
(paire clé-valeur) machines virtuelles. En règle générale, les administrateurs utilisent le
mécanisme 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 non Avec cette fonctionnalité, un administrateur peut émettre des interruptions
masquable non masquables (NMI) sur une machine virtuelle. Les MN sont utiles pour
obtenir des 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 fichiers Cette fonctionnalité permet de copier des fichiers de l’ordinateur physique
de l’hôte vers hôte vers les machines virtuelles invitées sans utiliser la carte réseau. Pour
l’invité plus d’informations, voir Services invités.

Commande Cette commande obtient des informations sur les appareils du bus de
lsvmbus machines virtuelles Hyper-V (VMBus) similaires aux commandes
d’informations telles que lspci.

Sockets Hyper-V Il s’agit d’un canal de communication supplémentaire entre le système

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.

Ordinateurs virtuels de génération 2

 ﾉ Expand table

Fonctionnalité Description

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
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

Meilleures pratiques pour l’exécution de Linux sur Hyper-V

Bonnes pratiques pour l’exécution de FreeBSD sur Hyper-V

Meilleures pratiques pour l’exécution de
Linux sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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.

Références supplémentaires
Ordinateurs virtuels Linux et FreeBSD pris en charge pour Hyper-V sur Windows

Bonnes pratiques pour l’exécution de FreeBSD sur Hyper-V

Déployer un cluster Hyper-V

Créer des images Linux pour Azure

Optimiser votre machine virtuelle Linux sur Azure

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Bonnes pratiques pour l’exécution de
FreeBSD sur Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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

Machines virtuelles FreeBSD prises en charge sur Hyper-V

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Compatibilité des fonctionnalités Hyper-
V par génération et invité
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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. 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
ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Points de 1 et 2 Tout invité pris en charge

contrôle

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

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
 ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Mémoire dynamique 1 et 2 Versions spécifiques des invités pris en charge. Consultez

Vue d’ensemble de la mémoire dynamique Hyper-V pour
les versions antérieures à Windows Server 2016 et
Windows 10.

Ajout/suppression de 1 et 2 Windows Server 2016, Windows 10

mémoire à chaud

NUMA virtuel 1 et 2 Tout invité pris en charge

Développement et test
ﾉ Agrandir le tableau

Fonctionnalité Generation Système

d’exploitation
invité

Ports 1 et 2 Tout invité pris en

COM/série Remarque : Pour la génération 2, utilisez Windows charge
PowerShell pour configurer. Pour plus d’informations,
consultez Ajouter un port COM pour le débogage du
noyau.

Mobilité
ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Migration dynamique 1 et 2 Tout invité pris en charge

Importation/Exportation 1 et 2 Tout invité pris en charge

Mise en réseau
ﾉ Agrandir le tableau
Fonctionnalité Generation Système d’exploitation invité

Ajout/suppression à chaud de carte 2 Tout invité pris en charge

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

ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Attribution discrète de 1 et 2 Windows Server 2012 et versions ultérieures, Windows 10

périphérique (DDA) et Windows 11

Mode de session 1 et 2 Windows Server 2012 R2 et versions ultérieures, et

amélioré Windows 8.1 et versions ultérieures, avec les services de
bureau à distance activés
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 64 bits de Windows 10 et
Windows 11

Sécurité
ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Démarrage sécurisé 2 Linux : Ubuntu 14.04 et versions ultérieures, SUSE Linux

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
 Fonctionnalité Generation Système d’exploitation invité

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 protection s’exécuter sur un ordinateur virtuel de génération 2
maximale

Stockage
ﾉ Agrandir le tableau

Fonctionnalité Generation Système d’exploitation invité

Disques durs virtuels partagés (VHDX 1 et 2 Windows Server 2012 et ultérieur

uniquement)

SMB3 1 et 2 Tout ce qui prend en charge SMB3

Espaces de stockage direct 2 Windows Server 2016 et versions

ultérieures

Fibre Channel virtuel 1 et 2 Windows Server 2012 et ultérieur

Format VHDX 1 et 2 Tout invité pris en charge

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Installer le rôle Hyper-V sur Windows
Server
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
and 22H2

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 et Windows 11, voir
Installer Hyper-V sous Windows.

Pour en savoir plus sur Hyper-V, consultez Vue d’ensemble de la technologie Hyper-V.
Pour en savoir plus sur Hyper-V, consultez la présentation d'Hyper-V. Pour essayer
Windows Server 2025, 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.

Références supplémentaires
Install-WindowsFeature
Commentaires
Cette page a-t-elle été utile ?  Yes  No
Installer le rôle Hyper-V sur Windows
Server
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
and 22H2

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 et Windows 11, voir
Installer Hyper-V sous Windows.

Pour en savoir plus sur Hyper-V, consultez Vue d’ensemble de la technologie Hyper-V.
Pour en savoir plus sur Hyper-V, consultez la présentation d'Hyper-V. Pour essayer
Windows Server 2025, 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.

Références supplémentaires
Install-WindowsFeature
Commentaires
Cette page a-t-elle été utile ?  Yes  No
Créer et configurer un commutateur
virtuel avec Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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.

Gestionnaire Hyper-V
 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.

Gestionnaire Hyper-V

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.

1. Ouvrez le Gestionnaire Hyper-V.

2. Dans le volet Actions, sélectionnez Gestionnaire de commutateur virtuel.

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.

Un avertissement s’affichera, indiquant que la modification peut perturber

votre connectivité réseau. Sélectionnez Oui si vous souhaitez continuer.
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.

Gestionnaire Hyper-V

Voici comment spécifier le numéro d’identification de réseau local 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. 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.

Un avertissement s’affichera, indiquant que la modification peut perturber

votre connectivité réseau. Sélectionnez Oui si vous souhaitez continuer.

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Créer une machine virtuelle avec Hyper-
V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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

Gestionnaire Hyper-V

1. Ouvrez le Gestionnaire Hyper-V.

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.

ﾉ Agrandir le tableau

Page Valeur par défaut pour Windows Server 2016, Autres options
Windows 10 et ultérieur

Spécifier le Nom : nouvelle machine virtuelle. Vous pouvez aussi entrer

nom et Emplacement : votre propre nom et choisir
l’emplacement C:\ProgramData\Microsoft\Windows\Hyper-V\. un autre emplacement pour
la machine 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

génération de 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 dynamique : non sélectionné mémoire 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

mise en réseau une connexion réseau pour
la 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
 Page Valeur par défaut pour Windows Server 2016, Autres options
Windows 10 et ultérieur

virtuel Emplacement : virtuel existant, ou bien

C:\Users\Public\Documents\Hyper-V\Virtual attendre et attacher un
Hard Disks\ disque dur virtuel
ultérieurement.
Taille : 127 Go

Options Installer un système d’exploitation Ces options changent

d’installation ultérieurement l’ordre de 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 pour Astuce : Vous pouvez
vous permettre de vérifier qu’elles sont copier le résumé de la page
correctes. et le coller dans un e-mail
- Nom ou ailleurs pour faciliter le
- Génération suivi de vos machines
- Mémoire virtuelles.
- Réseau
- Disque dur
- Système d’exploitation

Références supplémentaires
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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Planifier la scalabilité d’Hyper-V dans
Windows Server
Article • 25/10/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Local, versions 23H2 and 22H2

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. Lorsque vous planifiez votre
déploiement, tenez compte des plafonds qui s'appliquent à chaque machine virtuelle et
à 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 plafonds s'appliquent à chaque machine virtuelle lorsque l'hôte exécute la version
sélectionnée du produit. Le système d'exploitation invité peut prendre en charge moins
que le maximum de la machine virtuelle. 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 ?.

ﾉ Agrandir le tableau

Composant Maximale Notes

Points de contrôle 50 Le nombre réel peut être inférieur, en fonction du

stockage disponible. Chaque point de contrôle est
stocké sous la forme d’un fichier .avhd qui utilise du
stockage physique.

Mémoire 240 To pour Vérifiez la configuration requise du système

la génération d’exploitation spécifique pour déterminer les
Composant Maximale Notes

2 capacités minimales et recommandées.

1 To pour la
génération 1

Ports série (COM) 2 Aucune.

Taille des disques Variable La taille maximale est fonction du système

physiques d’exploitation invité.
connectés
directement à un
ordinateur virtuel

Carte Fibre 4 En guise de meilleure pratique, nous vous

Channel virtuelle recommandons de connecter chaque carte Fibre
Channel virtuelle à un SAN virtuel différent.

Lecteurs de 1 lecteur de Aucune.

disquettes virtuels disquettes virtuel

Capacité du disque 64 To pour le Chaque disque dur virtuel est stocké sur un média
dur virtuel format VHDX physique en tant que fichier .vhdx ou .vhd, selon le
2 040 Go format utilisé par le disque dur virtuel.
pour le
format VHD

Disques virtuels 4 Le disque de démarrage (parfois appelé disque

IDE d’amorçage) doit ê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 2048 pour la Le nombre de processeurs virtuels pris en charge par

virtuels génération 2 un système d’exploitation invité pourrait être
64 pour la inférieur. Pour plus d’informations, consultez les
génération 1 informations publiées pour le système d’exploitation
spécifique.

Contrôleurs SCSI 4 L’utilisation de périphériques SCSI virtuels nécessite

virtuels les services d’intégration, qui sont disponibles pour
les systèmes 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 SCSI 256 Chaque contrôleur SCSI prend en charge jusqu’à

virtuels 64 disques. En d’autres termes, chaque ordinateur
virtuel peut être configuré avec un maximum de
 Composant Maximale Notes

256 disques SCSI virtuels (4 contrôleurs x 64 disques

par contrôleur). (4 contrôleurs x 64 disques par
contrôleur).

Cartes réseau 68 adaptateurs au La carte réseau propre à Hyper-V offre de meilleures

virtuel total : performances et nécessite un pilote inclus dans les
64 cartes services d’intégration. Pour plus d’informations,
réseau consultez Planifier les réseaux Hyper-V dans Windows
propres à Server.
Hyper-V
4 cartes
réseau
héritées ;

Valeurs maximales pour les hôtes Hyper-V

Ces maximums s'appliquent à chaque hôte Hyper-V exécutant la version de produit
sélectionnée.

ﾉ Agrandir le tableau

Composant Maximale Notes

Processeurs 2 048 Ces deux fonctionnalités doivent être

logiques activées dans le micrologiciel :
Virtualisation assistée par le
matériel
Prévention de l’exécution des
données (DEP) appliquée par
matériel

Mémoire 4 PB pour les hôtes Aucune.

prenant en charge la
pagination à 5 niveaux
256 To pour les hôtes
prenant en charge la
pagination à 4 niveaux.

Association de Aucune limite imposée par Aucune.

cartes réseau Hyper-V.

Cartes réseau Aucune limite imposée par Aucune.

physiques Hyper-V.
 Composant Maximale Notes

Ordinateurs virtuels 1 024 Aucune.

en cours
d'exécution par
serveur

Stockage Limité par la capacité prise en Remarque : Microsoft prend en charge

charge par le système le stockage NAS (Network-Attached
d’exploitation de gestion. Storage) lors de l’utilisation de SMB 3.0.
Aucune limite imposée par Le stockage basé sur NFS n'est pas pris
Hyper-V. en charge.

Ports de Variable ; aucune limite La limite pratique varie en fonction des

commutateurs de imposée par Hyper-V. ressources informatiques disponibles.
réseau virtuel par
serveur

Processeurs virtuels 2 048 La limite est appliquée au système

disponibles pour d'exploitation de l'hôte (partition racine).
l'hôte

Processeurs virtuels Aucun ratio imposé par Hyper- Aucune.

par processeur V.
logique

Processeurs virtuels 2 048 Aucune.

par serveur

Réseaux de zone de Aucune limite imposée par Aucune.

stockage virtuels Hyper-V.

Commutateurs Variable ; aucune limite La limite pratique varie en fonction des

virtuels imposée par Hyper-V. ressources 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 planifier la capacité afin de s'assurer
qu'il y a suffisamment de ressources matérielles pour exécuter toutes les machines
virtuelles dans un environnement en grappe.

ﾉ Agrandir le tableau

Composant Maximale Notes

Nœuds par 64 Prenez en compte le nombre de nœuds que vous souhaitez

cluster réserver pour le basculement et les tâches de maintenance
 Composant Maximale Notes

telles que l'application de mises à jour. Nous vous

recommandons de prévoir suffisamment de ressources pour
qu'un nœud soit réservé au basculement. Cela signifie qu'il
reste inactif jusqu'à ce qu'un autre nœud soit basculé sur lui, ce
que l'on appelle parfois un nœud passif. Vous pouvez
augmenter ce nombre si vous souhaitez réserver davantage de
nœuds. Il n'y a pas de ratio ou de multiplicateur recommandé
entre les nœuds réservés et les nœuds actifs ; la seule exigence
est que le nombre total de nœuds dans une grappe ne dépasse
pas le maximum de 64.

Ordinateurs 8 000 par Plusieurs facteurs peuvent avoir une incidence sur le nombre
virtuels exécutés cluster réel d’ordinateurs virtuels que vous pouvez exécuter en même
simultanément temps sur un nœud, tels que :
par nœud - Quantité de mémoire physique utilisée par chaque ordinateur
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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
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
Azure Stack HCI version 22H2

17763 et 17784 Windows Server 2019 Datacenter

Windows Server 2019 Standard
Windows Server 2019 Essentials
Serveur Hyper-V 2019
Azure Stack HCI version 20H2
 Build Hyper-V Produits compatibles

14393 Windows Server 2016 Datacenter

Windows Server 2016 Standard
Windows Server 2016 Essentials
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 • 21/06/2024

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

La création d’une machine virtuelle de génération 1 ou de génération 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 des machines virtuelles de génération 2 pour tirer parti des
fonctionnalités telles que le démarrage sécurisé, sauf si l’une des instructions suivantes
est vraie :

Vous utilisez un disque dur virtuel prédéfini existant (fichiers 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 qu’elle a été
créée. Nous vous recommandons de passer en revue les considérations ici, puis 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 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é
 Utilisez le démarrage sécurisé pour empêcher le microprogramme, les systèmes
d’exploitation ou les pilotes UEFI non autorisés de s’exécuter au moment du
démarrage. Le démarrage sécurisé vérifie que le chargeur de démarrage est signé
par une autorité approuvée dans la base de données UEFI. 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é que le démarrage sécurisé ne prend pas
en charge, vous pouvez le désactiver après avoir créé 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. Ce volume de démarrage
maximal est la taille maximale de disque prise en charge par une machine virtuelle
Pour la .VHDX génération 1, le volume de démarrage maximal est de 2 To pour une
.VHDX et de 2040 Go pour plus .VHD d’informations, voir Vue d’ensemble du format

de disque dur virtuel Hyper-V.

Vous pouvez également constater une légère amélioration des temps de

démarrage et d’installation des machines virtuelles de génération 2.

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 Windows pris en charge

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

Systèmes d’exploitation invités Windows 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.

ﾉ Agrandir le tableau

Versions 64 bits de Windows Génération 1 Génération 2

Windows Server 2025 ✔ ✔

Windows Server 2022 ✔ ✔

Windows Server 2019 ✔ ✔

Windows Server 2016 ✔ ✔

Windows Server 2012 R2 ✔ ✔

Windows Server 2012 ✔ ✔

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.

ﾉ Agrandir le tableau

Versions 32 bits de Windows Génération 1 Génération 2

Windows 10 ✔ ✖

Windows 8.1 ✔ ✖
 Versions 32 bits de Windows Génération 1 Génération 2

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.

ﾉ Agrandir le tableau

Versions du système Génération Génération 2

d’exploitation 1

Série 8.x de RHEL/CentOS ✔ ✔

Série 7.x de RHEL/CentOS ✔ ✔

Série 6.x de RHEL/CentOS ✔ ✔

Note : prise en charge uniquement sur Windows
Server 2016 et versions ultérieures.

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.

ﾉ Agrandir le tableau

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) ✔ ✔

 Versions du système d’exploitation Génération 1 Génération 2

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
systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.

ﾉ Agrandir le tableau

Versions du système d’exploitation Génération 1 Génération 2

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.

ﾉ Agrandir le tableau

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.

ﾉ Agrandir le tableau

Versions d’Unbreakable Enterprise Kernel (UEK) Génération 1 Génération 2

Oracle Linux UEK R3 QU3 ✔ ✖

Oracle Linux UEK R3 QU2 ✔ ✖

Oracle Linux UEK R3 QU1 ✔ ✖

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
systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.

ﾉ Agrandir le tableau

Versions du système d’exploitation Génération 1 Génération 2

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
systèmes d’exploitation invités pour les machines virtuelles de génération 1 et 2.

ﾉ Agrandir le tableau

Versions du système d’exploitation Génération 1 Génération 2

Ubuntu 20.04 ✔ ✔
 Versions du système d’exploitation Génération 1 Génération 2

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 ?

Les machines virtuelles de génération 1 et de génération 2 prennent en charge
différentes méthodes de démarrage, ces méthodes sont présentées dans le tableau
suivant.

ﾉ Agrandir le tableau

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émarrez à partir d’un disque dur virtuel SCSI ( .VHDX) ou dvd ✖ ✔

virtuel (. ISO)

Démarrage à partir d’un disque dur virtuel du contrôleur IDE ✔ ✖

( .VHD) , DVD virtuel ou .ISO) lecteur CD/DVD physique

Démarrage à partir de la floppy virtuelle ( .VFD) ✔ ✖

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.

ﾉ Agrandir le tableau
Périphérique de Remplacement de Améliorations de génération 2
génération 1 génération 2

Contrôleur IDE Contrôleur SCSI virtuel Démarrage à partir de (taille maximale de

64 To et capacité de
.VHDX redimensionnement en ligne)

CD-ROM IDE CD-ROM SCSI virtuel Prise en charge de 64 périphériques DVD

SCSI par contrôleur SCSI.

BIOS hérité Microprogramme UEFI Démarrage sécurisé

Carte réseau héritée Carte réseau Démarrage réseau avec IPv4 et IPv6
synthétique

Contrôleur de disquettes Aucune prise en N/A

et contrôleur DMA charge des contrôleurs
de disquettes

Émetteur/récepteur UART facultatif pour le Rapidité et fiabilité accrues

asynchrone universel débogage
(UART) pour ports COM

Contrôleur de clavier Entrée basée sur le Utilise moins de ressources en raison de

i8042 logiciel l’absence d’émulation. Réduit également la
surface d'attaque sur le système
d'exploitation invité.

Clavier PS/2 Clavier logiciel Utilise moins de ressources en raison de

l’absence d’émulation. Réduit également la
surface d'attaque sur le système
d'exploitation invité.

Souris PS/2 Souris logicielle Utilise moins de ressources en raison de

l’absence d’émulation. Réduit également la
surface d'attaque sur le système
d'exploitation invité.

Vidéo S3 Vidéo basée sur le Utilise moins de ressources en raison de

logiciel l’absence d’émulation. Réduit également la
surface d'attaque sur le système
d'exploitation invité.

Bus PCI Plus nécessaire N/A

Contrôleur d'interruptions Plus nécessaire N/A

programmable (PIC)

Minuteur d'intervalle Plus nécessaire N/A

programmable (PIT)
 Périphérique de Remplacement de Améliorations de génération 2
génération 1 génération 2

Super périphérique d'E/S Plus nécessaire S/O

Considérations relatives à l’utilisation de

machines virtuelles de génération 1 et de
génération 2
Voici quelques conseils supplémentaires sur l’utilisation des différentes générations de
machines virtuelles.

Création de machines virtuelles avec plus de 64

processeurs logiques
Le gestionnaire Hyper-V peut échouer à créer une machine virtuelle de génération 1 sur
un système avec plus de 64 processeurs logiques. Le gestionnaire Hyper-V ne vous
permet pas de spécifier le nombre de processeurs virtuels au moment de la création de
la machine virtuelle. Pour les hôtes avec plus de 64 processeurs logiques, spécifiez le
nombre de processeurs virtuels lors de la création de machines virtuelles à l’aide de
Windows Admin Center, de PowerShell ou d’un autre outil.

Chargement d’un disque dur virtuel sur Azure

Les disques durs virtuels créés sur les machines virtuelles de génération 1 et 2e
génération peuvent être chargés sur Azure tant qu’ils utilisent le format de fichier VHD.
Le disque dur virtuel doit avoir un disque de taille fixe (pas en expansion 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.

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. Pour les machines virtuelles de génération 2, Hyper-V
fournit un microprogramme virtuel aux machines virtuelles indépendantes 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
est compilé directement à partir des sources. Si ces applications ne sont pas
signées numériquement correctement, vous devez 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. Au lieu de cela, créez des fichiers VHDX
de démarrage qui ciblent uniquement les machines virtuelles de génération 1 ou
de génération 2.
La génération de l’ordinateur virtuel est une propriété de l’ordinateur virtuel, et
non du disque dur virtuel. Vous ne pouvez pas savoir si un fichier VHDX a été créé
en tant que 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, si le
disque dur virtuel est un fichier VHDX de démarrage, la machine virtuelle de
génération 1 ne parvient pas à démarrer.
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 ajouter des ports COM 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. Utilisez l’applet de commande Set-VMComPort pour ajouter

un port COM. 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 • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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 :

ﾉ Agrandir le tableau
 Nom du paramètre Description

Autoriser le système Autorisez l’hôte Hyper-V à partager l’utilisation du commutateur virtuel

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

Activer la virtualisation Autorisez le trafic de machine virtuelle à contourner le commutateur de

d’E/S d’une racine machine virtuelle et à accéder directement à la carte réseau physique.
unique (SR-IOV) SR-IOV est disponible uniquement pour les machines virtuelles
exécutant Windows Server. Pour plus d’informations, consultez
Virtualisation d’E/S mono-racine dans la 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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Planifier la scalabilité d’Hyper-V dans
Windows Server
Article • 25/10/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Local, versions 23H2 and 22H2

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. Lorsque vous planifiez votre
déploiement, tenez compte des plafonds qui s'appliquent à chaque machine virtuelle et
à 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 plafonds s'appliquent à chaque machine virtuelle lorsque l'hôte exécute la version
sélectionnée du produit. Le système d'exploitation invité peut prendre en charge moins
que le maximum de la machine virtuelle. 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 ?.

ﾉ Agrandir le tableau

Composant Maximale Notes

Points de contrôle 50 Le nombre réel peut être inférieur, en fonction du

stockage disponible. Chaque point de contrôle est
stocké sous la forme d’un fichier .avhd qui utilise du
stockage physique.

Mémoire 240 To pour Vérifiez la configuration requise du système

la génération d’exploitation spécifique pour déterminer les
Composant Maximale Notes

2 capacités minimales et recommandées.

1 To pour la
génération 1

Ports série (COM) 2 Aucune.

Taille des disques Variable La taille maximale est fonction du système

physiques d’exploitation invité.
connectés
directement à un
ordinateur virtuel

Carte Fibre 4 En guise de meilleure pratique, nous vous

Channel virtuelle recommandons de connecter chaque carte Fibre
Channel virtuelle à un SAN virtuel différent.

Lecteurs de 1 lecteur de Aucune.

disquettes virtuels disquettes virtuel

Capacité du disque 64 To pour le Chaque disque dur virtuel est stocké sur un média
dur virtuel format VHDX physique en tant que fichier .vhdx ou .vhd, selon le
2 040 Go format utilisé par le disque dur virtuel.
pour le
format VHD

Disques virtuels 4 Le disque de démarrage (parfois appelé disque

IDE d’amorçage) doit ê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 2048 pour la Le nombre de processeurs virtuels pris en charge par

virtuels génération 2 un système d’exploitation invité pourrait être
64 pour la inférieur. Pour plus d’informations, consultez les
génération 1 informations publiées pour le système d’exploitation
spécifique.

Contrôleurs SCSI 4 L’utilisation de périphériques SCSI virtuels nécessite

virtuels les services d’intégration, qui sont disponibles pour
les systèmes 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 SCSI 256 Chaque contrôleur SCSI prend en charge jusqu’à

virtuels 64 disques. En d’autres termes, chaque ordinateur
virtuel peut être configuré avec un maximum de
 Composant Maximale Notes

256 disques SCSI virtuels (4 contrôleurs x 64 disques

par contrôleur). (4 contrôleurs x 64 disques par
contrôleur).

Cartes réseau 68 adaptateurs au La carte réseau propre à Hyper-V offre de meilleures

virtuel total : performances et nécessite un pilote inclus dans les
64 cartes services d’intégration. Pour plus d’informations,
réseau consultez Planifier les réseaux Hyper-V dans Windows
propres à Server.
Hyper-V
4 cartes
réseau
héritées ;

Valeurs maximales pour les hôtes Hyper-V

Ces maximums s'appliquent à chaque hôte Hyper-V exécutant la version de produit
sélectionnée.

ﾉ Agrandir le tableau

Composant Maximale Notes

Processeurs 2 048 Ces deux fonctionnalités doivent être

logiques activées dans le micrologiciel :
Virtualisation assistée par le
matériel
Prévention de l’exécution des
données (DEP) appliquée par
matériel

Mémoire 4 PB pour les hôtes Aucune.

prenant en charge la
pagination à 5 niveaux
256 To pour les hôtes
prenant en charge la
pagination à 4 niveaux.

Association de Aucune limite imposée par Aucune.

cartes réseau Hyper-V.

Cartes réseau Aucune limite imposée par Aucune.

physiques Hyper-V.
 Composant Maximale Notes

Ordinateurs virtuels 1 024 Aucune.

en cours
d'exécution par
serveur

Stockage Limité par la capacité prise en Remarque : Microsoft prend en charge

charge par le système le stockage NAS (Network-Attached
d’exploitation de gestion. Storage) lors de l’utilisation de SMB 3.0.
Aucune limite imposée par Le stockage basé sur NFS n'est pas pris
Hyper-V. en charge.

Ports de Variable ; aucune limite La limite pratique varie en fonction des

commutateurs de imposée par Hyper-V. ressources informatiques disponibles.
réseau virtuel par
serveur

Processeurs virtuels 2 048 La limite est appliquée au système

disponibles pour d'exploitation de l'hôte (partition racine).
l'hôte

Processeurs virtuels Aucun ratio imposé par Hyper- Aucune.

par processeur V.
logique

Processeurs virtuels 2 048 Aucune.

par serveur

Réseaux de zone de Aucune limite imposée par Aucune.

stockage virtuels Hyper-V.

Commutateurs Variable ; aucune limite La limite pratique varie en fonction des

virtuels imposée par Hyper-V. ressources 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 planifier la capacité afin de s'assurer
qu'il y a suffisamment de ressources matérielles pour exécuter toutes les machines
virtuelles dans un environnement en grappe.

ﾉ Agrandir le tableau

Composant Maximale Notes

Nœuds par 64 Prenez en compte le nombre de nœuds que vous souhaitez

cluster réserver pour le basculement et les tâches de maintenance
 Composant Maximale Notes

telles que l'application de mises à jour. Nous vous

recommandons de prévoir suffisamment de ressources pour
qu'un nœud soit réservé au basculement. Cela signifie qu'il
reste inactif jusqu'à ce qu'un autre nœud soit basculé sur lui, ce
que l'on appelle parfois un nœud passif. Vous pouvez
augmenter ce nombre si vous souhaitez réserver davantage de
nœuds. Il n'y a pas de ratio ou de multiplicateur recommandé
entre les nœuds réservés et les nœuds actifs ; la seule exigence
est que le nombre total de nœuds dans une grappe ne dépasse
pas le maximum de 64.

Ordinateurs 8 000 par Plusieurs facteurs peuvent avoir une incidence sur le nombre
virtuels exécutés cluster réel d’ordinateurs virtuels que vous pouvez exécuter en même
simultanément temps sur un nœud, tels que :
par nœud - Quantité de mémoire physique utilisée par chaque ordinateur
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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Planifier la sécurité Hyper-V dans
Windows Server
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2016, Microsoft Hyper-V

Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

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é.

Pour plus d’informations, consultez Paramètres de sécurité des ordinateurs virtuels

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.

Pour plus d’informations, consultez Paramètres de sécurité des ordinateurs virtuels

de génération 2 et Infrastructure protégée.
Planifier l’accélération GPU dans
Windows Server
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

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 liées aux applications et au bureau à distance (VDI/DaaS) : Si

vous créez un service d'application ou de communication à distance avec Windows
Server, tenez compte du catalogue d'applications que vous attendez de vos
utilisateurs. 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 (VM) dotée
d'un GPU pourrait être en mesure d'égaler le débit de plusieurs VM dotées
uniquement d'un processeur.
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. Par ailleurs, elle
pourrait offrir un meilleur rapport coût-efficacité qu'une architecture basée sur le
processeur à un niveau de performance comparable. De nombreux frameworks de
calcul haute performance (HPC) et de machine learning peuvent utiliser
l'accélération GPU ; examinez si l'accélération GPU pourrait bénéficier à 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, alors vous devez employer la virtualisation
graphique afin de fournir une accélération GPU du GPU physique à vos apps 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)

Partitionnement du GPU (GPU-P)

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)

L’attribution d’un DDA (Discrete Device Assignment) vous permet de dédier un 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 développez une solution de services de bureau à distance,
vous pouvez améliorer l'échelle des utilisateurs en utilisant les capacités multisessions
de Windows Server pour héberger plusieurs bureaux d'utilisateurs sur chaque machine
virtuelle. Ces utilisateurs partagent les avantages de l'accélération GPU.

Pour plus d’informations, consultez les articles suivants :

 Planifier le déploiement Discrete Device Assignment
Déployer des appareils graphiques à l’aide de la technologie Discrete Device
Assignment

Partitionnement du GPU (GPU-P)

À partir de Windows Server 2025, le partitionnement GPU vous permet de partager un
appareil GPU physique avec plusieurs machines virtuelles (VM). Avec le partitionnement
du GPU ou la virtualisation du GPU, chaque machine virtuelle obtient une fraction
dédiée du processeur graphique (GPU) au lieu de l’ensemble du GPU.

La fonctionnalité de partitionnement de GPU utilise l’interface SR-IOV (Single Root IO

Virtualization, virtualisation d’E/S d’une racine unique), qui fournit une limite de sécurité
basée sur le matériel avec des performances prévisibles pour chaque machine virtuelle.
Chaque machine virtuelle peut accéder uniquement aux ressources GPU qui lui sont
dédiées et le partitionnement sécurisé du matériel empêche tout accès non autorisé par
d'autres machines virtuelles.

Pour en savoir plus sur le partitionnement GPU, consultez ces articles :

Partitionnement du GPU
Partitionner et affecter des GPU à une machine virtuelle

Comparaison entre le DDA et le GPU

partitionnement
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 :

ﾉ Agrandir le tableau

Description Attribution d’appareils en mode Partitionnement du GPU

discret

Modèle de Dédié uniquement Partitionné

ressource GPU

Densité de Faible (un ou plusieurs GPU sur une Élevée (un ou plusieurs GPU pour de
machines machine virtuelle) nombreuses machines virtuelles)
virtuelles
 Description Attribution d’appareils en mode Partitionnement du GPU
discret

Compatibilité des Toutes les fonctionnalités GPU Toutes les fonctionnalités GPU
applications fournies par le fournisseur (DX 12, fournies par le fournisseur (DX 12,
OpenGL, CUDA) OpenGL, CUDA)

AVC444 Disponible via les stratégies de Disponible via les stratégies de

groupe groupe

VRAM de GPU Jusqu’à la quantité de RAM vidéo Jusqu'à VRAM pris en charge par le
prise en charge par le GPU GPU par partition

Pilote GPU dans Pilote de fournisseur GPU (NVIDIA, Pilote de fournisseur GPU (NVIDIA,
l’invité AMD, Intel) AMD, Intel)

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Planifier le déploiement de
périphériques à l’aide de l’attribution de
périphérique en mode discret
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

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 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 appareil est identifié comme étant incompatible avec l’affectation
d’appareil discret, 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é.
Commentaires
Cette page a-t-elle été utile ?  Yes  No
Qu’est-ce que la virtualisation
imbriquée ?
Article • 31/07/2024

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. Un
niveau de virtualisation imbriquée est pris en charge en production, ce qui permet des
déploiements de conteneurs isolés.

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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Configurer des réseaux locaux virtuels
pour Hyper-V
Article • 16/08/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Local, versions 23H2
and 22H2

Les réseaux locaux virtuels (VLAN) offrent un moyen d’isoler le trafic réseau. Les réseaux
locaux virtuels sont configurés dans des commutateurs et des routeurs qui prennent en
charge 802.1q. Si vous configurez plusieurs réseaux locaux virtuels et que vous souhaitez
que la communication se produise entre eux, vous devez configurer les périphériques
réseau pour permettre cela.

Vous avez besoin des éléments suivants pour configurer des réseaux locaux virtuels :

Une carte réseau physique et un pilote qui prend en charge l’étiquetage VLAN
802.1q.
Commutateur de réseau physique qui prend en charge l’étiquetage VLAN 802.1qq.

Sur l’hôte, vous configurez le commutateur virtuel pour autoriser le trafic réseau sur le
port du commutateur physique. Il s’agit des ID de VLAN que vous souhaitez utiliser en
interne avec des machines virtuelles. Ensuite, vous configurez la machine virtuelle pour
spécifier le VLAN que la machine virtuelle utilise pour toutes les communications réseau.

Pour autoriser un commutateur virtuel à utiliser

un VLAN
1. Dans le Gestionnaire Hyper-V, sélectionnez Gestionnaire de commutateur virtuel
dans le volet Actions à droite.

2. Dans Gestionnaire de commutateur virtuel, sous Commutateurs virtuels à

gauche, sélectionnez un commutateur virtuel connecté à une carte réseau
physique prenant en charge les réseaux locaux virtuels.

3. Sous ID de réseau local virtuel dans le volet droit, sélectionnez Activer

l’identification de réseau local virtuel pour le système d’exploitation de gestion,
puis tapez un numéro pour l’ID de réseau local virtuel.

4. Sélectionnez OK.
Tout le trafic qui passe par la carte réseau physique connectée au commutateur virtuel
est marqué avec l’ID du réseau local virtuel que vous avez défini.

Pour autoriser une machine virtuelle à utiliser

un VLAN
1. Dans le Gestionnaire Hyper-V, sous Machines virtuelles, cliquez avec le bouton
droit sur la machine virtuelle appropriée, puis sélectionnez Paramètres. Vous
pouvez également sélectionner l’ordinateur, puis Paramètres sous le nom de
l’ordinateur dans le volet droit.

2. Dans l’écran Paramètres, sous Matériel dans le volet gauche, sélectionnez une
Carte réseau avec un commutateur virtuel configuré avec un réseau local virtuel.

3. Sous ID du réseau local virtuel dans le volet droit, sélectionnez Activer

l’identification de réseau local virtuel, puis tapez le même ID de réseau local
virtuel que celui que vous avez spécifié pour le commutateur virtuel.

4. Sélectionnez OK.

Si la machine virtuelle doit utiliser davantage de réseaux locaux virtuels, effectuez l’une
des opérations suivantes :

Connectez d’autres cartes réseau virtuelles aux commutateurs virtuels appropriés

et affectez les ID VLAN. Veillez à configurer correctement les adresses IP et à ce
que le trafic que vous souhaitez acheminer via le VLAN utilise également l’adresse
IP appropriée.

Configurez la carte réseau virtuelle en mode jonction à l’aide de la cmdlet Set-

VMNetworkAdapterVlan.

Voir aussi
Commutateur virtuel Hyper-V

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Exporter et importer des machines
virtuelles
Article • 11/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 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

Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

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

Import-VM -Path 'C:\<vm export path>\2B91FEB3-F1E0-4FFF-B8BE-

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 • 25/10/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

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.

Mise à niveau vers Windows Server 2025

À compter de Windows Server 2025, Credential Guard est activé par défaut sur tous les
serveurs joints à un domaine qui ne sont pas des contrôleurs de domaine. Par
conséquent, vous ne pouvez pas utiliser la migration dynamique basée sur CredSSP avec
Hyper-V après la mise à niveau vers Windows Server 2025. La délégation basée sur
CredSSP est la valeur par défaut pour Windows Server 2022 et les versions antérieures
pour la migration dynamique. Utilisez plutôt la délégation Kerberos contrainte, comme
décrit dans la section suivante. Pour plus d’informations, consultez Migration dynamique
avec des interruptions Hyper-V lors de la mise à niveau vers Windows Server 2025.

É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

ordinateurs sources et cible pour la migration dynamique
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.

ﾉ Agrandir le tableau

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 Copie la mémoire de la machine virtuelle sur le serveur de destination 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.
 Option Description

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
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
Windows de l’hôte
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
Windows de l’hôte
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
Windows de l’hôte
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
Emplacement par défaut : C:\ProgramData\Microsoft\Windows\Hyper-
V\Virtual Machines

Disque dur Stocke les disques durs virtuels pour la machine virtuelle.
virtuel Extension de nom de fichier : .vhd ou .vhdx
Emplacement par défaut : C:\ProgramData\Microsoft\Windows\Hyper-
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
Emplacement par défaut : C:\ProgramData\Microsoft\Windows\Hyper-
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 • 17/05/2024

Apprenez à utiliser Discrete Device Assignment (DDA) pour passer un appareil PCIe
entier dans une machine virtuelle (VM) avec PowerShell. 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.

Cet article vous présente les étapes à suivre 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

Prérequis
Avant de pouvoir utiliser DDA pour déployer des appareils graphiques, vous devez
disposer des éléments suivants :

Un hôte Hyper-V exécutant Windows Server 2016 ou une version ultérieure.

Une machine virtuelle exécutant l'un des systèmes d'exploitation suivants :

Windows Server 2016 ou ultérieur.

Windows 10 ou version ultérieure.

Examinez le plan de déploiement des appareils à l'aide de l'attribution discrète des

appareils pour vous assurer que votre matériel est compatible avec l'attribution
discrète des appareils.
Exécutez le script PowerShell SurveyDDA.ps1. PowerShell pour déterminer si
le serveur est configuré correctement. Le script affiche également les appareils
qui peuvent être passés-through en utilisant Discrete Device Assignment.

Des droits d'administration sur l'hôte Hyper-V.

 (Facultatif) Bien que cela ne soit pas obligatoire, si la virtualisation d'E/S à racine
unique (SR-IOV) n'est pas activée ou prise en charge, vous risquez de rencontrer
des problèmes lorsque vous utilisez DDA pour déployer des appareils graphiques.

Configurer la machine virtuelle pour DDA

La première étape de la solution consiste à traiter les restrictions DDA aux machines
virtuelles.

1. Connectez-vous à l'hôte Hyper-V en tant qu'administrateur.

2. Ouvrez une invite PowerShell avec élévation de privilèges.

3. 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 (memory mapped IO) 32 bits à l'aide de la cmdlet

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. Mais s'ils fournissent un pilote, installez-le avant de démonter
l'appareil 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.

Exemple - Montage d'un GPU dans 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 montez un GPU dans une machine virtuelle mais que Remote Desktop Services
ou une application ne reconnaît pas le GPU, vérifiez les problèmes courants suivants.

Assurez-vous que vous installez 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é). Naviguez jusqu'à 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 valeur de la stratégie de groupe sur Activé, puis redémarrez la

machine virtuelle après avoir appliqué la stratégie.
Déployer des appareils de stockage
NVMe à l’aide de la technologie Discrete
Device Assignment
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

À 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 :

Configurer la machine virtuelle pour DDA

Démonter l’appareil de la partition hôte
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.

Configurer la machine virtuelle pour DDA

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

Démonter l’appareil de la partition hôte

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
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
Applets de commande pour la
configuration d’appareils à mémoire
persistante pour les machines virtuelles
Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Local, versions 23H2 and 22H2

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Applets de commande pour la
configuration d’appareils à mémoire
persistante pour les machines virtuelles
Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Local, versions 23H2 and 22H2

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Choisir entre des points de contrôle
standard ou de production dans Hyper-
V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

À 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).

Références supplémentaires
Points de contrôle de production

Activer ou désactiver des points de contrôle

Commentaires
Cette page a-t-elle été utile ?  Yes  No
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 • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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.

Références supplémentaires
Choisir entre des points de contrôle standard ou de production dans Hyper-V

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Gérer des hôtes Hyper-V distants avec le
Gestionnaire Hyper-V
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
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
d’installation, et la version correspondante d’Hyper-V Server
- 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
d’installation, et la version correspondante d’Hyper-V Server
- Windows 8.1

Windows Server 2012 - Windows Server 2012 : toutes les éditions et options
d’installation, et la version correspondante d’Hyper-V Server

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 :

1. Dans le volet gauche, cliquez avec le bouton droit sur Gestionnaire Hyper-V.
2. Cliquez sur Se connecter au serveur.
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.

Se connecter à un hôte distant Windows Server 2016 ou

Windows 10 en utilisant une adresse IP
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. Entrez l’adresse IP dans le champ texte Un autre ordinateur.

７ Notes

Ceci va fonctionner seulement pour les hôtes distants Windows Server 2016 ou
Windows 10.
Se connecter à un hôte distant Windows Server 2016 ou
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.

4. Ouvrez le Gestionnaire Hyper-V.

5. Dans le volet gauche, cliquez avec le bouton droit sur Gestionnaire Hyper-V.

6. Cliquez sur Se connecter au serveur.

７ Notes

Ceci va fonctionner seulement pour les hôtes distants Windows Server 2016 ou
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

Références supplémentaires
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

S’applique à : Windows Server 2022, Windows Server 2016, Microsoft Hyper-V

Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

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
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ ----------
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

C:\vm\tools>CpuGroups.exe GetGroups
CpuGroupId CpuCap LpIndexes
------------------------------------ ------ ---------
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

CpuGroupId CpuCap LpIndexes

------------------------------------ ------ ---------
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

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 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

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-
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
 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 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

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
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 2016 1703 2018.07 C KB4338827

Windows Server 2016 1709 2018.07 C KB4338817

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

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
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

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016,
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

2. La sortie doit être semblable à ce qui suit :

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

4. La sortie doit être semblable à ce qui suit :

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_

6. La sortie doit être semblable à ce qui suit :

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 :

1. Ouvrez le Gestionnaire Hyper-V.

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 • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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 -VMId <VM GUID>

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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Configurer le réplica Hyper-V
Article • 28/08/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

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 : Si une panne survient sur votre site principal (ou secondaire s'il est
étendu), vous pouvez lancer manuellement un basculement test, planifié ou non
planifié.

ﾉ Agrandir le tableau

Question Test Prévu Non planifié

Quand dois- Vérifiez qu’une machine Pendant les temps Durant des
je le faire ? virtuelle peut basculer vers le d’arrêt et interruptions événements
site secondaire et démarrer planifiés inattendus
sur ce site
Utile lors des phases de test et
d’apprentissage

Une machine Oui No Non

virtuelle
dupliquée
est-elle
créée ?

Où Sur la machine virtuelle de Lancée sur l’ordinateur Sur la machine

l’opération réplication principal, puis se virtuelle de
est-elle termine sur réplication
lancée ? l’ordinateur secondaire

À quelle Nous vous recommandons de Une fois tous les six Uniquement en
fréquence l’exécuter une fois par mois mois ou à une autre cas de sinistre
l’exécuter ? pour les tests fréquence lorsque la
conformément aux machine
exigences de virtuelle
conformité principale n’est
pas disponible

La réplication Oui Oui. Lorsque Non

de la l’interruption est
machine résolue, la réplication
virtuelle inversée réplique les
principale se modifications sur le
poursuit- site principal pour
elle ? garantir la
synchronisation entre
le site principal et les
sites secondaires.

Cela None Aucun. Après le Cela dépend de

entraîne-t-il basculement, le réplica l’événement et
une perte de Hyper-V réplique le des points de
données ? dernier ensemble de récupération
modifications suivies
 Question Test Prévu Non planifié

vers le site principal

pour empêcher toute
perte de données.

Y a-t-il des Aucun. Cela n’impacte pas Durée de l’interruption Durée de

temps d’arrêt votre environnement de planifiée l’interruption
? production. Une machine non planifiée
virtuelle de test dupliqué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 pouviez
accéder aux points de récupération jusqu'à 24 heures auparavant.

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 vos considérations en
matière de bande passante ? Vos machines virtuelles hautement critiques
nécessiteront é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. Démarrez et installez le rôle Hyper-V sur Windows Server.
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 ce faire, vous devez connecter le stockage
externe au serveur primaire (ou au nœud propriétaire dans un cluster), puis,
lorsque vous sélectionnez Envoyer une copie initiale à l'aide d'un support externe,
vous pouvez spécifier un emplacement local ou sur votre support externe où la
copie initiale peut être stockée. 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 .
Commentaires
Cette page a-t-elle été utile ?  Yes  No
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
dynamique
Article • 10/07/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Local, versions 23H2 and 22H2

Le mode de compatibilité du processeur dynamique est mis à jour pour tirer parti des
nouvelles fonctionnalités du processeur dans un environnement cluster. Le
fonctionnement de la compatibilité du processeur est fondé sur la détermination des
fonctionnalités du processeur prises en charge pour chaque nœud individuel du cluster
et sur le calcul du dénominateur commun à tous les processeurs. Les machines virtuelles
(VM) sont configurées de manière à utiliser le nombre maximal de fonctionnalités
disponibles sur tous les serveurs du cluster. Cela permet d’améliorer les performances
par rapport à la version précédente de la compatibilité du processeur qui possède par
défaut un ensemble minimal et fixe de fonctionnalités du processeur.

À quel moment utiliser le mode de

compatibilité du processeur
Le mode de compatibilité du processeur vous permet de déplacer une machine virtuelle
dynamique (migration dynamique) ou de déplacer une machine virtuelle enregistrée
entre les nœuds avec différents ensembles de fonctionnalités de processus. Toutefois,
même lorsque la compatibilité du processeur est activée, vous ne pouvez pas déplacer
de machines virtuelles entre des hôtes ayant des fabricants de processeurs différents.
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 de cette façon, arrêtez d’abord la machine virtuelle, puis
redémarrez-la sur le nouvel hôte.

） Important

Seules les machines virtuelles Hyper-V dotées de la dernière version de la

configuration (10.0) peuvent profiter de la configuration dynamique. Les machines
virtuelles avec des versions antérieures ne bénéficient pas de la configuration
dynamique et n’continueront pas à utiliser les fonctionnalités de processeur fixe de
la version précédente.
 ７ Notes

Vous ne devez pas utiliser le mode de compatibilité du processeur si vous prévoyez

d’arrêter et de redémarrer les machines virtuelles. 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.

Pourquoi le mode de compatibilité du

processeur est-il nécessaire
Les fabricants de processeur introduisent souvent des optimisations et des
fonctionnalités dans leurs 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 que les applications s’exécutent ; ils augmentent 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 la capacité du processeur du système lorsqu’ils
sont lancés pour la première fois. Le logiciel ne s’attend pas à ce que les fonctionnalités
de processeur disponibles changent pendant leur durée de vie, ce qui ne se produit
jamais lors de l’exécution sur un ordinateur physique, car les fonctionnalités du
processeur sont statiques, sauf si le processeur est mis à niveau.

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 détecte et démarre à l’aide d’une fonctionnalité de
processeur particulière, puis que la machine virtuelle est déplacée vers un nouvel hôte
de virtualisation sans cette fonctionnalité, le logiciel échouera probablement. Cela peut
entraîner un incident au niveau de l’application ou de la machine virtuelle.

Pour éviter les défaillances, Hyper-V effectue des vérifications de « préversion » chaque
fois qu’une migration dynamique de machine virtuelle ou une opération
d’enregistrement/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.
Nouveautés du mode de compatibilité du
processeur
Auparavant, tous les nouveaux ensembles d’instructions de processeur étaient masqués,
ce qui signifie que le système d’exploitation invité et le logiciel d’application ne
pouvaient pas utiliser les améliorations apportées au jeu d’instructions de processeur
pour aider les applications et les machines virtuelles à rester performantes.

Pour surmonter cette limitation, le mode de compatibilité du processeur fournit

désormais des fonctionnalités dynamiques améliorées sur les processeurs capables de
traduction d’adresses de deuxième niveau (SLAT). Cette nouvelle fonctionnalité calcule
le dénominateur commun des fonctionnalités de processeur prises en charge par les
nœuds du cluster et met à jour le mode de compatibilité du processeur existant sur une
machine virtuelle pour utiliser ce jeu de fonctionnalités calculées dynamiquement à la
place de l’ancien ensemble de fonctionnalités codées en dur.

Le nouveau mode de compatibilité du processeur garantit que l’ensemble des

fonctionnalités du processeur disponibles pour les machines virtuelles sur les hôtes de
virtualisation correspondent en présentant un ensemble de fonctionnalités commun sur
tous les serveurs du cluster. Chaque machine virtuelle reçoit le nombre maximal de jeux
d’instructions du processeur qui sont présents sur tous les serveurs du cluster. Ce
processus s’effectue automatiquement et est toujours activé et répliqué sur le cluster. Il
n’y a donc pas de commande permettant d’activer ou de désactiver le processus.

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 fonctionnalité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.

Migration de machines virtuelles en cours

d’exécution entre des clusters
En supposant que tous les serveurs de chaque cluster exécutent le même matériel, il est
possible de migrer en direct des machines virtuelles en cours d’exécution entre des
clusters. Il existe trois scénarios courants.

Migration dynamique d’une machine virtuelle à partir d’un cluster avec de

nouveaux processeurs vers un cluster équipé des mêmes processeurs. Les
fonctionnalités de machine virtuelle sont transférées vers le cluster de destination.
Ce scénario ne nécessite pas que le mode de compatibilité du processeur soit
activé ; toutefois, le fait de le laisser activé n’entraîne aucun problème.

Migration dynamique d’une machine virtuelle à partir d’un cluster possédant de

nouveaux processeurs vers un cluster possédant des processeurs encore plus
récents. Les fonctionnalités de machine virtuelle sont transférées vers le cluster de
destination. Dans ce scénario, si la machine virtuelle est redémarrée, elle reçoit la
dernière fonctionnalité calculée du cluster de destination.

Migration dynamique d’une machine virtuelle à partir d’un cluster possédant de

nouveaux processeurs vers un cluster possédant d’anciens processeurs. Vous
devez définir le processeur VM pour utiliser le MinimumFeatureSet pour le
paramètre CompatibilityForMigrationMode dans PowerShell, ou sélectionner
Compatible avec les autres hôtes qui ont le même fabricant de processeur dans
Windows Admin Center sous Machines virtuelles > Paramètres > Processeurs. Ce
paramètre affecte la machine virtuelle aux fonctionnalités minimales du processeur
proposées sur le serveur. Une fois la compatibilité déplacée vers Compatible sur le
cluster (recommandé) et que la machine virtuelle est redémarrée, elle reçoit la
dernière fonctionnalité calculée du cluster de destination.

Ramifications de l’utilisation du mode de

compatibilité du processeur
Il est difficile de quantifier les effets globaux des 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 peuvent ne pas être affectées, tandis que d’autres présentent une différence
notable. Les logiciels qui reposent fortement sur des optimisations matérielles (telles
que le chiffrement, la compression ou des calculs à virgule flottante intensive) sont
impactés le plus.

Les applications qui chiffrent ou déchiffrent une grande quantité de données bénéficient
de cette fonctionnalité de processeur, de sorte que la désactivation en activant le mode
de compatibilité du processeur affecte les performances de ces opérations spécifiques.

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 avec celui-ci
désactivé.

Configurer une machine virtuelle de manière à

utiliser le mode de compatibilité du processeur
Cette section explique comment configurer une machine virtuelle pour utiliser le mode
de compatibilité du processeur à l’aide du gestionnaire Hyper-V ou de PowerShell. Il est
possible d’exécuter des machines virtuelles avec et sans le mode de compatibilité dans
le même cluster.

） Important

Vous devez arrêter la machine virtuelle avant de pouvoir activer ou désactiver le

mode de compatibilité du processeur.

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. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez

Gestionnaire Hyper-V.
 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, sélectionnez Paramètres, puis sélectionnez Processeur.

6. Développez Processeur, puis sélectionnez Compatibilité.

7. Sélectionnez Migrer vers un ordinateur physique avec un autre processeur, puis

sélectionnez 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. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez

Gestionnaire Hyper-V.

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, sélectionnez Paramètres, puis sélectionnez Processeur.

6. Développez Processeur, puis sélectionnez Compatibilité.

7. Désactivez la case Migrer vers un ordinateur physique avec une case à cocher de
processeur différente, puis sélectionnez OK.

8. Redémarrez la machine virtuelle.

Activer le mode de compatibilité du processeur avec

PowerShell
Pour activer le mode de compatibilité du processeur, exécutez la cmdlet suivante :

PowerShell
 get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-
VMProcessor -CompatibilityForMigrationEnabled $true

Nous vous recommandons de définir les fonctionnalités processeur de la machine

virtuelle sur le niveau maximal pris en charge par tous les serveurs du cluster. Cela
optimise les performances de la machine virtuelle tout en gardant la possibilité de
déplacer la machine virtuelle en cours d’exécution vers d’autres serveurs du cluster.

Pour permettre à la machine virtuelle d’utiliser les fonctionnalités courantes du nœud de

cluster, exécutez la cmdlet suivante :

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true -
CompatibilityForMigrationMode CommonClusterFeatureSet

Vous pouvez également définir les fonctionnalités processeur de la machine virtuelle sur
le niveau minimal pour être sûr de pouvoir déplacer la machine virtuelle en cours
d’exécution vers d’autres hôtes Hyper-V en dehors du cluster s’ils ont le même fabricant
de processeur.

Pour permettre à la machine virtuelle d’utiliser les fonctionnalités minimales par défaut
afin d’effectuer une migration entre les clusters, exécutez la cmdlet suivante :

PowerShell

get-vm -name <name of VM> -ComputerName <target cluster or host> | Set-

VMProcessor -CompatibilityForMigrationEnabled $true -
CompatibilityForMigrationMode MinimumFeatureSet

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
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)

Migration dynamique (Windows Server 2012 R2)
Clustering de basculement (Windows Server 2012 R2)
Clustering de basculement (Windows Server 2008 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
System Center Virtual Machine Manager (System Center 2008 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 :

Configurer des hôtes une migration dynamique sans clustering de basculement

Utiliser la migration dynamique sans le clustering de basculement pour déplacer
une machine virtuelle
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)

Migration dynamique (Windows Server 2012 R2)
Clustering de basculement (Windows Server 2012 R2)
Clustering de basculement (Windows Server 2008 R2)
System Center Virtual Machine Manager (System Center 2012 R2)
System Center Virtual Machine Manager (System Center 2008 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 :

Configurer des hôtes une migration dynamique sans clustering de basculement

Utiliser la migration dynamique sans le clustering de basculement pour déplacer
une machine virtuelle
Configurer des hôtes une migration
dynamique sans clustering de
basculement
Article • 25/10/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Azure Stack HCI, versions 23H2 and 22H2

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.

Mise à niveau vers Windows Server 2025

À compter de Windows Server 2025, Credential Guard est activé par défaut sur tous les
serveurs joints à un domaine qui ne sont pas des contrôleurs de domaine. Par
conséquent, vous ne pouvez pas utiliser la migration dynamique basée sur CredSSP avec
Hyper-V après la mise à niveau vers Windows Server 2025. La délégation basée sur
CredSSP est la valeur par défaut pour Windows Server 2022 et les versions antérieures
pour la migration dynamique. Utilisez plutôt la délégation Kerberos contrainte, comme
décrit dans la section suivante. Pour plus d’informations, consultez Migration dynamique
avec des interruptions Hyper-V lors de la mise à niveau vers Windows Server 2025.

É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

ordinateurs sources et cible pour la migration dynamique
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.

ﾉ Agrandir le tableau

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 Copie la mémoire de la machine virtuelle sur le serveur de destination 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.
 Option Description

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.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Utiliser la migration dynamique sans le
clustering de basculement pour
déplacer une machine virtuelle
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

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.

Le rôle Hyper-V dans Windows Server 2016 ou Windows Server 2012 R2 installé
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.

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
Configurer des hôtes pour la migration dynamique.

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 de là.

Utiliser le Gestionnaire Hyper-V pour déplacer

une machine virtuelle en cours d’exécution
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 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

une machine virtuelle
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 • 12/03/2024

Hyper-V joue le rôle de serveur de virtualisation dans Windows Server et Azure Stack
HCI. 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.

Références supplémentaires
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

Commutateur virtuel Hyper-V
Article • 14/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

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.

Gérer le commutateur virtuel Hyper-V

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.
Configuration réseau requise pour Azure
Local
Article • 23/11/2024

S’applique à : Azure Local, versions 23H2 et 22H2

Cette rubrique décrit les considérations et exigences relatives à la mise en réseau de l’hôte pour Azure
Local. Pour plus d’informations sur les architectures de centre de données et les connexions physiques
entre les machines, consultez configuration réseau physique requise.

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 local Azure peut être classifié par son objectif prévu :

Trafic de gestion : trafic vers ou depuis l’extérieur du système local. Par exemple, le trafic de
réplica de stockage ou le trafic utilisé par l’administrateur pour la gestion du système, comme le
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 une machine pour Azure Local, vous devez disposer minimalement d’au moins un adaptateur
qualifié pour la gestion, le calcul et le stockage, car les trois types de trafic sont requis sur Azure Local.
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
billet de blog Windows Server.
 ） Important

L’utilisation d’un adaptateur en dehors de son type de trafic qualifié n’est pas prise en charge.

ﾉ Agrandir le tableau

Niveau Rôle de gestion Rôle de calcul Rôle de stockage

Distinction basée sur les rôles Gestion Standard de calcul Storage Standard

Prix maximal 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 Local.
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 de carte réseau utilisées par Azure Local sont les suivantes :

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 Dynamic
VMMQ. 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 ;
Permet aux charges de travail « bursty » de recevoir la quantité attendue de trafic.

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 la 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 Local prend en charge RDMA avec les implémentations de protocole RDMA (iWARP) ou RDMA
sur des implémentations de protocole Ethernet convergé (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 offrent 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
rechercher des adaptateurs avec la qualification Stockage (Standard) ou Stockage (Premium) qui
nécessitent une prise en charge RDMA.

７ Notes

InfiniBand (IB) n’est pas pris en charge avec Azure Local.

ﾉ Agrandir le tableau

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
référentiel 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 de gestion des réseaux RDMA.

Vous ne gérez pas ou n’êtes pas à l’aise avec la gestion de 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 (Switch Embedded Teaming)

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
est la seule technologie d’association prise en charge par Azure Local. SET fonctionne bien avec le
trafic de calcul, de stockage et de gestion et est pris en charge avec jusqu’à huit adaptateurs dans la
même équipe.

Types de trafic applicables : calcul, stockage et gestion

Certifications requises : Calcul (Standard) ou Calcul (Premium)

SET est la seule technologie d’association prise en charge par Azure Local. La fonctionnalité SET
fonctionne avec le trafic de calcul, de stockage et de gestion.

） Important

Azure Local ne prend pas en charge l’association de cartes réseau avec l’ancien équilibrage de
charge/basculement (LBFO). Consultez le billet de blog Teaming dans Azure Local pour plus
d’informations sur LBFO dans Azure Local.

SET est important pour Azure Local, car il s’agit de la seule technologie d’association qui permet :

Association d’adaptateurs RDMA (si nécessaire).

RDMA invité.
Dynamic VMMQ.
Autres fonctionnalités clés d’Azure Local (consultez Teaming dans Azure Local ).

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 et vous informe automatiquement si les adaptateurs que vous avez
choisis sont asymétriques. Le moyen le plus simple d’identifier manuellement si les adaptateurs sont
symétriques est que 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 :

ﾉ Agrandir le tableau

Nom Description de l’interface Vitesse de liaison

NIC1 Carte réseau 1 25 Gbits/s

NIC2 Carte réseau 2 25 Gbits/s

NIC3 Carte réseau 3 25 Gbits/s

NIC4 Carte réseau 4 25 Gbits/s

７ 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 locales Azure basées sur RoCE nécessitent la configuration de trois classes de
trafic PFC, y compris la classe de trafic par défaut, dans l’infrastructure et tous les hôtes.

Classe de trafic système

Cette classe de trafic garantit qu’il existe suffisamment de bande passante réservée pour les pulsations
système :

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 transporte tout autre trafic non défini dans les classes de trafic système ou
RDMA, notamment le trafic de machine virtuelle et le trafic de gestion :

Obligatoire : 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 hôte requise)

Modèles de trafic de stockage

SMB offre de nombreux avantages en tant que protocole de stockage pour Azure Local, 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 locaux virtuels pour
séparer le trafic de stockage dans Azure Local.

Prenons l’exemple suivant d’un système à quatre nœuds. Chaque machine a 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 gauche sur la première machine (192.168.1.1)) établira une connexion au port de
gauche sur la deuxième machine (192.168.1.2). Le port de droite sur la première machine
(192.168.1.12) se connecte au port de droite sur la deuxième machine. Des connexions similaires sont
établies pour les troisième et quatrième machines.

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 montre des exemples d’allocations de bande passante de différents types de trafic,
à l’aide de vitesses d’adaptateur courantes, dans Azure Local. 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 :

ﾉ Agrandir le tableau

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

 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

25 Gbits/s 50 Gbit/s 25 Gbits/s 70 % 17,5 29 % 7,25 Gbit/s 1% 250 Mbit/s

Gbit/s

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 cluster étendu d’Azure Local ressemble à ceci :

Exigences des clusters étendus

） Important
 La fonctionnalité de cluster étendu est disponible uniquement dans Azure Local version 22H2.

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 machines du même site doivent résider 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.

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.

É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 .
Consultez Déployer à l’aide de Portail Azure.
Consultez Déployer à l’aide du modèle Azure Resource Manager.

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Indiquer des commentaires sur le produit
Gérer le commutateur virtuel Hyper-V
Article • 02/11/2024 •
S’applique ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅
à: Windows Server 2016, ✅ Windows 11, ✅ Windows 10, ✅ Azure Stack HCI, versions
23H2 and 22H2

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

Commentaires
Cette page a-t-elle été utile ?  Yes  No
Créer des stratégies de sécurité avec les
listes de contrôle d’accès de ports
étendues
Article • 17/04/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

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.

Mettre en œuvre une sécurité au niveau de l’application

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

Mettre en œuvre une sécurité au niveau de l’application

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
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Outbound" -RemoteIPAddress 10.175.124.0/25 -RemotePort 67 -
Protocol "UDP"-Weight 20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
Direction "Inbound" -RemoteIPAddress 10.175.124.0/25 -RemotePort 68 -
Protocol "UDP"-Weight 20

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.

Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -

Direction "Inbound" -Protocol 2 -Weight 20
Add-VMNetworkAdapterExtendedAcl -VMName "ServerName" -Action "Allow" -
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.

Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -

Direction "Inbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Deny" -
Direction "Outbound" -Weight 1
Add-VMNetworkAdapterExtendedAcl -VMName "ApplicationServer" -Action "Allow"
-Direction "Outbound" 80 "TCP" -Weight 100 -Stateful -Timeout 3600