La sfida del pilota

Nell'ambiente VMware, Windows carica i driver paravirtualizzati VMware ( vmxnet3 per la rete, pvscsi per l'archiviazione e così via) e li lega a specifici identificatori hardware. Quando si sposta il disco in VPC, l'hardware cambia:

• Rete: VMware vmxnet3 → Scheda di rete Virtual I/O ( VirtIO )
• Archiviazione (avvio): VMware PVSCSI → VirtIO Adattatore SCSI
• Archiviazione (dati): VMware PVSCSI → VirtIO adattatore a blocchi

Se Windows si avvia e trova ID hardware diversi per il controller di archiviazione di avvio, non riesce ad avviarsi (schermata blu INACCESSIBLE_BOOT_DEVICE).

Soluzione A: approccio Sysprep

L'utilità sysprep di Microsoft "generalizza" un'installazione di Windows, riportandola allo stato di primo avvio. Questo:

• Rilascia i binding del driver
• Ripristina l'identificatore di sicurezza (SID) di Windows
• Rimuove le informazioni specifiche del computer
• Prepara l'immagine per la ridistribuzione

Completare la seguente procedura per sysprep:

1. Installare i driver di VirtIO nella macchina virtuale Windows ancora ospitata in VMware:

   1. Scarica l'ISO di virtio-win da un'istanza di server virtuale RHEL (/usr/share/virtio-win).
   2. Montate l'ISO, eseguite virtio-win-gt-x64.exe e virtio-win-guest-tools.exe.
   3. Installare i driver sia per il sistema operativo che per la partizione di ripristino.

2. Eseguire sysprep:

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

3. Esportare e migrare utilizzando uno qualsiasi dei metodi di migrazione, ad eccezione di VDDK Direct Extraction, che è solo per vCenter.

4. Primo avvio in VPC:

   • Windows esegue la mini-impostazione guidata (OOBE)
   • Rileva il nuovo hardware, carica i driver VirtIO
   • Potrebbe essere necessario reinserire il codice prodotto
   • Potrebbe essere necessario ricongiungere il dominio

Vantaggi:

• Processo Microsoft ben documentato
• Funziona in modo affidabile per le implementazioni Windows

Svantaggi:

• Ripristina l'identità della macchina (problematico per i server uniti al dominio)
• Potrebbe innescare la riattivazione di Windows
• Problemi specifici dell'applicazione (alcune applicazioni non gestiscono bene il sysprep)
• Richiede il completamento dell'OOBE al primo avvio

Decisione di progettazione: Usare sysprep per le distribuzioni basate su modelli o quando si migra su macchine virtuali di sviluppo o di prova in cui il ripristino dell'identità è accettabile. Da evitare per i server di produzione uniti al dominio con dipendenze complesse delle applicazioni.

Soluzione B: Iniezione del driver “ virt-v2v ”

Lo strumento libguestfs virt-v2v può iniettare i driver VirtIO in un'installazione di Windows senza eseguire sysprep. Di seguito sono riportate le caratteristiche principali:

• Monta il file system di Windows (senza avviare Windows)
• Inietta i driver di VirtIO nell'archivio dei driver
• Modifica il registro di sistema per forzare Windows a caricare questi driver
• Conserva l'identità della macchina, l'appartenenza al dominio e lo stato dell'applicazione

Prerequisiti

• La macchina virtuale deve essere spenta in modo pulito (non si è bloccata, non è stata forzata)
• La versione di Windows deve essere supportata (Server 2008 R2 fino a 2025, Windows 7 fino a 11)
• Pacchetto driver Virtio-win (disponibile sui sistemi RHEL: /usr/share/virtio-win)

Di seguito viene descritta la procedura per l'iniezione di driver in virt-v2v:

1. Installare i driver VirtIO nelle partizioni di avvio e di ripristino di Windows (stesso approccio di sysprep)

2. Arresto pulito della macchina virtuale Windows

3. Esportare/trasferire il disco su un'istanza di server virtuale di lavoro utilizzando uno qualsiasi dei metodi di migrazione.

4. Correre virt-v2v:

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

   Parametri:

   • -i disk: L'input è un file immagine del disco
   • -o disk -os /target: Uscita nella directory
   • --block-driver virtio-scsi: Usa il driver SCSI per il primo disco (necessario per i volumi di avvio VPC)

5. Se si scrive direttamente sul dispositivo:

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

Vantaggi di virt-v2v:

• Preserva l'identità della macchina (nessuna riattivazione, nessun redomain-join)
• Nessuna configurazione guidata al primo avvio
• Stato dell'applicazione intatto
• Funziona per i server di produzione

Svantaggi:

• Richiede una configurazione ibrida RHEL/ Ubuntu
• Più complesso di sysprep
• Richiede uno spegnimento pulito (non elabora macchine virtuali in crash o forzate)

Decisione di progettazione: Utilizzare virt-v2v per i server Windows di produzione in cui la conservazione dell'identità è fondamentale. Accettare la complessità degli strumenti aggiuntivi come compromesso per migrazioni più pulite.

# 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

Architettura dei driver di archiviazione di Windows in VPC

La comprensione del modo in cui VPC presenta lo storage a Windows aiuta a risolvere i problemi di avvio:

Primo volume (disco di avvio):

• Presentato come dispositivo SCSI VirtIO
• Richiede un driver virtio-scsi
• Ecco perché --block-driver virtio-scsi è obbligatorio

Volumi successivi (dischi dati):

• Presentati come dispositivi a blocchi VirtIO
• Richiede un driver virtio-blk
• Driver diverso dal disco di avvio

Entrambi i driver devono essere installati in entrambi:

• Il sistema operativo in esecuzione
• L'ambiente di recupero ( WinRE )

Installazione dei driver nell'ambiente di ripristino

L'ambiente di ripristino di Windows ( WinRE ) è un mini-ambiente Windows indipendente utilizzato per le operazioni di ripristino. Se non dispone dei driver per l'I/O virtuale ( VirtIO ), non è possibile utilizzarlo per il ripristino dopo la migrazione.

Individuazione WinRE:

reagentc /info

Potrebbe essere segnalato un volume di ripristino, ma l'immagine reale di WinRE potrebbe essere a livello:

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

Installazione dei driver in WinRE:

1. Montare la ISO di virtio-win

2. Identificare la posizione di WinRE attraverso reagentc /info

3. Se su un volume separato, montarlo temporaneamente

4. Utilizzare DISM per iniettare i driver:

   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
   

Considerazioni sulla partizione GPT:

Se il disco di Windows utilizza GPT (non MBR):

• Utilizzare list volume e select volume al posto di list partition
• L'impostazione degli ID volume è diversa:
  • Volume dei dati: set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
  • Volume del sistema: set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Versioni di Windows supportate

Red Hat il pacchetto virtio-win fornisce i driver per:

Windows Server:

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

Client Windows:

• 7
• 8, 8.1
• 10
• 11

Le versioni precedenti (Server 2003, 2008 non-R2, Vista) non sono supportate.

La seguente tabella è la matrice delle decisioni di progettazione per Windows