Passthrough de GPU en Hyper-V: una guía esencial para principiantes

Las máquinas virtuales de Hyper-V utilizan, de forma predeterminada, un adaptador gráfico emulado, que resulta suficiente para tareas básicas de visualización, pero carece del rendimiento necesario para cargas de trabajo aceleradas por GPU, como el renderizado 3D, la inferencia de aprendizaje automático o los cálculos basados en CUDA. El «GPU passthrough» de Hyper-V resuelve este problema asignando una tarjeta gráfica física directamente a una máquina virtual, evitando la emulación y proporcionando al sistema operativo invitado acceso completo a la GPU física.

Esta guía describe los dos métodos disponibles para la asignación de GPU en Hyper-V: la asignación directa de dispositivos (DDA) y la partición de GPU (GPU-P). Lee esta entrada para saber cómo cumplir los requisitos de hardware y software, configurar cada método en Windows Server y en las versiones de Windows para clientes, y solucionar problemas comunes.

NAKIVO para backup de Hyper-V

Copias de seguridad sin agente y coherentes con las aplicaciones para Hyper-V. Protección contra el ransomware, inicio instantáneo de máquinas virtuales desde la copia de seguridad, compatibilidad con otras plataformas virtuales y físicas, y mucho más.

Descubre Solution

¿Qué hay de nuevo?

Esta guía se ha actualizado para reflejar los cambios introducidos en Windows Server 2025 y en las últimas versiones de Windows para clientes:

• Windows Server 2025 introduce la partición de GPU (GPU-P) como una función empresarial totalmente compatible, lo que permite que varias máquinas virtuales compartan un recurso compartido de GPU mediante el aislamiento basado en SR-IOV.
• La migración en vivo ya es compatible con máquinas virtuales con particiones de GPU en Windows Server 2025, lo que permite el mantenimiento del host sin tiempo de inactividad de las máquinas virtuales.
• Se ha ampliado la compatibilidad con los clústeres de conmutación por recuperación: las máquinas virtuales con GPU-P se pueden configurar como roles en clúster, y las máquinas virtuales respaldadas por DDA pueden reiniciarse en otro nodo del clúster si hay una GPU compatible disponible.
• El componente vGPU de RemoteFX se ha eliminado por completo en Windows Server 2025 (obsoleto desde Windows Server 2019).
• Se han actualizado las directrices de resolución de problemas y las consideraciones sobre hacer backup de máquinas virtuales con GPU.

¿Qué es el «GPU Passthrough»?

Cuando se inicia una máquina virtual de Hyper-V, recibe un adaptador de vídeo emulado que procesa los gráficos a través de la CPU del host. Esto es suficiente para el acceso a la consola y el uso básico del escritorio, pero no permite aprovechar las funciones de hardware de las que dependen las cargas de trabajo que requieren una GPU: shaders de cálculo, cifrado de vídeo por hardware, núcleos CUDA o compatibilidad con DirectX 12.

El «GPU passthrough» elimina esta capa de emulación. En lugar de enrutar los gráficos a través de un adaptador virtual, Hyper-V asigna una tarjeta gráfica física a la máquina virtual a nivel de PCI Express (PCIe). El sistema operativo invitado se comunica directamente con la GPU, utilizando el controlador nativo del proveedor en lugar de una abstracción de Hyper-V. Desde la perspectiva de las aplicaciones que se ejecutan dentro de la máquina virtual, la GPU se comporta como si estuviera instalada en una máquina física.

Hyper-V admite dos mecanismos para ello. La asignación directa de dispositivos (DDA) cede toda la GPU física a una única máquina virtual. La partición de la GPU (GPU-P) divide una tarjeta en fracciones aisladas para que varias máquinas virtuales puedan ser recursos compartidos. Ambos se tratan en detalle más adelante en esta guía.

Nota: Una GPU puede estar integrada en el chip de la CPU (algo habitual en los procesadores recientes de Intel y AMD) o montada en una tarjeta gráfica discreta conectada a la placa base a través de PCIe. La asignación directa y la partición de GPU suelen estar destinadas a las GPU discretas, aunque GPU-P también puede funcionar con gráficos integrados en las versiones cliente de Windows.

Ventajas principales de la asignación directa de GPU en Hyper-V

Una tarjeta gráfica física conectada mediante asignación directa de GPU puede ser útil para usuarios domésticos, desarrolladores, diseñadores y otras personas que necesitan gráficos acelerados por hardware en una máquina virtual. Entre los escenarios más habituales se incluyen:

• Ejecutar aplicaciones con uso intensivo de gráficos, como programas de modelado 3D, dibujo en AutoCAD, simulaciones de ingeniería, desarrollo de juegos y renderizado acelerado por hardware;
• Ejecutar juegos que requieren funciones de aceleración por hardware; es posible que algunos títulos no funcionen sin una tarjeta de vídeo física;
• Ejecutar cargas de trabajo de aprendizaje automático (ML) e inteligencia artificial (IA) que aprovechan las capacidades de procesamiento de la GPU.

Las ventajas de la asignación directa de GPU incluyen:

• Mejor rendimiento gráfico. Las máquinas virtuales obtienen acceso directo a la tarjeta gráfica para ejecutar aplicaciones o juegos exigentes. La reproducción de vídeo es más fluida y se dispone de renderizado acelerado por hardware con las API gráficas más recientes.
• Uso flexible del hardware. Un único host de Hyper-V puede ejecutar varias máquinas virtuales con distintas cargas de trabajo gráficas en casos en los que las estaciones de trabajo dedicadas no serían prácticas.
• Eficiencia de costos. La asignación directa de GPU puede reducir los costos de hardware al consolidar las cargas de trabajo. Esta función también se aplica a las implementaciones de infraestructura de escritorio virtual (VDI).

Asignación directa de GPU frente a partición de GPU (GPU-P)

Hyper-V ofrece dos métodos para asignar recursos de GPU a máquinas virtuales:

• Asignación directa de dispositivos (DDA) asigna una GPU física completa exclusivamente a una sola máquina virtual. La máquina virtual obtiene acceso completo al hardware y el máximo rendimiento, pero ninguna otra máquina virtual puede usar esa GPU. DDA está disponible en Windows Server 2016 y versiones posteriores (ediciones Datacenter). Las máquinas virtuales respaldadas por DDA no se pueden migrar en vivo.
• La partición de GPU (GPU-P) divide una GPU física en varias fracciones aisladas mediante SR-IOV, lo que permite que varias máquinas virtuales compartan el mismo hardware. Cada máquina virtual recibe una parte dedicada de los recursos de la GPU (memoria, procesamiento y codificadores), con aislamiento aplicado por hardware. GPU-P está disponible como función empresarial totalmente compatible en Windows Server 2025 y también se puede usar en las versiones cliente de Windows 10/11 mediante PowerShell.

Se prefiere DDA cuando una carga de trabajo necesita toda la GPU o cuando el hardware no admite la partición. GPU-P es más adecuado para entornos en los que varias máquinas virtuales necesitan aceleración por GPU sin requerir el 100 % de los recursos de la tarjeta. GPU-P también admite la migración en vivo y la agrupación en clústeres de conmutación por recuperación en Windows Server 2025, algo que DDA no admite.

Una GPU física puede funcionar en modo DDA o GPU-P, pero no en ambos simultáneamente.

Requisitos

Para configurar una máquina virtual con acceso directo a la GPU en un host de Hyper-V, debe cumplir ciertos requisitos de hardware y software. No todas las tarjetas de vídeo admiten esta función.

Requisitos de hardware

• La CPU del host de Hyper-V debe admitir las funciones de virtualización Intel VT-d o AMD-V. La función correspondiente debe estar habilitada en los ajustes de UEFI/BIOS.
• La CPU debe admitir la unidad de administración de memoria de entrada/salida (IOMMU). Esta función es necesaria para el acceso directo a través de PCI Express, incluido el acceso directo a la GPU.
• Para la partición de GPU con migración en vivo en Windows Server 2025, la CPU debe admitir capacidades específicas de seguimiento de DMA (acceso directo a memoria). Los procesadores Intel Sapphire Rapids (o posteriores) y AMD EPYC Milan (o posteriores) cumplen este requisito.
• Una tarjeta de vídeo con una GPU que admita tecnologías de virtualización de GPU, como NVIDIA GRID o AMD MxGPU (GPU multiusuario). Estas tecnologías son específicas de cada proveedor. El hardware de clase servidor mejora las tasas de éxito. No se admiten dispositivos antiguos que usen interrupciones PCI (INTx).
• Para la partición de GPU, la GPU debe admitir SR-IOV (virtualización de E/S de raíz única). Entre los modelos compatibles se incluyen las GPU NVIDIA A2, A10, A16 y A40.

Requisitos de software

• Windows Server 2016 o posterior para DDA. Se recomienda Windows Server 2025 Datacenter para la partición de GPU con compatibilidad con la agrupación en clústeres y la migración en vivo.
• Windows 10 (compilación 1903 o posterior) o Windows 11 para la partición de GPU en sistemas cliente. DDA no es compatible con las versiones cliente de Windows.
• El rol de Hyper-V debe estar habilitado en Windows.
• Los controladores de GPU más recientes deben estar instalados en el host de Hyper-V y en el sistema operativo invitado de la máquina virtual.
• Para el acceso directo a la GPU con DDA, solo se pueden usar máquinas virtuales de Hyper-V de segunda generación.

Limitaciones y configuraciones no compatibles

Tenga en cuenta que las siguientes configuraciones no son compatibles con el acceso directo a la GPU:

• Las máquinas virtuales con la memoria dinámica de Hyper-V habilitada no pueden usar el acceso directo a la GPU. La memoria dinámica debe estar desactivada antes de asignar una GPU.
• El acceso directo a GPU con DDA solo está disponible en las ediciones Datacenter de Windows Server. La partición de GPU en entornos en clúster también requiere la edición Datacenter.
• Si se instala el Subsistema de Windows para Linux en el host de Hyper-V, puede producirse un error de código 43 en la máquina virtual cuando se le asigna una GPU mediante particiones.
• En las versiones anteriores a Windows Server 2025, las funciones de clúster, como la alta disponibilidad (HA) y la migración en vivo de máquinas virtuales, no son compatibles con las máquinas virtuales habilitadas para GPU. Windows Server 2025 añade compatibilidad con la migración en vivo de máquinas virtuales GPU-P y el reinicio por conmutación por error de máquinas virtuales DDA.
• Las máquinas virtuales con una GPU asignada no admiten guardar/restaurar ni puntos de control automáticos. Desactive los puntos de control automáticos antes de asignar una GPU.

Configuración del acceso directo a GPU: lo que necesita saber

El método que se utiliza para asignar una GPU a una máquina virtual de Hyper-V depende de la versión de Windows y del nivel de uso compartido del hardware que se necesite. Microsoft ha ofrecido tres métodos a lo largo del tiempo, y solo dos siguen siendo compatibles.

RemoteFX vGPU (en desuso). Disponible desde Windows Server 2012 R2 hasta Windows Server 2016, RemoteFX amplió el Protocolo de escritorio remoto (RDP) para compartir una sola GPU del host entre varias máquinas virtuales. Era útil en entornos VDI de alta densidad, donde no era práctico dedicar una tarjeta completa a cada máquina virtual. Sin embargo, RemoteFX limitaba la memoria de vídeo dedicada a 1 GB por máquina virtual y la frecuencia de fotogramas a 30 FPS. Microsoft lo declaró en desuso en Windows Server 2019 y Windows 10, compilación 1809, debido a vulnerabilidades de seguridad arquitectónicas en la implementación de Hyper-V, y lo he eliminado por completo en Windows Server 2025. Si todavía ejecuta una versión que incluía RemoteFX, hay disponible un actualización específica para eliminar el componente.

Asignación directa de dispositivos (DDA). Introducida en Windows Server 2016, DDA sustituyó a RemoteFX en los escenarios que requieren el rendimiento completo de la GPU. Asigna un dispositivo PCIe completo (GPU, unidad NVMe u otro adaptador) directamente a una sola máquina virtual, sin compartirlo ni usar una capa de emulación. La máquina virtual carga el controlador nativo del proveedor y obtiene acceso sin restricciones a la memoria de vídeo y a la frecuencia de fotogramas. DDA es el equivalente de Hyper-V a la asignación directa de PCI de VMware. La contrapartida es la flexibilidad: solo una máquina virtual puede usar la tarjeta, no se puede migrar la máquina virtual en vivo (está vinculada a una ruta PCIe física del host) y DDA solo está disponible en las ediciones Datacenter de Windows Server. En Windows Server 2025, las máquinas virtuales respaldadas por DDA obtuvieron compatibilidad con clústeres de conmutación por error, lo que significa que el clúster puede reiniciar la máquina virtual en otro nodo si hay una GPU compatible disponible, pero la migración en vivo sigue sin ser compatible.

Particionamiento de GPU (GPU-P). GPU-P es el sucesor moderno de RemoteFX. En Windows Server 2025, divide una sola GPU física en varias fracciones aisladas mediante SR-IOV, lo que proporciona a cada máquina virtual una porción dedicada de los recursos de cómputo, memoria y codificador, con aislamiento impuesto por hardware. A diferencia de DDA, GPU-P admite la migración en vivo y los clústeres de conmutación por error en Windows Server 2025 Datacenter, por lo que es una opción viable para entornos productivos que requieren movilidad de las máquinas virtuales. En las versiones cliente de Windows (Windows 10, compilación 1903 o posterior, y Windows 11), GPU-P está disponible mediante PowerShell, pero se basa en la paravirtualización de WDDM en lugar del particionamiento real mediante SR-IOV. El host y el invitado deben ejecutar la misma versión del sistema operativo, y los controladores de GPU deben copiarse manualmente del host al invitado.

La implicación práctica es sencilla: si necesita la GPU completa para una sola máquina virtual en Windows Server, use DDA. Si varias máquinas virtuales necesitan aceleración de GPU o necesita migración en vivo, use GPU-P en Windows Server 2025. En Windows cliente, GPU-P mediante PowerShell es la única opción compatible.

Configuración de la transferencia directa de GPU en Hyper-V

Siga los pasos a continuación para preparar el entorno y configurar la transferencia directa de GPU en Hyper-V.

Preparación para configurar la transferencia directa de GPU

1. Asegúrese de que el hardware y el software cumplan los requisitos de virtualización de GPU.
2. Habilite las funciones de virtualización Intel VT-d o AMD-V para la CPU en UEFI/BIOS del host de Hyper-V.
3. Habilite IOMMU . La ubicación de la configuración de IOMMU varía según la placa base y la versión de UEFI/BIOS. En algunos casos, aparece en la configuración de North Bridge. IOMMU también puede habilitarse al habilitar Intel VT-d o AMD-V. Compruebe la función de reasignación de memoria en UEFI/BIOS.

   Puede verificar si IOMMU está habilitado en un host de Hyper-V con el siguiente comando de PowerShell (ejecútelo como administrador):

   (Get-VMHost).IovSupport; (Get-VMHost).IovSupportReasons

   True = habilitado; Falso = desactivado.

4. Elimine todos los puntos de control de la máquina virtual que usará la asignación directa de GPU.

   Para desactivar los puntos de control automáticos de una máquina virtual, ejecute:

   Set-VM -Name VMName -AutomaticStopAction TurnOff

Asignación directa de GPU en Windows Server

Los siguientes pasos usan DDA para asignar una GPU física a una máquina virtual en Windows Server.

1. Establezca el tipo de caché y los límites del espacio MMIO (E/S asignada a memoria) para la máquina virtual. Ejecute este comando de PowerShell como administrador:

   Set-VM -Name VMName -GuestControlledCacheTypes $True -LowMemoryMappedIoSpace 3Gb -HighMemoryMappedIoSpace 33280Mb

   También puede ejecutar tres comandos separados:

   Set-VM -GuestControlledCacheTypes $true -VMName YourVMName
   Set-VM -LowMemoryMappedIoSpace 3Gb -VMName YourVMName
   Set-VM -HighMemoryMappedIoSpace 33280Mb -VMName YourVMName

   Estos límites definen la ventana de memoria que permite que el dispositivo esté disponible para la máquina virtual. Puede usar una script de perfil de máquina de Microsoft para calcular los valores MMIO óptimos. Los valores correctos varían según el adaptador de vídeo. Si aparece un mensaje que indica que no hay recursos suficientes al iniciar la máquina virtual, apáguela y ajuste estos valores. Se usan 33280 MB para el espacio MMIO por encima de 32 bits (se aplican 3 GB a la ventana MMIO de 32 bits).

2. Identifique la ruta de ubicación PCI Express de la tarjeta gráfica que desea asignar directamente.

   Puede encontrarla en el Administrador de dispositivos. Abra el Administrador de dispositivos ejecutando el siguiente comando:

   Devmgmt.msc

   En el Administrador de dispositivos:

   • Haga clic con el botón derecho en el adaptador de pantalla de destino, en Adaptadores de pantalla, y haga clic en Propiedades .
   • Seleccione la pestaña Detalles .
   • Seleccione Rutas de ubicación en el menú desplegable de propiedades y copie el valor.

   

   También puede usar PowerShell para recuperar la ruta de ubicación:

   Get-PnpDevice | Where-Object {$_.Present -eq $true} | Where-Object {$_.Class -eq "Display"}|select Name,InstanceId

   y:

   Get-PnpDevice -Class Display | ForEach-Object { Write-Output "$($_.FriendlyName) has a device id of $($_.DeviceId) and is located at $($_ | Get-PnpDeviceProperty DEVPKEY_Device_LocationPaths | Select-Object -ExpandProperty Data | Where-Object { $_ -like "PCIROOT*" })"; }

   El resultado debe contener una cadena como esta:

   “PCIROOT(0)#PCI(0300)#PCI(0000)”

   

3. Desactive la tarjeta gráfica en el Administrador de dispositivos. Haga clic con el botón derecho en el adaptador de vídeo y haga clic en Deshabilitar dispositivo .
4. Desmonte el adaptador de pantalla desactivado en PowerShell:

   Dismount-VmHostAssignableDevice -LocationPath "PCIROOT(0)#PCI(0300)#PCI(0000)" -Force

   La marca -Force es necesaria cuando no hay instalado un controlador de partición. El proveedor del dispositivo puede proporcionar este controlador opcional de mitigación de seguridad. Si tiene previsto instalarlo, hágalo antes de desmontar el dispositivo PCIe del host.

   La ruta de ubicación usada anteriormente es solo ilustrativa; reemplácelo por su valor específico.

5. Asigne la tarjeta de vídeo a la máquina virtual:

   Add-VMAssignableDevice -VMName VMName -LocationPath "PCIROOT(0)#PCI(0300)#PCI(0000)"

6. Encienda la máquina virtual y verifique que la tarjeta de vídeo física aparezca en Administrador de dispositivos junto con el adaptador de vídeo predeterminado de Microsoft Hyper-V.
7. Instale los controladores de la tarjeta de vídeo en el sistema operativo invitado de la máquina virtual. Descargue los controladores del sitio web oficial de NVIDIA o AMD.
8. Para desconectar la tarjeta de vídeo de la máquina virtual, detenga la máquina virtual y ejecute:

   Remove-VMAssignableDevice -VMName YourVMName -LocationPath $locationPath

   A continuación, vuelva a conectar la GPU al host de Hyper-V:

   Mount-VMHostAssignableDevice -LocationPath $locationPath

Prueba NAKIVO Backup & Replication para Hyper-V

Empieza tu versión de prueba gratuita de 15 días para realizar backups de Hyper-V sin agentes y coherentes con las aplicaciones, con recuperación completa y granular instantánea y protección integrada contra el ransomware.

Probar gratis

Configuración en Windows 10 y 11

En las versiones de Windows para clientes (Windows 10, compilación 1903 y posteriores, Windows 11), DDA no está disponible. El método compatible es la partición de la GPU:

1. Verifica si tu tarjeta gráfica admite la partición de la GPU. En Windows 10, ejecuta:

   Get-VMPartitionableGpu

   En Windows 11 :

   Get-VMHostPartitionableGpu

2. Utiliza el cmdlet Add-VMGpuPartitionAdapter para asignar una partición de la GPU a la máquina virtual. Sin embargo, debe copiar los controladores de la GPU desde el host de Hyper-V a la máquina virtual. La versión del controlador en el host y en el sistema invitado debe coincidir. El script Easy-GPU-PV puede automatizar este proceso. Descargue el script como archivo ZIP y extráigalo a una carpeta en el host de Hyper-V. Este script aprovecha los mecanismos de paravirtualización de la GPU que utilizan el Subsistema de Windows para Linux (WSL2) y Windows Sandbox.
3. Abre PowerShell como administrador y permite la ejecución del script:

   Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
   Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

4. Apaga la máquina virtual. Ejecuta el script para copiar los controladores de la GPU desde el host a la máquina virtual:

   .\Update-VMGpuPartitionDriver.ps1 -VMName YourVMName -GPUName "AUTO"

5. Configura la máquina virtual para la partición de la GPU:

   Set-VM -VMName VMName -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 1Gb -HighMemoryMappedIoSpace 32Gb
   Add-VMGpuPartitionAdapter -VMName YourVMName

6. Después de actualizar los controladores de la GPU en el host de Hyper-V, actualiza también los controladores de la máquina virtual. La máquina virtual debe estar apagada:

   .\Update-VMGpuPartitionDriver.ps1 -VMName YourVMName -GPUName "AUTO"

7. Para eliminar la partición de la GPU de la máquina virtual:

   Remove-VMGpuPartitionAdapter -VMName "YourVMName"

   Una vez realizada correctamente la configuración, el adaptador de pantalla correspondiente debería aparecer en el Administrador de dispositivos dentro de la máquina virtual. También verás efectos visuales como la transparencia del escritorio en el tema de Windows del sistema invitado.

Ten en cuenta que es posible que algunos juegos y aplicaciones no funcionen incluso después de completar la configuración del paso directo de la GPU. Esto puede ocurrir cuando una aplicación realiza una comprobación de compatibilidad de hardware y la información de la GPU que se muestra en el sistema operativo invitado difiere de la del host. Algunas aplicaciones también detectan que se están ejecutando dentro de una máquina virtual.

Si las aplicaciones que dependen de OpenGL no funcionan en la máquina virtual, puede ser útil instalar el Paquete de compatibilidad con OpenGL .

Al utilizar la partición de la GPU en Windows 10 u 11, el adaptador de vídeo que aparece en el Administrador de dispositivos muestra un controlador de Microsoft en lugar del modelo físico de la GPU. Las herramientas específicas del proveedor, como el Panel de control de NVIDIA, no están disponibles en la máquina virtual.

Puede producirse un problema adicional si se cierra una sesión RDP sin desconectarse primero. En este caso, la máquina virtual puede perder el acceso a la memoria de la GPU, y las aplicaciones que dependen de ella indicarán que la memoria de vídeo es inaccesible. Volver a conectarse a través de RDP no resuelve el problema; debe reiniciar las aplicaciones afectadas.

Solución de problemas de asignación directa de GPU

Si la tarjeta de video no funciona correctamente después de asignarla a una máquina virtual, compruebe lo siguiente:

• Verifique que estén instalados los controladores de GPU más recientes y que no haya errores relacionados con los controladores. Abra el Administrador de dispositivos y compruebe el estado del dispositivo. Instale los controladores desde el sitio web del proveedor (NVIDIA, AMD, Intel) en lugar de confiar en Windows Update.
• Asegúrese de que se haya asignado suficiente espacio MMIO a la máquina virtual.
• Confirme que el proveedor admita oficialmente la asignación directa de GPU para su adaptador gráfico específico. No todas las tarjetas de video de consumo admiten esta función. Algunos proveedores limitan la asignación directa de GPU a los modelos de gama alta.
• Verifique que la aplicación que se ejecuta dentro de la máquina virtual sea compatible con su tarjeta de video y sus controladores.
• Habilite la siguiente directiva de grupo para permitir el uso de la GPU a través del Escritorio remoto:

  Computer ConfigurationTemplatesComponentsDesktop ServicesDesktop Session HostSession Environmenthardware graphics adapters for all Remote Desktop Services sessions

  Establezca este valor en Habilitado .

• Si ve un error como «La operación falló porque no se encontró el objeto» o Error 12 , agregue las siguientes claves del Registro a:

  HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsHyperV

  Valores:

  RequireSecureDeviceAssignment = 0 (REG_DWORD)

  RequireSupportedDeviceAssignment = 0 (REG_DWORD)

  Puede establecer estos valores con PowerShell:

  Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSecureDeviceAssignment" -Type DWORD -Value 0 -Force
  Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\HyperV" -Name "RequireSupportedDeviceAssignment" -Type DWORD -Value 0 -Force

• Para omitir las comprobaciones del controlador del hipervisor dentro de la máquina virtual, use el Kit de controladores de Windows Enterprise (WDK):
  • Monte la imagen ISO del WDK en la unidad de DVD virtual de la máquina virtual.
  • Ejecute E:LaunchBuildEnv.cmd (donde E: es la unidad de DVD virtual) y, a continuación, ejecute PowerShell .
  • Vaya al directorio que contiene el script Remove-HypervisorChecks.ps1 .
  • Ejecute el comando para eliminar las comprobaciones del hipervisor para el controlador de video (ejemplo de NVIDIA):

    ./Remove-HypervisorChecks.ps1 -Nvidia -DriverPath "C:\path-to-driver\package.exe"

  • Espere a que finalice la ejecución del script.
  • Copie el controlador resultante (patched-driver.zip) en la máquina virtual, habilite el modo de prueba e instale el controlador.
• Si se encuentra con el Error 43 , asegúrese de que la GPU y su controlador de sonido (las tarjetas NVIDIA suelen incluir un dispositivo de audio) estén asignados juntos a la máquina virtual.
• Si aparece un error al ejecutar:

  Update-VMGpuPartitionDriver.ps1 -VMName “YourVMName” -GPUName “AUTO”

  Esto puede deberse a que hay varias particiones (volúmenes) en el disco duro virtual. Prueba a establecer el atributo oculto en las particiones que no sean del sistema o a eliminarlas temporalmente después de hacer una copia de seguridad de los datos. Como alternativa, especifica explícitamente la partición del sistema en el script o comando de PowerShell.

Consideraciones sobre backup y recuperación de máquinas virtuales con GPU

Los flujos de trabajo de backup estándar de Hyper-V presuponen que una máquina virtual es portátil: puedes restaurarla en cualquier host compatible y encenderla. Las máquinas virtuales con GPU invalidan esa suposición. Tanto si se asigna mediante DDA como mediante GPU-P, la máquina virtual queda vinculada a hardware físico que podría no existir o no tener la misma configuración en el destino de recuperación. Esto hace que el backup sea sencillo, pero que la recuperación dependa de la disponibilidad del hardware.

La GPU también plantea una cuestión de coherencia de los datos. El software de backup captura el estado del disco, pero no puede crear una instantánea del contenido de la memoria RAM de vídeo de la GPU. En el caso de las máquinas virtuales que ejecutan cargas de trabajo intensivas de GPU, esto significa que el backup refleja una vista sin conexión o consistente en caso de fallo del estado del hardware, incluso cuando los datos del disco son coherentes con la aplicación. Para reducir al mínimo la diferencia, usa puntos de control de producción con Servicio de instantáneas de volumen (VSS) o una herramienta de backup compatible con VSS, que garantiza que los datos vaciados de la memoria de la GPU al disco se capturen en un estado coherente.

La elección entre backups a nivel de host y a nivel de máquina virtual es menos evidente en el caso de las máquinas virtuales con GPU que en el de las estándar:

• El backup a nivel de host captura los archivos VHDX y la configuración de la máquina virtual. Este es el enfoque estándar, pero requiere volver a asignar manualmente la GPU después de la restauración.
• El backup a nivel de invitado requiere que se instale un agente de backup dentro de la máquina virtual. Este enfoque suele ser más práctico para las cargas de trabajo de GPU porque trata la máquina virtual como un servidor estándar y evita la complejidad del paso a través de la GPU durante la captura de datos.

En las configuraciones DDA con paso a través exclusivo, la máquina virtual está vinculada a una ruta PCI Express específica del host. Si restauras una máquina virtual habilitada para DDA en otro host, es probable que no se inicie porque la ruta PCIe original (como PciRoot(0x0)/Pci(0x3,0x0)…) podría no existir o estar asignada a otro dispositivo.

Para resolver una incompatibilidad de hardware después de la recuperación:

1. Quita el dispositivo GPU que falta de la configuración de la máquina virtual.
2. Desmonta una GPU compatible en el nuevo host.
3. Vuelve a asignar la nueva GPU a la máquina virtual restaurada mediante PowerShell.

Con la partición de GPU en Windows Server 2025 y Windows 11, la configuración es más flexible, pero introduce sus propias consideraciones de recuperación. GPU-P requiere que las versiones de los controladores de GPU del host y del invitado coincidan. Si restaura una máquina virtual en un host que ejecuta una versión diferente del controlador, es posible que la aceleración de GPU no se inicialice correctamente.

Durante la recuperación (especialmente en un Clúster de conmutación por recuperación de Hyper-V), el host de destino debe tener suficiente capacidad de partición de GPU disponible. Si la GPU del host ya está completamente particionada entre otras máquinas virtuales en ejecución, la máquina virtual restaurada no se iniciará o recurrirá al renderizado por software.

Windows Server 2025 mejora la movilidad de las máquinas virtuales con GPU. Las máquinas virtuales con GPU-P admiten la migración en vivo en configuraciones agrupadas en clústeres e independientes. En un escenario de conmutación por recuperación, el clúster puede reiniciar la máquina virtual en otro nodo, siempre que haya una GPU compatible configurada para DDA o GPU-P en el destino.

Siga estas recomendaciones para realizar backups y recuperar máquinas virtuales con GPU:

• Documente las rutas PCI y registre los comandos de PowerShell utilizados para asignar la GPU. Disponer de un script listo para usar reduce el tiempo de inactividad durante la restauración en otro host.
• Estandarice el hardware utilizando modelos de GPU y versiones de controladores idénticos en todos los nodos del clúster. Así se garantiza que la máquina virtual restaurada encuentre el mismo entorno de hardware, independientemente del host en el que se inicie.
• Realice pruebas periódicas de restauración de máquinas virtuales con GPU en distintos hosts para verificar que el equipo de recuperación pueda reasignar los dispositivos PCI.
• Cree un script posterior a la restauración que detecte las GPU disponibles y las asigne automáticamente a la máquina virtual restaurada.

Conclusión

Utilizar una máquina virtual con passthrough de GPU en un host Hyper-V puede ser la solución óptima para determinadas cargas de trabajo, pero las limitaciones requieren una planificación cuidadosa. Por lo general, se recomienda utilizar hardware de clase servidor y Windows Server para el passthrough de GPU discretas basado en DDA. Verifique la compatibilidad del software y el hardware antes de iniciar la configuración. Mantenga backups periódicos de las máquinas virtuales de Hyper-V para protegerse contra la pérdida de datos si algo sale mal durante la configuración de la GPU o el funcionamiento continuo.

.

Prueba NAKIVO Backup & Replication

Solicita una versión de prueba gratuita para descubrir todas las funciones de protección de datos de la solución. 15 días gratis. Sin limitaciones de funciones ni de capacidad. No es necesario facilitar un número de tarjeta de crédito.

Probar gratis