Le défi du conducteur

Dans votre environnement VMware, Windows charge VMware des pilotes paravirtualisés ( vmxnet3 pour le réseau, pvscsi pour le stockage, etc.) et les associe à des identifiants matériels spécifiques. Lorsque vous déplacez le disque vers le VPC, le matériel change :

• Réseau : VMware vmxnet3 → Carte réseau à E/S virtuelles ( VirtIO )
• Stockage (boot): VMware PVSCSI → VirtIO Adaptateur SCSI
• Stockage (données): VMware PVSCSI → VirtIO adaptateur de bloc

Si Windows démarre et trouve des ID matériels différents pour son contrôleur de stockage de démarrage, il ne démarre pas (écran bleu INACCESSIBLE_BOOT_DEVICE).

Solution A : approche Sysprep

L'utilitaire sysprep de Microsoft "généralise" une installation Windows, en la ramenant à l'état de premier démarrage. Ceci :

• Libère les liaisons avec les pilotes
• Réinitialise l'identifiant de sécurité (SID) de Windows
• Supprime les informations spécifiques à l'ordinateur
• Préparer l'image pour le redéploiement

Complétez le processus suivant pour sysprep:

1. Installez les pilotes VirtIO dans votre machine virtuelle Windows alors qu'elle est encore hébergée sur VMware:

   1. Téléchargez l'image ISO « virtio-win » à partir d'une instance de serveur virtuel RHEL (/usr/share/virtio-win).
   2. Montez l'ISO, exécutez virtio-win-gt-x64.exe et virtio-win-guest-tools.exe.
   3. Installez les pilotes pour le système d'exploitation et la partition de récupération.

2. Exécutez sysprep :

   C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown
   

3. Exporter et migrer en utilisant n'importe quelle méthode de migration, à l'exception de l'extraction directe de VDDK, qui n'est possible que pour vCenter.

4. Premier démarrage dans le VPC :

   • Windows exécute un mini-assistant d'installation (OOBE)
   • Détecte le nouveau matériel, charge les pilotes VirtIO
   • Il peut être nécessaire de réintroduire la clé de produit
   • Il pourrait être nécessaire de réintégrer le domaine

Avantages :

• Processus Microsoft bien documenté
• Fonctionne de manière fiable pour les déploiements Windows

Inconvénients :

• Réinitialise l'identité de la machine (problématique pour les serveurs reliés à un domaine)
• Peut déclencher la réactivation de Windows
• Problèmes spécifiques à l'application (certaines applications ne gèrent pas bien sysprep)
• Nécessite l'achèvement de l'OOBE au premier démarrage

Décision de conception : Utilisez sysprep pour les déploiements basés sur des modèles ou lorsque vous migrez vers des machines virtuelles de développement ou de test où la réinitialisation de l'identité est acceptable. À éviter pour les serveurs de production reliés à un domaine avec des dépendances d'applications complexes.

Solution B : Injection du pilote « virt-v2v »

L'outil libguestfs virt-v2v permet d'injecter des pilotes VirtIO dans une installation Windows sans exécuter sysprep. Pour les raisons suivantes :

• Monte le système de fichiers Windows (sans démarrer Windows)
• Injecte les pilotes VirtIO dans le magasin de pilotes
• Modifie le registre pour forcer Windows à charger ces pilotes
• Préserve l'identité de la machine, l'appartenance au domaine et l'état de l'application

Prérequis :

• La machine virtuelle doit être arrêtée proprement (pas de panne, pas d'arrêt forcé)
• La version de Windows doit être prise en charge (Server 2008 R2 à 2025, Windows 7 à 11)
• Paquet de pilotes Virtio-win (disponible sur les systèmes RHEL : /usr/share/virtio-win)

Voici la procédure à suivre pour virt-v2v driver injection :

1. Installer les pilotes VirtIO dans les partitions de démarrage et de récupération de Windows (même approche que sysprep)

2. Arrêter proprement une machine virtuelle Windows

3. Exportez/transférez le disque vers une instance de serveur virtuel de travail à l'aide de l'une des méthodes de migration.

4. Exécuter virt-v2v:

   virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi
   

   Paramètres :

   • -i disk: L'entrée est un fichier image de disque
   • -o disk -os /target: Sortie dans le répertoire
   • --block-driver virtio-scsi: Utiliser le pilote SCSI pour le premier disque (nécessaire pour les volumes d'amorçage VPC)

5. Si vous écrivez directement sur l'appareil :

   ln -fs /dev/vdb /target/windows-vm-sda
   virt-v2v -i disk windows-vm.img -o disk -os /target --block-driver virtio-scsi
   

Avantages de la virt-v2v:

• Préserve l'identité de la machine (pas de réactivation, pas de redomain-join)
• Pas d'assistant de configuration au premier démarrage
• État de l'application intact
• Fonctionne pour les serveurs de production

Inconvénients :

• Nécessite une configuration hybride RHEL/ Ubuntu
• Plus complexe que sysprep
• Nécessité d'un arrêt complet (ne pas traiter les machines virtuelles bloquées/forcées)

Décision de conception : Utiliser virt-v2v pour les serveurs Windows de production où la préservation de l'identité est essentielle. Acceptez la complexité supplémentaire des outils comme un compromis pour des migrations plus propres.

# On Ubuntu worker virtual server instance
apt-get install libguestfs-tools
# Copy virtio-win from a RHEL system
# On RHEL: tar czf virtio-win.tar.gz /usr/share/virtio-win
# Transfer to Ubuntu and extract:
tar xzf virtio-win.tar.gz -C /usr/share/
# Now virt-v2v on Ubuntu has both SCSI support and drivers
virt-v2v -i disk windows.img -o disk -os /target --block-driver virtio-scsi

# On RHEL worker (has drivers, no SCSI support)
virt-v2v -i disk windows.img -o disk -os /tmp
# Transfer to Ubuntu worker
scp /tmp/windows-sda ubuntu-worker:/tmp/
# On Ubuntu worker (has SCSI support)
virt-v2v -i disk /tmp/windows-sda -o disk -os /target --block-driver virtio-scsi

Architecture des pilotes de stockage Windows dans un VPC

Comprendre comment VPC présente le stockage à Windows permet de résoudre les problèmes de démarrage :

Premier volume (disque de démarrage):

• Présenté comme VirtIO Périphérique SCSI
• Nécessite un pilote virtio-scsi
• C'est pourquoi --block-driver virtio-scsi est obligatoire

Volumes suivants (disques de données):

• Présentés sous la forme de VirtIO
• Nécessite un pilote virtio-blk
• Pilote différent du disque de démarrage

Les deux pilotes doivent être installés dans les deux :

• Le système d'exploitation en cours d'exécution
• L'environnement de récupération ( WinRE )

Installation des pilotes dans l'environnement de récupération

L'environnement de récupération Windows ( WinRE ) est un mini-environnement Windows distinct utilisé pour les opérations de récupération. S'il ne dispose pas de pilotes d'E/S virtuelles ( VirtIO ), vous ne pourrez pas l'utiliser pour la restauration après la migration.

Localisation WinRE:

reagentc /info

Il peut s'agir d'un volume de récupération, mais l'image WinRE peut se trouver à l'extérieur :

C:\Windows\System32\Recovery\winre.wim

Installation des pilotes dans WinRE:

1. Monter l'ISO virtio-win

2. Identifier l'emplacement de WinRE grâce à reagentc /info

3. S'il se trouve sur un volume séparé, montez-le temporairement

4. Utiliser DISM pour injecter des pilotes :

   dism /mount-wim /wimfile:C:\Windows\System32\Recovery\winre.wim /index:1 /mountdir:C:\mount
   dism /image:C:\mount /add-driver /driver:E:\viostor\w10\amd64 /recurse
   dism /image:C:\mount /add-driver /driver:E:\netkvm\w10\amd64 /recurse
   dism /unmount-wim /mountdir:C:\mount /commit
   

Considérations relatives à la partition GPT :

Si votre disque Windows utilise GPT (et non MBR):

• Utilisez list volume et select volume au lieu de list partition
• La définition des ID de volume diffère :
  • Volume de données : set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
  • Volume du système : set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Versions de Windows prises en charge

Red Hat le paquetage virtio-win de la société Virtio-win fournit des pilotes pour :

Serveur Windows :

• 2008 R2
• 2012, 2012 R2
• 2016, 2019, 2022, 2025

Client Windows :

• 7
• 8, 8.1
• 10
• 11

Les anciennes versions (Server 2003, 2008 non-R2, Vista) ne sont pas prises en charge.

Le tableau suivant est la matrice de décision de conception pour Windows