VMware - Restaurar un WindowsImageBackup (VHDX) como VM arrancable

Convertir una copia de WindowsImageBackup de un PC fisico en una VM de VMware Workstation que arranca. El proceso encadena tres fallos distintos que conviene entender por separado, porque cada uno se manifiesta con un mensaje que apunta a otro sitio.

Síntomas

1. vmware-vdiskmanager: The specified virtual disk needs repair al abrir el disco convertido con qemu-img.
2. Exception 0xc0000005 (access violation) al arrancar la VM, con vmware-vmx.dmp y minidump.
3. 0xc000000e / 0xc000014c (BCD missing) al intentar bootear: el arranque apunta a la firma de disco del PC original.

Causa 1: conversión interrumpida o cabecera sparse corrupta

Si el proceso qemu-img se interrumpe (o se queda leyendo y escribiendo en el mismo disco USB), los VMDK parciales quedan con la cabecera sparse marcada como sucia. Síntoma en el log:

DISKLIB-SPARSE: failed to open (14): Failed to check header

vmware-vdiskmanager -R no lo repara cuando la corrupción es del extent, no del descriptor. Hay que reconvertir desde el origen.

Comprobación y limpieza:

Get-Process qemu-img -ErrorAction SilentlyContinue | Select-Object Id, StartTime, CPU
 
# Si Stop-Process devuelve "Acceso denegado" por ser hijo de otro proceso:
 
$inst = Get-CimInstance Win32_Process -Filter "ProcessId=<PID>"
$inst | Invoke-CimMethod -MethodName Terminate

Causa 2: crash 0xc0000005 por falta de slots PCIe

El access violation de VMware no es un bug del producto. En vmware.log aparece el motivo real:

[msg.pci.noslotavail] No PCIe slot available for Ethernet0. Remove Ethernet0 and try again.
E1000PCI: failed to register e1000e device.

Dos factores combinados:

1. Faltan los pcibridge* en el .vmx. Una VM convertida desde backup declara solo sata0 y svga; los puentes nativos quedan ocupados y no hay hueco para la NIC.
2. virtualDev = "e1000e" puede tumbar el proceso vmx contra puentes recien creados. Cambiar a e1000 (Intel 82545EM, driver incluido en Windows 10) registra el dispositivo sin crash.

Causa 3: BCD apunta al disco original

Un WindowsImageBackup de metal desnudo no es arrancable en hardware distinto: el BCD de la partición ESP guarda la firma del disco original y el offset de la partición Windows. Al cambiar controladora (fisica a SATA virtual) y firma, winload.efi no encuentra la partición. Es esperado: siempre hay que reparar el BCD.

Procedimiento

1. Convertir VHDX a VMDK escribiendo en disco local

El error clasico es leer del USB y escribir en el mismo USB: la contención de cabezal lo hace hasta seis veces más lento. Leer del USB y escribir en NVMe.

$qemu = "<ruta>\qemu-img.exe"
$src = "D:\WindowsImageBackup\<EQUIPO>\Backup <fecha>"
$out = "C:\VMs\<VM>"
New-Item -ItemType Directory -Path $out -Force | Out-Null
 
& $qemu convert -p -f vhdx -O vmdk -o subformat=monolithicSparse "$src\Esp.vhdx" "$out\Esp.vmdk"
 
& $qemu convert -p -f vhdx -O vmdk -o subformat=monolithicSparse `
 "$src\<GUID>.vhdx" "$out\<VM>.vmdk"

Rendimiento medido en un caso real (288 GB): lectura USB 77 MB/s, escritura USB 77 MB/s, lectura y escritura en el mismo USB 13 MB/s, lectura USB más escritura NVMe 134 MB/s. De 3-4 horas a unos 40 minutos.

Nota: qemu-img de la versión 2.3.0 no acepta -m ni -W aunque aparezcan en --help.

2. Quitar ethernet del .vmx antes del primer arranque

El .vmx heredado trae ethernet0.pciSlotNumber en conflicto con el resto de dispositivos.

ethernet0.present = "FALSE"
# eliminar tambien: ethernet0.pciSlotNumber, ethernet0.addressType,
 
# ethernet0.generatedAddress, ethernet0.generatedAddressOffset
 

3. Reparar el BCD offline desde el host

Más rápido y fiable que pelear con “Press any key to boot from CD” dentro de la VM. Requiere PowerShell como administrador y Mount-VHD no disponible (sin Hyper-V), así que se usa diskpart.

@'
select vdisk file="D:\WindowsImageBackup\<EQUIPO>\Backup <fecha>\<GUID>.vhdx"
attach vdisk readonly
select vdisk file="D:\WindowsImageBackup\<EQUIPO>\Backup <fecha>\Esp.vhdx"
attach vdisk
exit
'@ | Out-File "$env:TEMP\dp.txt" -Encoding ASCII; diskpart /s "$env:TEMP\dp.txt"
 
diskpart
# DISKPART> list vol
 
# volumen NTFS grande = particion Windows (sin letra)
 
# volumen FAT32 ~96 MB = ESP (sin letra)
 
# DISKPART> select vol <n_esp> ; assign letter=S
 
# DISKPART> select vol <n_windows> ; assign letter=W
 
# DISKPART> exit
 
bcdboot W:\Windows /s S: /f UEFI
# debe responder: "Archivos de arranque creados correctamente."
 

Después, desmontar los dos VHDX con detach vdisk.

4. Reconverir solo el ESP

El BCD reparado está en el VHDX original; la VM usa VMDK. Basta reconvertir el ESP (unos segundos). El disco de Windows no cambia y no necesita reconversión.

& $qemu convert -p -f vhdx -O vmdk -o subformat=monolithicSparse "$src\Esp.vhdx" "$out\Esp.vmdk"

5. Arrancar en frio

Remove-Item "$out\nvram" -Force -ErrorAction SilentlyContinue
& "C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" -T ws start "$out\<VM>.vmx" gui

Windows arranca, detecta hardware nuevo y llega al login.

6. Reanadir la red sin crashear

No vale con “Settings - Add Network Adapter”: VMware descarta los pcibridge anadidos a mano y vuelve a “no hot-pluggable slots”. Hay que declarar todo en el .vmx con la VM apagada y no abrir Settings después.

# Puentes PCI: sin ellos VMware no tiene donde enchufar la NIC
 
pcibridge0.present = "TRUE"
pcibridge4.present = "TRUE"
pcibridge4.pciSlotNumber = "18"
pcibridge5.present = "TRUE"
pcibridge5.pciSlotNumber = "19"
pcibridge6.present = "TRUE"
pcibridge6.pciSlotNumber = "32"
pcibridge7.present = "TRUE"
pcibridge7.pciSlotNumber = "33"
 
# Red NAT con e1000 (no e1000e)
 
ethernet0.present = "TRUE"
ethernet0.startConnected = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.virtualDev = "e1000"
ethernet0.pciSlotNumber = "35"
ethernet0.generatedAddress = "00:0c:29:xx:xx:xx"
ethernet0.generatedAddressOffset = "0"
 
# USB 2.0 activo desde el arranque
 
ehci.present = "TRUE"
ehci.pciSlotNumber = "34"
usb.present = "TRUE"

Arrancar con Archivo - Abrir - seleccionar el .vmx - Power on directo, sin pasar por Settings. Windows detectara “Intel PRO/1000 MT Desktop Adapter” y tomara DHCP del rango NAT de VMware.

Mapa de slots que asigna VMware

sata0 -> 16
pciBridge0 -> 17
pciBridge4 -> 18
pciBridge5 -> 19
pciBridge6 -> 32
pciBridge7 -> 33
ehci -> 34
ethernet0 -> 35

Slots validos: 0-31 para PCIe primarios y 32 o más para los secundarios.

Verificar los discos

& "C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -R "C:\VMs\<VM>\Esp.vmdk"
& "C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -R "C:\VMs\<VM>\<VM>.vmdk"
# exit=0 significa correcto
 

Lecciones aplicables

1. vmware-vdiskmanager -R no repara todo: si la corrupción es estructural del sparse extent, hay que reconvertir desde el origen.
2. Un access violation de VMware puede ser solo síntoma. El motivo real está en vmware.log ([msg.pci.noslotavail]).
3. Nunca convertir leyendo y escribiendo en el mismo disco USB: la contención de cabezal multiplica el tiempo.
4. Reparar el BCD offline con diskpart y bcdboot es más rápido y fiable que arrancar WinRE desde ISO.
5. Mount-VHD exige Hyper-V; diskpart con attach vdisk hace lo mismo y siempre está disponible.
6. Tras reparar el BCD, reconvertir solo el ESP: el disco de Windows no cambia.
7. Borrar nvram cuando se altera la configuración de arranque: persiste el orden EFI anterior.
8. No editar el .vmx con VMware abierto: vmware.exe o vmware-vmx.exe reescriben el fichero al cerrar.
9. No entrar en Settings después de editar el .vmx a mano: la interfaz reconstruye el fichero y elimina los pcibridge* que no reconoce.
10. Los pcibridge* son obligatorios en .vmx convertidos: sin ellos no hay hueco para la NIC ni hot-add.
11. Si Stop-Process falla por permisos, taskkill /F /T /PID termina el árbol completo.
12. Un adaptador WLAN USB no sustituye a la NAT: muchos chipsets no tienen driver firmado en Windows 10 y solo sirven para Wi-Fi.
13. e1000 es más lento que vmxnet3, pero vmxnet3 necesita VMware Tools instaladas y en algunas builds heredadas conviene quedarse en e1000.