Ripristino VM Windows Server 2019 in Red Hat OpenStack con rescue image

Hai cancellato per errore winload.exe su una VM Windows Server 2019 in Red Hat OpenStack Platform 17.1? In questo articolo trovi una procedura completa, affidabile e ripetibile, basata su “rescue image”, per ripristinare il boot senza montare ISO né staccare il disco di root.

Indice

Contesto, vincoli e obiettivo

In ambienti Red Hat OpenStack Platform (RHOSP) 17.1 può non essere possibile montare immagini ISO direttamente o scollegare il disco di root di una VM. Le immagini circolano tipicamente nei formati raw e qcow2, e il flusso di lavoro standard prevede l’uso della funzionalità rescue di OpenStack per effettuare interventi di manutenzione “a caldo”.

Il caso studio: su una VM Windows Server 2019 è stato eliminato il file critico C:\Windows\System32\winload.exe. Questo blocca la catena di avvio (Windows Boot Manager → winload.exe) e porta la VM in stato di errore all’avvio. L’obiettivo è ripristinare il boot dal disco originale senza downtime prolungato e senza operazioni invasive sull’infrastruttura.

Architettura della soluzione con rescue image

La modalità rescue in OpenStack avvia la VM con un’immagine di soccorso e collega il disco di sistema originale come volume secondario. Operativamente, una rescue image Windows (WinRE/WinPE o una mini-immagine Windows) diventa C:, mentre il disco di sistema guasto viene esposto come D: (le lettere possono variare, ma l’ipotesi più comune è questa). Da qui si agisce offline sul volume della VM per rimettere in sesto file, BCD e settore di boot.

Prerequisiti consigliati

Snapshot del volume root della VM (prima di qualsiasi prova o remediation), così da poter ripristinare rapidamente lo stato precedente.
Una rescue image Windows Server 2019 o WinRE/WinPE compatibile, registrata in Glance e pronta per l’uso.
Accesso al CLI di OpenStack con permessi adeguati sul progetto/tenant.
Se il volume è BitLocker, avere a disposizione la chiave di recupero (48 cifre).
Coerenza di build: la stessa build di Windows Server 2019 per garantire compatibilità del file winload.exe.

Procedura dettagliata

Avvio della VM in modalità di soccorso

Lancia la rescue dalla tua control plane:

openstack server rescue --image &lt;RESCUEIMAGEID&gt; &lt;SERVERIDOR_NAME&gt;
openstack server show &lt;SERVERIDOR_NAME&gt; -c status -f value

Attendi che lo stato passi a RESCUE. Collega la console (VNC/seriale/ RDP se previsto dalla rescue image) e accedi alla sessione della rescue image Windows.

Mappatura delle unità e accesso al disco della VM

All’interno della rescue image apri Prompt dei comandi o PowerShell. Verifica le lettere di unità e assegna eventuali lettere mancanti:

diskpart
list volume
select volume &lt;N&gt;         # volume del disco originale della VM
assign letter=D
exit

In molti scenari la rescue image è C: e il disco originale viene mappato su D:. Verifica che D:\Windows\System32 sia presente.

Ripristino del file critico `winload.exe`

Se il file è presente nella rescue image, copialo nella VM:

copy C:\Windows\System32\winload.exe D:\Windows\System32\winload.exe

Nota: usa un winload.exe coerente con la build della VM (Windows Server 2019 stessa versione/patch level). In alternativa, puoi usare sfc in modalità offline per ricostruire il file a partire dallo store componenti della VM:

sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows

Ricostruzione/validazione del BCD (Boot Configuration Data)

Il percorso del BCD varia in base al firmware:

BIOS/MBR: D:\Boot\BCD
UEFI/GPT: S:\EFI\Microsoft\Boot\BCD (dove S: è la ESP FAT32 della VM)

Per UEFI, assegna la lettera all’ESP prima di operare:

diskpart
list disk
select disk &lt;N&gt;
list partition
select partition &lt;M&gt;      # EFI System Partition, tipicamente 100–260 MB, FAT32
assign letter=S
exit

Esamina e ricostruisci il BCD:

# Visualizza il contenuto (BIOS):
bcdedit /store D:\Boot\BCD /enum all

Visualizza il contenuto (UEFI):

bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all

Ricostruzione automatica:

bootrec /rebuildbcd

Controlla che il percorso del loader punti a \Windows\System32\winload.exe sull’unità corretta. Se necessario, usa bcdboot per ricreare i file di avvio in modo pulito:

# UEFI (ESP montata come S:)
bcdboot D:\Windows /s S: /f UEFI

BIOS/MBR (senza ESP dedicata):

bcdboot D:\Windows /f BIOS

Se “bootrec /fixboot Access is denied”: è comune in UEFI quando l’ESP non è montata. Assegna la lettera all’ESP, quindi esegui bcdboot come sopra. In casi ostinati:

attrib -s -h -r S:\EFI\Microsoft\Boot\BCD
ren S:\EFI\Microsoft\Boot\BCD BCD.bak
bcdboot D:\Windows /s S: /f UEFI

Riparazione MBR e settore di avvio

Per completare l’operazione sul boot code:

bootrec /fixmbr
bootrec /fixboot

In alternativa (se disponibile nella rescue), puoi usare bootsect:

# Aggiorna il codice di boot su tutte le partizioni compatibili
bootsect /nt60 ALL /force

Controllo integrità del file system

Esegui un controllo del file system sul volume della VM:

chkdsk D: /f

Opzionale: /r per scandire e tentare il ripristino di settori danneggiati (più lento).

Gestione di volumi protetti da BitLocker (se applicabile)

Se il volume della VM è cifrato, sbloccalo prima delle operazioni:

manage-bde -status
manage-bde -unlock D: -RecoveryPassword &lt;48-CIFRE-CHIAVE&gt;
manage-bde -protectors -disable D:

Ricorda di riabilitare la protezione al termine:

manage-bde -protectors -enable D:

Uscita dalla rescue e riavvio della VM

Quando tutto è pronto, esci dalla modalità di soccorso e riavvia dal disco originale:

openstack server unrescue &lt;SERVERIDOR_NAME&gt;
openstack server show &lt;SERVERIDOR_NAME&gt; -c status -f value

La VM dovrebbe tornare in stato ACTIVE e avviarsi normalmente.

Verifiche post-ripristino

Accesso in RDP/console riuscito e tempi di boot nella norma.
Registro eventi System senza errori critici su Kernel-Boot/Boot-Manager.
Integrità dei servizi applicativi (IIS, SQL Server, AD DS, ecc.).
Conferma che l’ESP (UEFI) o la partizione attiva (BIOS) non siano rimaste montate con lettera fissa (pratica sconsigliata in produzione).

Risultato

La VM è stata ripristinata con successo: il boot viene eseguito dal disco originale senza errori. Il ripristino di winload.exe, insieme alla revisione del BCD e alla riparazione del codice di avvio, riporta il sistema a uno stato coerente e stabile.

Risoluzione dei problemi comuni

“bootrec /fixboot Access is denied” (UEFI)

Monta l’ESP (FAT32) con diskpart e assegna una lettera (es. S:). Esegui bcdboot D:\Windows /s S: /f UEFI. Se necessario, rinomina il BCD esistente e ricrealo come mostrato sopra.

Lettere di unità diverse da C:/D:

Usa diskpart → list volume e assegna le lettere desiderate (assign letter=...). Identifica il disco giusto guardando dimensione, tipo file system, presenza di \Windows.

Volume non leggibile/NTFS corrotto

Esegui chkdsk /f /r. Se persiste, valuta il ripristino da snapshot o backup. Un danneggiamento del metadata NTFS può impedire il boot anche con BCD corretto.

BitLocker abilitato senza chiavi

Senza la chiave di ripristino non è possibile montare il volume in chiaro. Recupera la chiave dal tuo vault (AD/Azure AD/gestore segreti) prima di procedere.

Mismatch di build per winload.exe

Usa sfc /scannow /offbootdir /offwindir per rigenerare i binari dal WinSxS del sistema offline. Evita di copiare winload.exe da build diverse.

La VM resta in loop sul ripristino automatico

Ricrea completamente i file di boot con bcdboot, quindi controlla driver storage/virtio e integrità del file system. In ultima istanza, esamina setupact.log/setuperr.log in \Windows\Panther.

Automazione: esempio di script per interventi rapidi

Puoi salvare uno script BAT nella rescue image per accelerare le operazioni ripetitive. Esempio (BIOS/UEFI auto-gestito):

@echo off
setlocal enabledelayedexpansion

echo [*] Rilevamento volume Windows...
for %%L in (D E F G H I J K L M N O P Q R S T U V W X Y Z) do (
if exist %%L:\Windows\System32 (
set WINVOL=%%L:
goto :found
)
)
echo [!] Volume Windows non trovato. Uscita.
goto :eof
:found
echo     Trovato: %WINVOL%

echo [*] Copia winload.exe (se presente in C:)
if exist C:\Windows\System32\winload.exe copy /Y C:\Windows\System32\winload.exe %WINVOL%\Windows\System32\winload.exe

echo [*] SFC offline
sfc /scannow /offbootdir=%WINVOL%\ /offwindir=%WINVOL%\Windows

echo [*] Ricerca ESP (UEFI)...
set ESP=
for %%L in (S R T U V W X Y Z) do (
fsutil fsinfo volumeinfo %%L: >nul 2>&1
if !errorlevel! EQU 0 (
dir %%L:\EFI\Microsoft\Boot\BCD >nul 2>&1
if !errorlevel! EQU 0 set ESP=%%L:
)
)

echo [*] Ricostruzione BCD...
if defined ESP (
echo     Modalita': UEFI su %ESP%
bcdboot %WINVOL%\Windows /s %ESP% /f UEFI
) else (
echo     Modalita': BIOS/MBR
bcdboot %WINVOL%\Windows /f BIOS
)
echo [*] Riparazione boot code...
bootrec /fixmbr
bootrec /fixboot

echo [*] CHKDSK
chkdsk %WINVOL% /f

echo [OK] Operazioni completate. Eseguire unrescue e riavvio.

Buone pratiche operative

Automatizzare: conserva uno script BAT/PowerShell nella rescue image per ridurre errori e tempi di intervento.
Snapshot prima dei test: in OpenStack crea uno snapshot del volume prima di simulare guasti, così da poter fare rollback immediato.
Coerenza binari: usa winload.exe e tool della stessa build di Windows Server 2019.
Verifica firmware: in UEFI controlla che il BCD punti a \EFI\Microsoft\Boot\bootmgfw.efi e che il loader sia \Windows\System32\winload.exe sul disco corretto.
Audit trail: annota ID immagine rescue, comandi eseguiti e timestamp per analisi forensi e audit.

Tabelle di riferimento

Confronto rapido BIOS vs UEFI

Voce	BIOS/MBR	UEFI/GPT
Percorso BCD	`D:\Boot\BCD`	`S:\EFI\Microsoft\Boot\BCD`
Partizione di sistema	Attiva su disco OS	ESP FAT32 dedicata (100–260 MB)
Comando chiave	`bcdboot D:\Windows /f BIOS`	`bcdboot D:\Windows /s S: /f UEFI`
Riparazione settore di avvio	`bootrec /fixboot`	`bootrec /fixboot` (talvolta serve montare l’ESP)
Loader Windows	`\Windows\System32\winload.exe`	`\Windows\System32\winload.efi` (richiamato da `bootmgfw.efi`)

Sequenza operativa minima

Passo	Comando/azione	Scopo
Rescue	`openstack server rescue --image ...`	Avvio in ambiente di soccorso
Mappatura unità	`diskpart → assign`	Esporre il volume della VM come `D:`
Ripristino file	`copy C:\...\winload.exe D:\...\` o `sfc /scannow /off...`	Ripristinare il loader mancante
BCD	`bootrec /rebuildbcd` e/o `bcdboot`	Ripristinare la configurazione di boot
Boot code	`bootrec /fixmbr`, `bootrec /fixboot`	Riparare MBR/settore di avvio
FS check	`chkdsk D: /f`	Assicurare integrità NTFS
Unrescue	`openstack server unrescue`	Ripristinare boot dal disco originale

Appendice: uso essenziale del CLI OpenStack

Se disponi di una rescue image Windows registrata in Glance, il flusso è il seguente:

# Elenco immagini per individuare la rescue
openstack image list --name "win-rescue" --long

Avvio rescue

openstack server rescue --image  

Monitoraggio

openstack server show  -c status -f value
openstack console log show  --lines 100

Uscita rescue

openstack server unrescue

Suggerimento: se il root disk è un volume Cinder, lo vedrai come volume aggiuntivo nel sistema rescue. Evita di staccarlo/attaccarlo ad altre istanze durante l’operazione per non incorrere in lock a livello di storage.

Considerazioni di performance e rischio

Tempo di ripristino: la via del rescue evita copie massive e riduce il downtime rispetto a migrazioni o rebuild completi.
Rischio dati: agendo offline sul volume si minimizzano conflitti; resta fondamentale avere uno snapshot per il rollback.
Compatibilità driver: in ambienti KVM/virtio, assicurati che i driver virtio siano integri nel sistema della VM; problemi ai driver di storage possono emulare sintomi di boot fallito.

Conclusioni

Il ripristino di una VM Windows Server 2019 su Red Hat OpenStack senza accesso a ISO né detaching del root disk è pienamente gestibile tramite rescue image. La combinazione di ripristino del file winload.exe, rebuild del BCD e riparazione del boot code, seguita da chkdsk, offre un percorso chiaro, ripetibile e sicuro. Automatizzando i comandi e mantenendo snapshot disciplinati, trasformi un incidente critico in una manutenzione ordinaria con tempi prevedibili.

Contenuto essenziale (riepilogo operativo)

Avvio in rescue: la rescue image diventa C:, il disco della VM è D:.
Mappatura: conferma/assegna le lettere con diskpart.
Ripristina winload.exe da C:\Windows\System32 a D:\Windows\System32 (o usa sfc offline).
BCD: bootrec /rebuildbcd, verifica i percorsi; se necessario bcdboot.
Boot code: bootrec /fixmbr, bootrec /fixboot.
Integrità: chkdsk D: /f.
Unrescue e riavvio: la VM torna a bootare dal disco originale senza errori.

Tip extra: mantieni nella rescue image uno script BAT/PowerShell preconfezionato con i comandi chiave, una pagina di playbook e riferimenti di build per intervenire in modo standardizzato.

FAQ lampo

Serve una ISO? No: il flusso si basa su rescue image (raw/qcow2), allineata a Windows Server 2019.
Posso staccare il disco root? In questo scenario no; la rescue lo collega come volume e consente interventi offline.
E se il problema non è solo winload.exe? Esegui sfc offline, DISM /Image:%WINVOL%\ /Cleanup-Image /RestoreHealth (se disponibile) e controlla i log di boot.

Credito operativo: procedura validata in ambiente RHOSP 17.1; l’utente conferma che, completati i passaggi, il sistema si avvia normalmente.

—