El reto del conductor

En su entorno VMware, Windows carga los controladores paravirtualizados VMware ( vmxnet3 para red, pvscsi para almacenamiento, etc.) y los vincula a identificadores de hardware específicos. Al trasladar el disco a VPC, cambia el hardware:

• Red: VMware vmxnet3 → Adaptador de red de E/S virtual ( VirtIO )
• Almacenamiento (arranque): VMware PVSCSI → VirtIO Adaptador SCSI
• Almacenamiento (datos): VMware PVSCSI → VirtIO adaptador de bloque

Si Windows arranca y encuentra diferentes IDs de hardware para su controlador de almacenamiento de arranque, falla el arranque (pantalla azul INACCESSIBLE_BOOT_DEVICE).

Solución A: Método Sysprep

La utilidad de Microsoft sysprep "generaliza" una instalación de Windows, restableciéndola a un estado de primer arranque. Esto:

• Libera los enlaces de los controladores
• Restablece el identificador de seguridad de Windows (SID)
• Elimina la información específica del ordenador
• Prepara la imagen para su redistribución

Complete el siguiente proceso para sysprep:

1. Instale los controladores VirtIO en su máquina virtual Windows mientras sigue alojada en VMware:

   1. Descarga la imagen ISO de virtio-win desde una instancia de servidor virtual RHEL (/usr/share/virtio-win).
   2. Monte ISO, ejecute virtio-win-gt-x64.exe, y virtio-win-guest-tools.exe.
   3. Instale los controladores tanto para el sistema operativo como para la partición de recuperación.

2. Ejecute sysprep:

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

3. Exporte y migre utilizando cualquiera de los métodos de migración, excepto VDDK Direct Extraction, que es sólo para vCenter.

4. Primer arranque en VPC:

   • Windows ejecuta el miniasistente de configuración (OOBE)
   • Detecta nuevo hardware, carga los controladores VirtIO
   • Podría ser necesario volver a introducir la clave del producto
   • Podría ser necesario volver a unirse al dominio

Ventajas:

• Proceso Microsoft bien documentado
• Funciona de forma fiable en instalaciones Windows

Desventajas:

• Restablece la identidad de la máquina (problemático para servidores unidos a un dominio)
• Podría provocar la reactivación de Windows
• Problemas específicos de la aplicación (algunas aplicaciones no gestionan bien sysprep)
• Requiere completar OOBE en el primer arranque

Decisión de diseño: Utilice sysprep para implementaciones basadas en plantillas o cuando migre a máquinas virtuales de desarrollo o de prueba en las que el restablecimiento de identidades sea aceptable. Evitar para servidores de producción unidos por dominios con dependencias de aplicaciones complejas.

Solución B: Inyección del controlador « virt-v2v »

La herramienta libguestfs virt-v2v puede inyectar controladores VirtIO en una instalación de Windows sin ejecutar sysprep. Sí:

• Monta el sistema de archivos de Windows (sin arrancar Windows)
• Inyecta controladores VirtIO en el almacén de controladores
• Modifica el registro para forzar a Windows a cargar estos controladores
• Conserva la identidad de la máquina, la pertenencia a un dominio y el estado de la aplicación

Requisitos previos:

• La máquina virtual debe apagarse de forma limpia (no colapsada, no forzada)
• Debe ser compatible con la versión de Windows (Server 2008 R2 a 2025, Windows 7 a 11)
• Paquete de controladores Virtio-win (disponible en sistemas RHEL: /usr/share/virtio-win)

A continuación se describe el proceso de inyección de controladores de virt-v2v:

1. Instale los controladores VirtIO en las particiones de arranque y recuperación de Windows (igual que el método sysprep)

2. Apagar limpiamente la máquina virtual Windows

3. Exporta o transfiere el disco a una instancia de servidor virtual de trabajo utilizando cualquiera de los métodos de migración.

4. Ejecutar virt-v2v:

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

   Parámetros:

   • -i disk: La entrada es un archivo de imagen de disco
   • -o disk -os /target: Salida al directorio
   • --block-driver virtio-scsi: Utilizar controlador SCSI para el primer disco (necesario para volúmenes de arranque VPC)

5. Si se escribe directamente en el dispositivo:

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

Ventajas de virt-v2v:

• Preserva la identidad de la máquina (sin reactivación ni redominio)
• No hay asistente para el primer arranque
• Estado de la aplicación intacto
• Funciona en servidores de producción

Desventajas:

• Requiere una configuración híbrida RHEL/ Ubuntu
• Más complejo que sysprep
• Requiere un apagado limpio (no procesa máquinas virtuales estropeadas/apagadas a la fuerza)

Decisión de diseño: Utilice virt-v2v para los servidores Windows de producción en los que la preservación de la identidad es fundamental. Acepte la complejidad adicional de las herramientas como compensación por unas migraciones más limpias.

# 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

Arquitectura del controlador de almacenamiento de Windows en VPC

Comprender cómo VPC presenta el almacenamiento a Windows ayuda a solucionar los problemas de arranque:

Primer volumen (disco de arranque):

• Presentado como VirtIO Dispositivo SCSI
• Requiere un controlador virtio-scsi
• Por eso es obligatorio --block-driver virtio-scsi

Volúmenes posteriores (discos de datos):

• Presentados como dispositivos de bloque VirtIO
• Se necesita un controlador virtio-blk
• Controlador diferente del disco de arranque

Ambos controladores deben estar instalados en ambos:

• El sistema operativo en funcionamiento
• El entorno de recuperación ( WinRE )

Instalación de controladores en el entorno de recuperación

El Entorno de recuperación de Windows ( WinRE ) es un mini-entorno de Windows independiente que se utiliza para operaciones de recuperación. Si no dispone de controladores de E/S virtual ( VirtIO ), no podrás utilizarlo para la recuperación tras la migración.

Localización de WinRE:

reagentc /info

Esto podría informar de un volumen de recuperación, pero la imagen real WinRE podría estar en:

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

Instalación de controladores en WinRE:

1. Montar virtio-win ISO

2. Identifique la ubicación de WinRE mediante reagentc /info

3. Si está en un volumen separado, móntalo temporalmente

4. Utilice DISM para inyectar controladores:

   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
   

Consideraciones sobre la partición GPT:

Si su disco Windows utiliza GPT (no MBR):

• Utilice list volume y select volume en lugar de list partition
• La configuración de los ID de volumen es diferente:
  • Volumen de datos: set id=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
  • Volumen del sistema: set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b

Versiones de Windows compatibles

Red Hat el paquete virtio-win proporciona controladores para:

Windows Server:

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

Cliente Windows:

• 7
• 8, 8.1
• 10
• 11

Las versiones anteriores (Server 2003, 2008 non-R2, Vista) no son compatibles.

La siguiente tabla es la matriz de decisiones de diseño para Windows