Aller au contenu

Migrer depuis Hyper-V

Day 1 · DéployerNiveau 2 · OpérerProcédureRédigé · à valider en lab

Objectif. Migrer une VM Hyper-V vers Proxmox VE en recréant la VM (VMID 101) puis en important son disque VHDX avec qm disk import, qui convertit tout format lu par qemu-img (VHDX, et VHD sous le nom de format vpc).

Principe. Il n'existe pas d'assistant d'import Hyper-V. La méthode : préparer l'invité, éteindre la VM, copier le VHDX sur un nœud PVE, créer une VM équivalente, importer le disque, démarrer.

Correspondance des réglages

Hyper-V Proxmox VE
Génération 1 (BIOS) --bios seabios, machine pc (i440fx) ou q35
Génération 2 (UEFI) --bios ovmf, machine q35, disque EFI efidisk0
Secure Boot activé efidisk0 avec pre-enrolled-keys=1
vTPM tpmstate0 (version=v2.0) : état non transférable, BitLocker à suspendre
Contrôleur SCSI synthétique VirtIO SCSI single
Carte réseau synthétique VirtIO (paravirtualized)
Integration Services QEMU Guest Agent + pilotes VirtIO
Point de contrôle (.avhdx) À fusionner avant l'export

Avant de toucher la prod

  • Génération, Secure Boot, vTPM, vCPU, RAM, VLAN et MAC relevés : Get-VM srv-app01 | Format-List Name, Generation, ProcessorCount, MemoryStartup et Get-VMNetworkAdapter srv-app01.
  • Aucun point de contrôle : Get-VMSnapshot srv-app01 ne renvoie rien (sinon les supprimer et attendre la fusion des .avhdx).
  • Windows : pilotes VirtIO et QEMU Guest Agent installés dans la VM Hyper-V (procédure), IP fixe notée.
  • Linux : modules VirtIO dans l'initramfs (lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio sur Debian), /etc/fstab en UUID.
  • BitLocker suspendu ou clé de récupération disponible.
  • Espace de transit sur le nœud PVE supérieur à la taille du VHDX, et espace cible suffisant (pvesm status).

Étapes

1. Exporter le disque côté Hyper-V

Stop-VM -Name srv-app01
Get-VMHardDiskDrive -VMName srv-app01 | Select Path
# copier le fichier .vhdx (VM arrêtée) vers le nœud PVE, par exemple avec scp
scp D:\Hyper-V\srv-app01\srv-app01.vhdx root@pve01:/var/lib/vz/import/

2. Créer la VM et importer le disque

  1. Create VM : VMID 101, nom srv-app01.
  2. OS : Do not use any media, type d'OS correspondant (Windows 2022, Linux 6.x…).
  3. System : Machine q35 ; génération 2 → BIOS OVMF (UEFI), cocher Add EFI Disk sur ceph-vm et Pre-Enroll keys si Secure Boot ; SCSI Controller VirtIO SCSI single ; cocher Qemu Agent.
  4. Disks : supprimer le disque proposé (icône corbeille).
  5. CPU, Memory : reprendre les valeurs relevées. Network : vmbr0, VLAN, modèle VirtIO, MAC d'origine si une réservation ou une licence en dépend.
  6. Ne pas démarrer. Poursuivre dans le shell du nœud (onglet CLI) pour l'import du VHDX, puis revenir dans Hardware : double-cliquer sur Unused Disk 0 → bus SCSI 0 (ou SATA 0 si Windows n'a pas les pilotes), cocher Discard → Add. Options → Boot Order : activer ce disque en premier.
qemu-img info /var/lib/vz/import/srv-app01.vhdx      # file format: vhdx
# VM génération 2 (UEFI + Secure Boot)
qm create 101 --name srv-app01 --machine q35 --bios ovmf \
  --efidisk0 ceph-vm:1,efitype=4m,pre-enrolled-keys=1 \
  --cores 4 --memory 8192 --cpu x86-64-v2-AES --ostype win11 \
  --scsihw virtio-scsi-single --net0 virtio,bridge=vmbr0,tag=20 --agent enabled=1
qm disk import 101 /var/lib/vz/import/srv-app01.vhdx ceph-vm
qm set 101 --scsi0 ceph-vm:vm-101-disk-1,discard=on,iothread=1 --boot order=scsi0

Vérifiez le nom exact du volume importé avec qm config 101 (unused0: …) : le disque EFI occupe souvent vm-101-disk-0. Génération 1 : remplacez --bios ovmf --efidisk0 … par --bios seabios.

3. Premier démarrage

  1. qm start 101, console noVNC ouverte.
  2. Windows : ressaisir l'IP sur la carte VirtIO, vérifier le Gestionnaire de périphériques, désinstaller les composants Hyper-V restants si un éditeur en avait installé.
  3. Linux génération 2 qui ne démarre pas : dans le menu OVMF (touche Échap au démarrage), Boot Maintenance Manager → Boot From File → choisir le chargeur .efi de la distribution, puis recréer l'entrée de démarrage depuis l'invité.
  4. Disque démarré en SATA : appliquer la méthode du disque témoin pour passer en VirtIO SCSI.
  5. Lancer la recette post-migration, puis supprimer le VHDX de la zone de transit.

Vérifications

qm config 101 | grep -E 'bios|efidisk0|scsi0|boot|net0|agent'
qm guest cmd 101 get-osinfo
Sortie attendue : bios: ovmf et efidisk0 (génération 2), scsi0 sur ceph-vm, boot: order=scsi0, agent: enabled=1, et un JSON décrivant l'OS invité. La taille de scsi0 correspond à la virtual size de qemu-img info.

Rollback

La VM Hyper-V est intacte. qm stop 101, puis Start-VM -Name srv-app01 côté Hyper-V. Nettoyage côté Proxmox : qm destroy 101 --purge.

Pièges vus en support

  • Copie du .vhdx parent alors qu'un point de contrôle existe : le disque importé ne contient pas les dernières données (elles sont dans le .avhdx).
  • VM génération 2 créée en SeaBIOS : « No bootable device ».
  • Secure Boot actif côté Hyper-V et Pre-Enroll keys non coché : Windows peut refuser de démarrer selon sa configuration ; inversement, certains chargeurs Linux anciens refusent les clés préenregistrées.
  • Disque VHDX dynamique copié pendant que la VM tourne : image incohérente. Toujours arrêter la VM.
  • Licence Windows liée au matériel : réactivation demandée après migration.

Quand ouvrir un ticket iTop

VM critique qui ne démarre pas après import et rollback impossible : P2. Format refusé par qemu-img, problème de démarrage UEFI persistant : P3. Planification d'une migration Hyper-V complète : P4. Joignez qemu-img info du VHDX, qm config 101, la génération Hyper-V et l'OS invité.

Ouvrir un ticket iTop

Pour aller plus loin : Import OVF/OVA, VMDK · qm(1) · Formats qemu-img · Migrate to Proxmox VE