Administrer Hyper-V au quotidien ne nécessite pas de tout faire dans Hyper-V Manager. Le module PowerShell Hyper-V fourni avec Windows Server 2022 et Windows Server 2025 couvre l’essentiel des opérations d’inventaire, de création, d’exploitation, de protection et de migration des machines virtuelles. Il est particulièrement utile pour standardiser les actions, automatiser les contrôles et intervenir à distance sur plusieurs hôtes.

Avant de commencer, vérifier que le rôle Hyper-V et ses outils de gestion sont installés. Sur un serveur d’administration, les outils RSAT Hyper-V peuvent suffire si la délégation et le pare-feu WinRM sont correctement configurés.

Get-WindowsFeature Hyper-V*
Get-Module -ListAvailable Hyper-V
Import-Module Hyper-V

Pour exécuter des commandes contre un hôte distant, la plupart des cmdlets acceptent le paramètre -ComputerName.

Get-VM -ComputerName HVHOST01
Get-VMHost -ComputerName HVHOST01

Dans un environnement de cluster, privilégier également les cmdlets du module FailoverClusters pour connaître le propriétaire d’un rôle ou déplacer une ressource clusterisée. Les cmdlets Hyper-V pilotent la couche de virtualisation ; le cluster reste l’autorité de placement et de haute disponibilité.

Inventorier les VM et l’hôte Hyper-V

Get-VM est la commande centrale pour lister les machines virtuelles locales ou distantes. Sans paramètre, elle retourne les VM de l’hôte local. La référence complète du module PowerShell Hyper-V sur Microsoft Learn liste l’ensemble des cmdlets et leur syntaxe.

Get-VM

Quelques propriétés sont particulièrement utiles en exploitation : état d’alimentation, version de configuration, mémoire attribuée, nombre de processeurs virtuels, uptime et état de réplication éventuel.

Get-VM |
    Select-Object Name, State, Status, Version, Generation,
                  ProcessorCount, MemoryStartup, Uptime

Pour filtrer uniquement les VM démarrées :

Get-VM | Where-Object State -eq 'Running'

Pour identifier les VM arrêtées ou en erreur :

Get-VM |
    Where-Object { $_.State -ne 'Running' -or $_.Status -ne 'Operating normally' } |
    Select-Object Name, State, Status

La commande accepte le nom d’une VM, avec prise en charge des jokers. Cela simplifie les opérations par lot, mais impose de vérifier la sélection avant une action destructive.

Get-VM -Name 'WEB-*'
Get-VM -Name 'SQL-PRD-01'

Get-VMHost expose la configuration globale de l’hôte : chemins par défaut, nombre de migrations simultanées, paramètres NUMA, mode de migration en direct, configuration Enhanced Session Mode et informations sur les adaptateurs réseau dédiés à la migration.

Get-VMHost | Format-List *

Les propriétés les plus consultées sont généralement les chemins de stockage par défaut et les réglages de migration.

Get-VMHost |
    Select-Object VirtualMachinePath,
                  VirtualHardDiskPath,
                  MaximumStorageMigrations,
                  MaximumVirtualMachineMigrations,
                  VirtualMachineMigrationEnabled,
                  VirtualMachineMigrationAuthenticationType,
                  VirtualMachineMigrationPerformanceOption

Pour inspecter la configuration matérielle virtuelle d’une VM, utiliser les cmdlets spécialisées plutôt que de se limiter à Get-VM.

Get-VMProcessor -VMName 'APP-PRD-01'
Get-VMMemory -VMName 'APP-PRD-01'
Get-VMNetworkAdapter -VMName 'APP-PRD-01'
Get-VMHardDiskDrive -VMName 'APP-PRD-01'
Get-VMDvdDrive -VMName 'APP-PRD-01'

Un inventaire synthétique des adaptateurs réseau et de leur vSwitch peut être produit ainsi :

Get-VM | ForEach-Object {
    $vm = $_
    Get-VMNetworkAdapter -VMName $vm.Name |
        Select-Object @{Name='VM'; Expression={$vm.Name}},
                      Name, SwitchName, MacAddress, Status, IPAddresses
}

Les adresses IP retournées dépendent des services d’intégration Hyper-V et de l’état du système invité. Elles ne constituent pas une source d’inventaire fiable pour toutes les VM, notamment les appliances, les systèmes anciens ou les VM dont les services d’intégration ne remontent pas correctement. Pour aller plus loin, consultez le comparatif Hyper-V contre VMware.

Créer une VM de manière reproductible

La création d’une VM ne se limite pas à New-VM. Une procédure correcte doit définir au minimum la génération, l’emplacement des fichiers, la mémoire, les vCPU, le réseau, le disque système et éventuellement les paramètres Secure Boot.

Pour une VM Windows ou Linux moderne, la génération 2 est le choix normal. Elle apporte notamment le démarrage UEFI, Secure Boot, le support du démarrage réseau moderne et une meilleure cohérence avec les systèmes récents. La génération 1 reste nécessaire pour certains systèmes invités hérités.

Exemple de création d’une VM génération 2 avec disque VHDX dynamique, vSwitch existant et ISO d’installation :

$VMName = 'APP-PRD-01'
$VMPath = 'D:\Hyper-V\VMs\APP-PRD-01'
$VHDPath = 'D:\Hyper-V\VHDX\APP-PRD-01_OS.vhdx'
$ISOPath = 'D:\ISO\Windows_Server_2025.iso'
$SwitchName = 'vSwitch-Production'

New-VM -Name $VMName `
       -Generation 2 `
       -Path $VMPath `
       -MemoryStartupBytes 4GB `
       -NewVHDPath $VHDPath `
       -NewVHDSizeBytes 100GB `
       -SwitchName $SwitchName

Set-VMProcessor -VMName $VMName -Count 4

Set-VMMemory -VMName $VMName `
             -DynamicMemoryEnabled $true `
             -MinimumBytes 2GB `
             -StartupBytes 4GB `
             -MaximumBytes 16GB

Add-VMDvdDrive -VMName $VMName -Path $ISOPath

Set-VMFirmware -VMName $VMName `
               -FirstBootDevice (Get-VMDvdDrive -VMName $VMName)

Start-VM -Name $VMName

Pour une distribution Linux compatible Secure Boot, le modèle de certificat Microsoft UEFI Certificate Authority doit souvent être sélectionné. Le modèle par défaut vise les systèmes Microsoft.

Set-VMFirmware -VMName 'LINUX-PRD-01' `
               -SecureBootTemplate 'MicrosoftUEFICertificateAuthority'

Avant d’activer la mémoire dynamique partout, il faut tenir compte du profil de charge. Elle convient bien à de nombreuses VM de services généralistes, mais elle demande des tests pour les charges sensibles à la latence ou aux mécanismes de réservation mémoire propres à certains logiciels. La mémoire de démarrage doit également être suffisante pour que le système invité démarre et atteigne un état stable.

Un hôte Hyper-V sous Windows Server en production.
Un hôte Hyper-V sous Windows Server en production.

Pour ajouter un disque de données à une VM existante, créer le VHDX puis l’attacher au contrôleur SCSI. Les VM de génération 2 disposent nativement de contrôleurs SCSI ; ceux-ci permettent l’ajout à chaud de disques dans de nombreux cas.

New-VHD -Path 'D:\Hyper-V\VHDX\APP-PRD-01_DATA01.vhdx' `
        -Dynamic `
        -SizeBytes 500GB

Add-VMHardDiskDrive -VMName 'APP-PRD-01' `
                    -ControllerType SCSI `
                    -ControllerNumber 0 `
                    -ControllerLocation 1 `
                    -Path 'D:\Hyper-V\VHDX\APP-PRD-01_DATA01.vhdx'

La création d’une VM doit idéalement être encapsulée dans un script ou une fonction avec variables, validation des chemins, contrôles de capacité et journalisation. En production, éviter les valeurs implicites héritées de la configuration locale de l’hôte : spécifier les chemins, le vSwitch et les réglages de ressources.

Démarrer, arrêter et modifier les paramètres d’une VM

Les actions d’alimentation les plus fréquentes reposent sur Start-VM, Stop-VM, Suspend-VM, Save-VM et Restart-VM.

Start-VM -Name 'APP-PRD-01'

Stop-VM -Name 'APP-PRD-01'

Stop-VM -Name 'APP-PRD-01' -Force

Restart-VM -Name 'APP-PRD-01'

Sans -Force, Stop-VM demande généralement à l’invité de s’arrêter proprement via les services d’intégration. Avec -Force, Hyper-V peut imposer l’arrêt si l’invité ne répond pas. Cette option doit être réservée aux cas où un arrêt contrôlé est impossible ou trop lent, car elle présente les mêmes risques qu’une coupure électrique pour les applications invitées.

Pour modifier les ressources processeur :

Set-VMProcessor -VMName 'APP-PRD-01' -Count 8

Pour activer ou ajuster la mémoire dynamique :

Set-VMMemory -VMName 'APP-PRD-01' `
             -DynamicMemoryEnabled $true `
             -MinimumBytes 4GB `
             -StartupBytes 8GB `
             -MaximumBytes 32GB

Pour attribuer une adresse MAC statique, utile lorsque des politiques réseau ou des licences dépendent de l’identité réseau de la VM :

Set-VMNetworkAdapter -VMName 'APP-PRD-01' `
                     -StaticMacAddress '00155D123456'

La configuration du démarrage automatique mérite aussi d’être explicitement définie. Un hôte qui redémarre après maintenance ou incident ne doit pas forcément relancer toutes les VM simultanément. Pour aller plus loin, consultez l’équivalent côté VMware avec esxcli.

Set-VM -Name 'APP-PRD-01' `
       -AutomaticStartAction StartIfRunning `
       -AutomaticStartDelay 120 `
       -AutomaticStopAction ShutDown

StartIfRunning est souvent un choix prudent : seules les VM actives avant l’arrêt de l’hôte sont relancées. Le délai évite une tempête de démarrage, particulièrement pénalisante sur les hôtes à forte densité ou les stockages partagés.

Checkpoints : usages, limites et nettoyage

Les checkpoints Hyper-V constituent un mécanisme pratique pour revenir rapidement à un état antérieur, mais ils ne remplacent ni une sauvegarde applicative ni une stratégie de reprise après sinistre. Ils reposent sur des disques différentiels AVHDX. Chaque écriture de la VM peut nécessiter la lecture de plusieurs fichiers de la chaîne, ce qui augmente la complexité et peut dégrader les performances lorsque les checkpoints persistent.

Hyper-V distingue notamment les checkpoints de production et les checkpoints standard. Les checkpoints de production s’appuient sur VSS ou sur les mécanismes équivalents disponibles dans l’invité Linux. Ils sont adaptés à des scénarios d’administration et de protection cohérents. Les checkpoints standard capturent aussi l’état mémoire de la VM et peuvent être utiles en laboratoire, mais ils sont moins adaptés à des charges de production.

Type de checkpoint État capturé Usage recommandé
Production Disque uniquement, cohérence applicative (VSS) Protection avant intervention en environnement de production
Standard Disque + mémoire + état des processus Laboratoire, tests, débogage ponctuel

Vérifier le type configuré :

Get-VM -Name 'APP-PRD-01' |
    Select-Object Name, CheckpointType, CheckpointFileLocation

Configurer des checkpoints de production :

Set-VM -Name 'APP-PRD-01' -CheckpointType Production

Créer un checkpoint nommé :

Checkpoint-VM -Name 'APP-PRD-01' -SnapshotName 'Avant-mise-a-jour-2026-09'

Lister les checkpoints d’une VM :

Get-VMSnapshot -VMName 'APP-PRD-01' |
    Select-Object VMName, Name, CreationTime, SnapshotType

Appliquer un checkpoint exige une validation opérationnelle : vérifier l’impact sur les données, les transactions applicatives, la réplication et les services dépendants.

Restore-VMSnapshot -VMName 'APP-PRD-01' `
                   -Name 'Avant-mise-a-jour-2026-09' `
                   -Confirm:$false

Supprimer un checkpoint lance la fusion des AVHDX dans la chaîne de disques. Selon la volumétrie, l’activité de la VM et les performances du stockage, cette opération peut durer longtemps. Il ne faut pas supprimer manuellement les fichiers AVHDX depuis l’explorateur ou avec Remove-Item.

Remove-VMSnapshot -VMName 'APP-PRD-01' `
                  -Name 'Avant-mise-a-jour-2026-09' `
                  -Confirm:$false

Après la suppression, surveiller l’espace disque et l’état de la VM. La fusion peut se poursuivre en arrière-plan. En cas de chaîne AVHDX complexe ou d’incident de stockage, analyser la situation avant toute action sur les fichiers. Une suppression manuelle peut rendre une VM non démarrable et provoquer une perte de données.

Configurer et exécuter une migration en direct

La migration en direct permet de déplacer une VM en fonctionnement entre deux hôtes Hyper-V compatibles, avec une interruption de service normalement très faible. En environnement de production, elle est généralement opérée au sein d’un cluster de basculement, mais Hyper-V permet aussi des migrations entre hôtes autonomes correctement configurés.

Avant toute migration, vérifier les prérequis : connectivité réseau entre les hôtes, résolution DNS, versions Hyper-V compatibles, droits d’administration, règles pare-feu, compatibilité processeur si nécessaire, capacité CPU et mémoire sur la destination, ainsi que l’accessibilité au stockage selon le type de migration.

PowerShell reste l'outil central d'administration Hyper-V.
PowerShell reste l'outil central d'administration Hyper-V.

Activer la migration en direct sur l’hôte :

Enable-VMMigration

Configurer Kerberos comme méthode d’authentification :

Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos

Pour les migrations initiées depuis une console distante, Kerberos implique généralement une délégation contrainte correctement configurée dans Active Directory. Sans cela, l’erreur du « second saut » est fréquente. CredSSP peut faciliter certains scénarios d’administration interactive, mais expose davantage les identifiants et doit être utilisé avec précaution.

Définir les réseaux autorisés pour la migration :

Add-VMMigrationNetwork -Subnet '10.20.30.0/24'

Configurer la compression comme option de performance est souvent pertinent sur un réseau rapide non saturé. L’option SMB peut être adaptée si l’infrastructure SMB Direct ou RDMA est conçue, validée et exploitée pour cet usage.

Set-VMHost -VirtualMachineMigrationPerformanceOption Compression

Une migration avec stockage partagé déplace principalement l’état d’exécution et la mémoire de la VM. Lorsque le stockage n’est pas partagé, Hyper-V peut réaliser une migration avec transfert des fichiers de stockage, mais la durée et la consommation réseau sont nettement plus importantes.

Exemple de migration vers un hôte cible :

Move-VM -Name 'APP-PRD-01' `
        -DestinationHost 'HVHOST02' `
        -IncludeStorage `
        -DestinationStoragePath 'D:\Hyper-V\VMs\APP-PRD-01'

Lorsque les VHDX sont sur un stockage partagé accessible aux deux hôtes, ne pas utiliser -IncludeStorage sans raison. La migration sera plus rapide et évitera une copie inutile des disques.

Move-VM -Name 'APP-PRD-01' -DestinationHost 'HVHOST02'

Dans un cluster, préférer souvent la commande de cluster pour déplacer un rôle hautement disponible. Elle maintient la cohérence avec les règles de placement et les dépendances du cluster. Pour aller plus loin, consultez le comparatif complet des hyperviseurs.

Move-ClusterVirtualMachineRole -Name 'APP-PRD-01' -Node 'HVHOST02'

Avant une opération planifiée, contrôler la destination et la VM. Une approche simple consiste à comparer la mémoire disponible, l’état de la VM et les paramètres de migration des hôtes.

Get-VMHost -ComputerName 'HVHOST01','HVHOST02' |
    Select-Object ComputerName,
                  VirtualMachineMigrationEnabled,
                  VirtualMachineMigrationAuthenticationType,
                  VirtualMachineMigrationPerformanceOption

Get-VM -ComputerName 'HVHOST01' -Name 'APP-PRD-01' |
    Select-Object Name, State, MemoryAssigned, ProcessorCount

Correspondances rapides avec esxcli et PowerCLI

La comparaison avec VMware doit être nuancée. esxcli est surtout l’outil de gestion bas niveau d’un hôte ESXi : réseau, stockage, services, matériel et certains réglages système. PowerCLI est davantage comparable au module Hyper-V PowerShell, car il automatise les opérations sur les VM et les objets d’infrastructure via les API VMware. Pour approfondir l’automatisation côté vSphere, consultez notre guide sur PowerCLI et l’automatisation vSphere.

Dans Hyper-V, Get-VM correspond conceptuellement à Get-VM en PowerCLI. La différence est que PowerCLI est généralement connecté à vCenter Server pour gérer l’inventaire et les clusters, alors que le module Hyper-V interroge un ou plusieurs hôtes Windows, ou travaille conjointement avec Failover Clustering.

# Hyper-V
Get-VM

# PowerCLI
Get-VM

La création d’une VM se rapproche de New-VM côté PowerCLI, mais les paramètres et les objets manipulés diffèrent fortement.

# Hyper-V
New-VM -Name 'APP-PRD-01' -Generation 2 -MemoryStartupBytes 4GB

# PowerCLI, exemple conceptuel
New-VM -Name 'APP-PRD-01' -VMHost 'ESX01' -Datastore 'DS01'

Les checkpoints Hyper-V ont pour équivalent fonctionnel les snapshots VMware, gérés notamment par New-Snapshot, Get-Snapshot, Set-VM -Snapshot et Remove-Snapshot. Dans les deux plateformes, le principe d’exploitation reste identique : un snapshot ou checkpoint est temporaire, doit être surveillé et ne constitue pas une sauvegarde.

# Hyper-V
Checkpoint-VM -Name 'APP-PRD-01' -SnapshotName 'Avant-patch'
Get-VMSnapshot -VMName 'APP-PRD-01'
Remove-VMSnapshot -VMName 'APP-PRD-01' -Name 'Avant-patch'

# PowerCLI
New-Snapshot -VM 'APP-PRD-01' -Name 'Avant-patch'
Get-Snapshot -VM 'APP-PRD-01'
Get-Snapshot -VM 'APP-PRD-01' -Name 'Avant-patch' | Remove-Snapshot -Confirm:$false

Enfin, Move-VM et Move-ClusterVirtualMachineRole couvrent les besoins de migration en direct Hyper-V. Côté VMware, l’équivalent habituel est Move-VM, qui peut réaliser un vMotion, un Storage vMotion ou les deux selon les paramètres fournis.

# Hyper-V avec stockage partagé
Move-VM -Name 'APP-PRD-01' -DestinationHost 'HVHOST02'

# PowerCLI, exemple conceptuel
Move-VM -VM 'APP-PRD-01' -Destination 'ESX02'

La différence opérationnelle principale est l’architecture de contrôle. VMware centralise généralement les opérations via vCenter Server. Hyper-V s’appuie sur les services de l’hôte, PowerShell Remoting, Active Directory et, pour la haute disponibilité, Windows Server Failover Clustering. Les automatisations Hyper-V gagnent donc à intégrer explicitement les contrôles de connectivité, de droits, de cluster et de stockage.