MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Migration Hyper‑V Windows Server 2019 vers 2022 : méthodes, pas à pas, SID et Hyper‑V Replica

Migration Hyper‑V Windows Server 2019 vers 2022 : méthodes, pas à pas, SID et Hyper‑V Replica

Windows Server

Guide complet pour migrer des machines virtuelles Hyper‑V de Windows Server 2019 vers Windows Server 2022 (hors cluster) : méthodes pas à pas, scripts PowerShell, gestion du SID, réseau, réplication et plan de retour arrière.

Sommaire

Migration de VM Hyper‑V de Windows Server 2019 vers 2022 (hors cluster)

Vue d’ensemble de la question

Vous devez déplacer des VM d’un hôte Hyper‑V Windows Server 2019 Datacenter vers un nouvel hôte Windows Server 2022 Datacenter, sans cluster. Quelles méthodes employer (Live Migration « sans stockage partagé », migration de stockage, export/import, copie) ? L’identité de la VM (SID) change‑t‑elle ? Comment traiter les VM protégées par Hyper‑V Replica ?

Réponse & solutions

Faisabilité & points d’attention

  • Oui, la migration 2019 → 2022 est supportée et courante.
  • Compatibilité CPU/hyperviseur : Live Migration exige des familles CPU compatibles. Le passage Intel ↔ AMD empêche la Live Migration ; préférez un export/import à froid. Entre générations d’un même constructeur, activez la compatibilité processeur sur la VM si besoin.
  • Version de configuration des VM : correctement gérée par 2022. Ne mettez à niveau qu’après validation sur le nouvel hôte.
  • Services d’intégration invités : sur OS récents, ils viennent via Windows Update ou le kernel Linux. Assurez-vous qu’ils sont à jour.
  • Points de contrôle : supprimez/consolidez les checkpoints inutiles pour éviter des chaînes VHDX complexes.
  • Réseau : recréez à l’identique les vSwitch sur l’hôte 2022 (mêmes noms, VLAN, SR‑IOV/SET si utilisés). Les vNIC se reconnecteront automatiquement si les noms correspondent.
  • Stockage : vérifiez les chemins par défaut des VM (config, VHDX, Smart Paging). Anticipez l’espace libre sur 2022.
  • Backups : effectuez une sauvegarde cohérente applicative et planifiez un retour arrière.

Méthodes de déplacement (du plus transparent au plus « offline »)

MéthodeInterruptionConditions clésAvantagesPoints d’attention
Live Migration (sans stockage partagé)Quasi nulleMême domaine (ou approbation), Live Migration activée des deux côtés, réseaux autorisés, CPU compatiblesTransparente, aucun exportConfigurer Kerberos/CredSSP et les réseaux de migration. Débit dépendant des liens réseau.
Migration de stockageTrès faibleVM en marche, destination accessible (local ou SMB), bande passanteDéplace les fichiers VHDX/config « à chaud »Peut être combinée à une Live Migration ensuite.
Export/ImportCourte à modéréeFenêtre de bascule à froid, espace disqueSimple, sûr, reproductibleNécessite un arrêt de la VM pendant la bascule.
Copie manuelle (VHDX + config)VariableSavoir‑faire avancéPossible en dernier recoursDéconseillée : risques d’incohérence/mappage.

Identité/SID de la VM

  • Live/Storage Migration et Export/Import ne changent pas le SID invité ni l’identité de domaine de l’OS invité.
  • Lors d’un Import, l’option Copier peut générer un nouvel ID Hyper‑V (GUID) pour la VM, mais pas un nouveau SID invité.
  • Un nouveau SID invité n’apparaît que si vous clônez et exécutez Sysprep : ce n’est pas requis pour un simple déplacement.

VM sous Hyper‑V Replica

  • Avant de déplacer une VM répliquée : mettre la réplication en pause ou arrêt pour garantir la cohérence.
  • Si le serveur cible est déjà la réplique : faites un basculement planifié puis inversez la réplication (plus rapide et propre).
  • Après le déplacement, réinitialisez la réplication si nécessaire.

Procédure conseillée (check‑list rapide)

  1. Sauvegarder la VM (cohérence applicative) et consolider les checkpoints.
  2. Mettre à jour les hôtes 2019 et 2022, firmware/NIC/BIOS, et les services d’intégration des invités.
  3. Recréer les vSwitch sur l’hôte 2022 (mêmes noms/VLAN/SET/SR‑IOV).
  4. Choisir la méthode : Live/Storage Migration si prérequis, sinon Export/Import (de préférence Enregistrer/Restaurer).
  5. Importer/déplacer la VM, mapper les vNIC sur les bons vSwitch, vérifier le boot (Gen 1/Gen 2, Secure Boot).
  6. Tests post‑migration : IP/latence, performances disque, services applicatifs, sauvegardes, monitoring.
  7. Réplication : relancer l’initialisation ou effectuer l’inversion après basculement planifié.
  8. Optionnel : sur 2022, mettre à niveau la version de configuration après validation (irréversible).

Tutoriel pas à pas détaillé

Préparer les hôtes

  • Join domaine, synchronisation NTP, correctifs Windows à jour.
  • Vérifier la virtualisation assistée (SLAT) et activer Hyper‑V (rôle et outils).
  • Créer les chemins par défaut des VM sur l’hôte 2022 : dossiers séparés pour Configuration, Disques durs, Snapshots.
  • Réseau : reconstruire les vSwitch (type externe/interne/privé) et, si teaming, privilégier Switch Embedded Teaming (SET).

Activer et paramétrer la Live Migration (option recommandé si possible)

GUI : sur chaque hôte, Hyper‑V Manager → Paramètres de l’hôte → Live Migrations : cocher « Activer… », définir le nombre maximum de migrations simultanées, ajouter les réseaux autorisés (subnets/IPS), sélectionner le mode de performance : Compression (par défaut), SMB (idéal si RDMA), ou TCP.

PowerShell :

# Activer la Live Migration sur chaque hôte
Set-VMHost -VirtualMachineMigrationEnabled $true `
           -VirtualMachineMigrationAuthenticationType Kerberos `
           -VirtualMachineMigrationPerformanceOption Compression `
           -VirtualMachineMigrationMaximum 4

# Autoriser les réseaux de migration

Add-VMMigrationNetwork -Subnet "10.10.10.0/24"
Add-VMMigrationNetwork -Subnet "10.20.20.0/24"

# Si RDMA/SMB Direct disponible, privilégier SMB

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB

Authentification : pour des migrations inter‑hôtes via Kerberos, mettez en place une délégation contrainte dans Active Directory (sur les comptes ordinateurs des hôtes Hyper‑V) vers les services « Microsoft Virtual System Migration Service » et éventuellement « cifs » de l’hôte cible. À défaut, pour des environnements non approuvés ou tests, vous pouvez utiliser CredSSP (à activer explicitement et à limiter dans le temps).

# (Optionnel) Activer rapidement CredSSP le temps de la migration
Enable-WSManCredSSP -Role Server
Enable-WSManCredSSP -Role Client -DelegateComputer "HV2022.domain.local"
# ... puis désactiver après usage
Disable-WSManCredSSP -Role Client
Disable-WSManCredSSP -Role Server

Recréer l’environnement réseau à l’identique

  • Créer des vSwitch portant exactement les mêmes noms.
  • Reconfigurer VLAN, QoS, SR‑IOV, NVGRE/VxLAN s’il y a lieu.
  • Préparer les port‑ACL ou règles d’extension si vous en utilisez.

Choisir la méthode de bascule

ContrainteRecommandation
Même domaine, CPU compatibles, bonne bande passanteLive Migration avec ou sans inclusion du stockage.
Domaine différent / aucune délégation possibleExport/Import à froid.
Changement Intel ↔ AMDExport/Import (Live Migration indisponible).
Besoin de pré‑déplacer uniquement les disquesMigration de stockage puis migration de la VM.
VM sous Hyper‑V Replica et cible = serveur de réplicaBasculement planifié + inversion de la réplication.

Scénarios pas à pas

Live Migration « sans stockage partagé »

  1. Vérifiez que les vSwitch existent et portent les mêmes noms sur 2022.
  2. Activez la compatibilité CPU si nécessaire : Set-VMProcessor -VMName "VM01" -CompatibilityForMigrationEnabled $true
  3. Lancez la migration depuis l’hôte 2019 : Move-VM -Name "VM01" -DestinationHost "HV2022"
  4. Si vous devez déplacer les fichiers en même temps : Move-VM -Name "VM01" -DestinationHost "HV2022" ` -IncludeStorage ` -DestinationStoragePath "D:\Hyper-V\VMs\VM01\"
  5. Validez le mapping vNIC : Connect-VMNetworkAdapter -VMName "VM01" -SwitchName "vSwitch-Prod" Set-VMNetworkAdapterVlan -VMName "VM01" -Access -VlanId 120

Conseils performance : « Compression » est efficace sans RDMA. Si vous disposez de cartes RDMA (RoCE/iWARP), le mode « SMB » offre un débit et une latence supérieurs. Augmentez le nombre de migrations simultanées avec parcimonie.

Migration de stockage à chaud

  1. Créez (si besoin) le dossier cible sur l’hôte 2022 et assurez les permissions (comptes ordinateurs des deux hôtes).
  2. Depuis l’hôte 2019 : Move-VMStorage -VMName "VM01" -DestinationStoragePath "\\HV2022\D$\Hyper-V\VMs\VM01\"
  3. Une fois les fichiers sur 2022, enchaînez avec une Live Migration de la VM (sans -IncludeStorage).

Export/Import

  1. Arrêtez proprement la VM et consolidez les checkpoints.
  2. Exportez la VM depuis 2019 : Export-VM -Name "VM01" -Path "E:\Exports\VM01"
  3. Sur 2022, importez selon vos objectifs :
    • Enregistrer/Restaurer : conserve l’ID de VM (GUID) : Import-VM -Path "E:\Exports\VM01\Virtual Machines\{GUID}\VM01.vmcx"
    • Copier : copie les fichiers dans l’emplacement par défaut et peut générer un nouvel ID Hyper‑V (GUID), utile pour éviter un conflit avec l’ancienne VM : Import-VM -Path "E:\Exports\VM01\Virtual Machines\{GUID}\VM01.vmcx" ` -Copy -GenerateNewId
  4. Reconnectez les vNIC aux bons vSwitch et relancez la VM.

Important : l’Importer/Enregistrer réutilise les fichiers exportés « tels quels » ; l’Import/Restaurer les remet à un autre emplacement ; l’Import/Copier crée un nouveau jeu de fichiers et, si vous le souhaitez, un nouvel ID Hyper‑V.

VM sous Hyper‑V Replica : basculement planifié

  1. Assurez que la réplication est santé OK et à jour.
  2. Depuis le primaire (2019), lancez un basculement planifié : Start-VMFailover -VMName "VM01" -Prepare Start-VMFailover -VMName "VM01"
  3. Sur le serveur de réplica (2022), finalisez : Complete-VMFailover -VMName "VM01"
  4. Inversez la réplication (2022 → 2019, ou vers un nouveau réplica) : Set-VMReplication -VMName "VM01" -Reverse

Cette approche évite une réinitialisation complète de la réplication et minimise l’interruption.

Vérifications post‑migration

  • Statut Hyper‑V : Get-VM -Name "VM01" | Format-List State,CPUUsage,MemoryAssigned,Version
  • Réseau : Get-VMNetworkAdapter -VMName "VM01" Test-NetConnection -ComputerName <IP/DNS cible> -Port 3389
  • Disque : Get-VHD -Path "D:\Hyper-V\VMs\VM01\Disk0.vhdx" | Select-Object Path,FileSize,Size,BlockSize,Attached
  • Secure Boot (Gen 2) : Get-VMFirmware -VMName "VM01"
  • Backups : exécutez un job de sauvegarde d’essai et vérifiez le rapport.

Mise à niveau de la version de configuration (facultatif)

Une fois la VM validée sur 2022, vous pouvez mettre à niveau sa configuration version pour bénéficier des fonctionnalités les plus récentes.

# Voir la version actuelle
Get-VM -Name "VM01" | Select-Object Name,Version

# Mettre à niveau (irréversible)

Update-VMVersion -Name "VM01"

Ne mettez pas à niveau si vous prévoyez un retour arrière de l’hôte vers 2019 : la VM ne serait plus rétrocompatible.

Pièges fréquents & bonnes pratiques

  • Noms de vSwitch différents : les vNIC apparaissent « déconnectées » après import ; renommez les vSwitch pour une reconnexion automatique.
  • CPU hétérogènes (Intel ↔ AMD) : pas de Live Migration. Faites un export/import à froid.
  • Secure Boot (Gen 2) : vérifiez le template (Windows : « MicrosoftWindows », Linux : « MicrosoftUEFICertificateAuthority ») : Set-VMFirmware -VMName "VM01" -EnableSecureBoot On -SecureBootTemplate "MicrosoftWindows"
  • Adresses MAC : en import Copier + -GenerateNewId, Hyper‑V peut générer de nouvelles MAC dynamiques ; mettez à jour vos réservations DHCP, ACLs et licences liées au MAC.
  • Agents de sauvegarde : suspendez temporairement pendant la bascule pour éviter des snapshots VSS non désirés.
  • Permissions SMB (storage migration) : autorisez les comptes ordinateurs des hôtes à écrire/ lire la destination. Vérifiez NTFS + partage.
  • Port de Live Migration : autorisez le flux (par défaut TCP 6600) ainsi que SMB 445 si vous utilisez le mode SMB.
  • Sprawl de checkpoints : supprimez les checkpoints gels/anciens avant migration pour accélérer les copies.
  • Énergie/BIOS : désactivez des fonctionnalités d’économie d’énergie agressives sur les NIC (Green Ethernet) pendant les migrations lourdes.

Vers la haute disponibilité plus tard

  • Planifiez un cluster de basculement (WSFC) avec stockage partagé (SAN) ou Storage Spaces Direct (S2D).
  • Standardisez vSwitch, VLAN, noms et politiques réseau pour des Live Migrations fluides.
  • Documentez la nomenclature : dossiers VM, conventions de noms, balises, VLAN, IPAM.

FAQ express

Faut‑il rejoindre de nouveau le domaine à l’intérieur de la VM ?
Non, la VM conserve son appartenance au domaine et son SID invité. Seule l’empreinte Hyper‑V (GUID) peut changer si vous l’ordonnez (Import avec Copier + -GenerateNewId).

Quid des adresses IP ?
Elles sont gérées dans l’OS invité : elles ne changent pas tant que vous remappez la vNIC sur le vSwitch correct et que l’ordre des NIC reste cohérent.

Mes sauvegardes restent‑elles valides ?
La majorité des solutions détectent le nouvel hôte. Réenregistrez la VM si le produit se base sur le GUID Hyper‑V ou le chemin des fichiers.

Puis‑je migrer une VM Linux ?
Oui. Vérifiez les services d’intégration (LIS/Kernel), le Secure Boot (template Linux) et les modules réseau/heure.

Combien de temps dure la migration ?
Dépend du volume de données, de la bande passante et de la méthode (Live vs export). Planifiez une fenêtre en conséquence et testez sur une VM pilote.

Scripts utiles (boîte à outils)

Recréer rapidement des vSwitch cohérents

$switches = @(
    @{ Name = "vSwitch-Prod"; Type = "External"; NetAdapterName = "NIC-Prod-Team"; AllowManagementOS = $true; VlanId = 0 },
    @{ Name = "vSwitch-Backup"; Type = "External"; NetAdapterName = "NIC-Backup"; AllowManagementOS = $false; VlanId = 0 }
)
foreach ($s in $switches) {
    if (-not (Get-VMSwitch -Name $s.Name -ErrorAction SilentlyContinue)) {
        New-VMSwitch -Name $s.Name -NetAdapterName $s.NetAdapterName -AllowManagementOS:$($s.AllowManagementOS)
        if ($s.VlanId -gt 0) {
            Set-VMSwitch -Name $s.Name -DefaultFlowPriority 0
        }
    }
}

Mapper toutes les vNIC d’une VM après import

$vm = "VM01"
$targetSwitch = "vSwitch-Prod"
Get-VMNetworkAdapter -VMName $vm | ForEach-Object {
    Connect-VMNetworkAdapter -VMName $vm -Name $_.Name -SwitchName $targetSwitch
}

Activer la compatibilité CPU avant migration

Get-VM | Where-Object {$_.State -eq "Running"} | `
    ForEach-Object { Set-VMProcessor -VMName $_.Name -CompatibilityForMigrationEnabled $true }

Valider la santé globale des VM migrées

Get-VM | Select-Object Name, State, Version, CPUUsage, MemoryAssigned |
    Sort-Object Name | Format-Table -AutoSize

Plan de retour arrière (back‑out)

  1. Ne détruisez jamais la VM source avant validation complète (fonctionnelle et sauvegardes).
  2. Si la VM migrée présente un problème critique :
    • Arrêtez la VM sur 2022.
    • Rallumez la VM source sur 2019 (si restée intacte) ou restaurez depuis la sauvegarde.
  3. Si vous avez fait un basculement planifié avec Replica :
    • Vous pouvez re‑inverser la réplication pour revenir temporairement sur l’ancien hôte.
  4. Documentez la cause racine (réseau, drivers, sécurité, performances) avant de retenter.

Annexes pratiques

Récapitulatif des commandes clés

ObjectifCommandeRemarques
Activer Live MigrationSet-VMHost -VirtualMachineMigrationEnabled $trueChoisir Kerberos/CredSSP et l’option de performance.
Ajouter un réseau de migrationAdd-VMMigrationNetwork -Subnet "10.10.10.0/24"Répéter par subnet.
Déplacer une VM en ligneMove-VM -Name "VM01" -DestinationHost "HV2022"Sans stockage ou avec -IncludeStorage.
Migration de stockageMove-VMStorage -VMName "VM01" -DestinationStoragePath "..."VM en marche.
ExportExport-VM -Name "VM01" -Path "E:\Exports"À froid recommandé.
ImportImport-VM -Path "...vmcx" [-Copy] [-GenerateNewId]Préserve ou régénère l’ID Hyper‑V.
Compatibilité CPUSet-VMProcessor -VMName "VM01" -CompatibilityForMigrationEnabled $trueAvant Live Migration.
Mise à jour configUpdate-VMVersion -Name "VM01"Après validation, irréversible.
Replica : basculement planifiéStart-VMFailover -VMName "VM01" -PreparePuis Start-VMFailover et Complete-VMFailover.
Replica : inversionSet-VMReplication -VMName "VM01" -ReverseAprès basculement.

Ports et flux réseau à considérer

FonctionPort/ProtocoleCommentaires
Live MigrationTCP 6600Service de migration Hyper‑V.
SMB (fichiers VM)TCP 445Nécessaire si mode « SMB » ou copies via partages.
WinRM/PowerShell RemotingTCP 5985/5986Administration/automation.
DNS, NTP, ADDiversIndispensables à Kerberos et à la résolution.

En bref

  • Oui, la migration 2019 → 2022 est supportée.
  • Privilégiez Live/Storage Migration si possible ; sinon Export/Import.
  • Le SID invité ne change pas lors d’un simple déplacement.
  • Gérez la réplication : pause/arrêt ou basculement planifié, puis reconfiguration/inversion.
  • Suivez la check‑list ci‑dessus pour une bascule propre et reproductible.

Étape par étape : modèle de plan de migration prêt à l’emploi

Utilisez le canevas ci‑dessous pour industrialiser vos migrations.

  1. Inventaire : liste des VM (CPU/RAM/Disques, VLAN, dépendances, sauvegardes, Replica).
  2. Pré‑requêtes hôtes : correctifs, drivers, BIOS, Live Migration, réseaux, quotas d’espace.
  3. Reproduction réseau : vSwitch, VLAN, QoS, SET, routes.
  4. Tests préalables : migration d’une VM pilote peu critique.
  5. Bascule : appliquer la méthode choisie (scripts ci‑dessus), fenêtre de maintenance validée.
  6. Validation : monitoring, logs Hyper‑V (Hyper‑V‑VMMS, Hyper‑V‑Worker), journaux systèmes invités.
  7. Posture sécurité : réduire/désactiver temporaire CredSSP, valider Kerberos SPN/délégation, limiter les accès SMB.
  8. Documentation : rapport de migration, captures, versions, responsables.

Astuce : si vous anticipez des migrations fréquentes, créez un playbook PowerShell (fonctions réutilisables) et des balises d’adaptateurs côté invité pour faciliter le mappage (Device Naming).

Ce guide couvre l’essentiel pour réussir une migration Hyper‑V de Windows Server 2019 vers 2022, hors cluster, avec des chemins clairs selon vos contraintes. En respectant la préparation, le choix de méthode et la validation, vous obtiendrez une bascule prévisible, reproductible et sûre.

Windows Server
Sommaire