Die Herausforderung für den Fahrer

In Ihrer VMware Umgebung lädt Windows VMware paravirtualisierte Treiber ( vmxnet3 für Netzwerk, pvscsi für Speicher usw.) und bindet sie an bestimmte Hardware-Identifikatoren. Wenn Sie die Festplatte nach VPC verschieben, ändert sich die Hardware:

• Netzwerk: VMware vmxnet3 → Virtueller I/O-Netzwerkadapter ( VirtIO )
• Speicher (Boot): VMware PVSCSI → VirtIO SCSI-Adapter
• Speicherung (Daten): VMware PVSCSI → VirtIO block adapter

Wenn Windows bootet und unterschiedliche Hardware-IDs für seinen Boot-Speicher-Controller findet, kann es nicht starten (blauer Bildschirm INACCESSIBLE_BOOT_DEVICE).

Lösung A: Sysprep-Ansatz

Das Microsoft-Dienstprogramm sysprep "verallgemeinert" eine Windows-Installation und setzt sie auf den Zustand des ersten Starts zurück. Dies:

• Gibt Treiberbindungen frei
• Setzt den Windows Security Identifier (SID) zurück
• Entfernt computerspezifische Informationen
• Bereitet das Abbild für die erneute Bereitstellung vor

Führen Sie den folgenden Prozess für sysprep durch:

1. Installieren Sie die Treiber von VirtIO in Ihrer virtuellen Windows-Maschine, während diese noch in VMware gehostet wird:

   1. Laden Sie die virtio-win-ISO-Datei von einer virtuellen RHEL-Serverinstanz herunter (/usr/share/virtio-win).
   2. ISO einbinden, virtio-win-gt-x64.exe und virtio-win-guest-tools.exe ausführen.
   3. Installieren Sie Treiber sowohl für das Betriebssystem als auch für die Wiederherstellungspartition.

2. Führen Sie sysprep aus:

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

3. Exportieren und migrieren Sie mit einer der Migrationsmethoden, mit Ausnahme der VDDK-Direktextraktion, die nur für vCenter gilt.

4. Erster Start in VPC:

   • Windows führt einen Mini-Setup-Assistenten aus (OOBE)
   • Erkennt neue Hardware, lädt VirtIO Treiber
   • Möglicherweise muss der Produktschlüssel erneut eingegeben werden
   • Möglicherweise ist ein erneuter Beitritt zur Domäne erforderlich

Vorteile:

• Gut dokumentierter Microsoft-Prozess
• Funktioniert zuverlässig bei Windows-Bereitstellungen

Nachteile:

• Setzt die Rechneridentität zurück (problematisch bei Servern, die einer Domäne angeschlossen sind)
• Könnte die Reaktivierung von Windows auslösen
• Anwendungsspezifische Probleme (einige Anwendungen kommen mit Sysprep nicht gut zurecht)
• Erfordert den Abschluss der OOBE beim ersten Start

Entwurfsentscheidung: Verwenden Sie sysprep für vorlagenbasierte Bereitstellungen oder wenn Sie auf virtuelle Entwicklungs- oder Testmaschinen migrieren, bei denen ein Zurücksetzen der Identität akzeptabel ist. Vermeiden Sie dies für produktive, domänenverbundene Server mit komplexen Anwendungsabhängigkeiten.

Lösung B: Einbindung des „ virt-v2v “-Treibers

Das Tool libguestfs virt-v2v kann VirtIO Treiber in eine Windows-Installation einfügen, ohne sysprep auszuführen. Es:

• Mounten des Windows-Dateisystems (ohne Windows zu booten)
• Injiziert VirtIO Treiber in den Treiberspeicher
• Ändert die Registrierung, um Windows zu zwingen, diese Treiber zu laden
• Beibehaltung der Rechneridentität, der Domänenmitgliedschaft und des Anwendungsstatus

Voraussetzungen:

• Die virtuelle Maschine muss sauber heruntergefahren werden (kein Absturz, keine Zwangsabschaltung)
• Windows-Version muss unterstützt werden (Server 2008 R2 bis 2025, Windows 7 bis 11)
• Virtio-win-Treiberpaket (verfügbar auf RHEL-Systemen: /usr/share/virtio-win)

Im Folgenden wird das Verfahren für die virt-v2v Treiberinjektion beschrieben:

1. Installieren Sie VirtIO Treiber in Windows-Boot- und Wiederherstellungspartitionen (wie bei sysprep)

2. Sauberes Herunterfahren der virtuellen Windows-Maschine

3. Exportieren/übertragen Sie die Festplatte mithilfe einer der Migrationsmethoden auf eine virtuelle Worker-Server-Instanz.

4. Ausführen virt-v2v:

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

   Parameter:

   • -i disk: Die Eingabe ist eine Disk-Image-Datei
   • -o disk -os /target: Ausgabe im Verzeichnis
   • --block-driver virtio-scsi: SCSI-Treiber für die erste Festplatte verwenden (erforderlich für VPC-Boot-Volumes)

5. Wenn Sie direkt auf das Gerät schreiben:

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

Vorteile von virt-v2v:

• Bewahrt die Identität der Maschine (keine Reaktivierung, kein Redomain-Join)
• Kein Assistent für die Ersteinrichtung
• Anwendungsstatus intakt
• Funktioniert für Produktionsserver

Nachteile:

• Erfordert RHEL/ Ubuntu Hybrid-Setup
• Komplexer als sysprep
• Erfordert sauberes Herunterfahren (keine abgestürzten/abgeschalteten virtuellen Maschinen verarbeiten)

Entwurfsentscheidung: Verwenden Sie virt-v2v für produktive Windows-Server, bei denen die Wahrung der Identität entscheidend ist. Akzeptieren Sie die zusätzliche Komplexität der Tools als Kompromiss für sauberere Migrationen.

# 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

Architektur des Windows-Speichertreibers in einer VPC

Wenn Sie verstehen, wie VPC Speicher für Windows bereitstellt, können Sie Probleme beim Booten beheben:

Erstes Volume (Boot-Diskette):

• Präsentiert als VirtIO SCSI-Gerät
• Erfordert einen virtio-scsi-Treiber
• Aus diesem Grund ist --block-driver virtio-scsi obligatorisch

Nachfolgende Volumes (Datendisketten):

• Präsentiert als VirtIO Blockgeräte
• Erfordert einen virtio-blk-Treiber
• Anderer Treiber als Boot-Diskette

Beide Treiber müssen in beiden installiert sein:

• Das laufende Betriebssystem
• Die Wiederherstellungsumgebung ( WinRE )

Treiberinstallation in der Wiederherstellungsumgebung

Die Windows-Wiederherstellungsumgebung ( WinRE ) ist eine eigenständige Mini-Windows-Umgebung, die für Wiederherstellungsvorgänge verwendet wird. Wenn keine Treiber für Virtual I/O ( VirtIO ) vorhanden sind, können Sie das System nicht zur Wiederherstellung nach der Migration verwenden.

Suche nach WinRE:

reagentc /info

Dies könnte ein Wiederherstellungsvolume melden, aber das tatsächliche WinRE-Image könnte sich auf:

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

Installation von Treibern in WinRE:

1. Virtio-Win-ISO einbinden

2. Identifizieren Sie den Standort WinRE durch reagentc /info

3. Falls auf einem separaten Volume, mounten Sie es vorübergehend

4. Verwenden Sie DISM, um Treiber zu injizieren:

   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
   

Überlegungen zur GPT-Partition:

Wenn Ihr Windows-Laufwerk GPT (nicht MBR) verwendet:

• Verwenden Sie list volume und select volume anstelle von list partition
• Die Einstellung der Volume-IDs ist unterschiedlich:
  • Datenvolumen: set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
  • System-Lautstärke: set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Unterstützte Windows-Versionen

Red Hat das virtio-win-Paket bietet Treiber für:

Windows Server:

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

Windows-Client:

• 7
• 8. 8.1
• 10
• 11

Ältere Versionen (Server 2003, 2008 non-R2, Vista) werden nicht unterstützt.

Die folgende Tabelle ist die Entscheidungsmatrix für Windows