Passthrough de GPU (vDGA) en VMware: guía completa

Conectar directamente una GPU física a una máquina virtual en VMware es uno de esos cambios que marcan la diferencia cuando trabajas con cargas gráficas pesadas, IA o renderizado 3D. Pasar de una gráfica emulada a un acceso directo mediante passthrough (vDGA / VMDirectPath I/O) puede acercar el rendimiento de la VM al de un equipo físico, pero a cambio añade bastantes requisitos y limitaciones que conviene tener muy claros antes de lanzarse.

Además, en el ecosistema actual conviven varias formas de usar la GPU en entornos virtualizados: passthrough dedicado, vGPU compartida y tecnologías tipo BitFusion o GPU partitioning. Entender qué hace cada una, en qué casos encaja y cómo se configura en vSphere/ESXi (y cómo se relaciona con tecnologías similares como Hyper-V DDA) es clave para no meterse en un callejón sin salida con el hardware o la versión de hipervisor elegida.

Qué es el passthrough de GPU (vDGA / VMDirectPath I/O) en VMware

El passthrough de GPU en VMware, también conocido como vDGA o VMDirectPath I/O, es un modo de funcionamiento en el que una tarjeta gráfica física instalada en el host ESXi se asigna directamente a una máquina virtual. En lugar de usar un adaptador gráfico emulado por el hipervisor, el sistema operativo invitado ve la GPU casi como si estuviera pinchada en una placa base física.

Este acceso directo hace que la VM pueda aprovechar toda la potencia del chip gráfico, su memoria de vídeo y funciones avanzadas como CUDA, OpenCL, Direct3D u OpenGL de forma nativa, con muy poca sobrecarga añadida por el hipervisor. En pruebas de laboratorio de VMware se suele hablar de una pérdida de rendimiento de alrededor de un 4-5 % respecto a ejecutar la misma GPU en bare metal.

En la práctica, utilizar passthrough de GPU significa que esa tarjeta queda completamente dedicada a una única máquina virtual. No hay reparto fino de recursos entre varias VMs ni capa de software de terceros cargada en ESXi para compartir la tarjeta, a diferencia de lo que ocurre con soluciones de vGPU como NVIDIA GRID.

Conviene distinguir este enfoque de otras modalidades de uso de GPU en virtualización, como NVIDIA vGPU (vGPU compartida), RemoteFX/partitioning en Hyper‑V o soluciones tipo BitFusion, que buscan repartir una GPU o un pool de GPUs entre múltiples máquinas con distintas técnicas de virtualización o redirección remota.

Cuando se habla de vDGA en el mundo VMware, en esencia se está describiendo esta asignación directa del dispositivo PCIe de la GPU a la VM usando VMDirectPath I/O, con todo lo bueno (rendimiento) y lo malo (restricciones de movilidad y alta disponibilidad) que ello implica.

Ventajas de usar passthrough de GPU en vSphere

La razón principal para dar el salto a vDGA es que el rendimiento gráfico y de cómputo se acerca muchísimo al de un equipo físico. Al omitir buena parte de la capa de virtualización para ese dispositivo PCIe, los cuellos de botella típicos de la GPU emulada desaparecen y la VM puede trabajar con juegos, aplicaciones 3D o motores de IA de forma mucho más fluida.

Esto se nota especialmente en escenarios donde las GPU integradas o la tarjeta virtual emulada por defecto se quedan muy cortas: diseño gráfico avanzado, CAD, modelado y render 3D, edición de vídeo, animación y game development. También es crítico en entrenamientos de modelos de machine learning y cargas de IA que tiran mucho de CUDA o equivalentes.

Otra ventaja clara es el uso más flexible del hardware a nivel de centro de datos. En lugar de tener un workstation físico por usuario o por proyecto, es posible dedicar un host ESXi bien dimensionado a varias VMs, cada una con su propia GPU en passthrough, y jugar con horarios o picos de demanda.

En determinados entornos, sobre todo si ya se cuenta con servidores con ranuras PCIe libres, el coste por usuario o por proyecto puede ser menor que mantener un parque de estaciones físicas potentes, sobre todo si la gráfica no se necesita las 24 horas y se puede reconfigurar según épocas de trabajo intenso.

Por último, también hay un beneficio indirecto en materia de seguridad y operativa: al mantener las cargas de trabajo gráficas dentro de máquinas virtuales aisladas, si algo sale mal (un exploit, un controlador problemático, una mala configuración) es más fácil contener el impacto, revertir a un snapshot previo o restaurar desde copia de seguridad, siempre que se respeten las limitaciones propias del passthrough que veremos más adelante.

Passthrough de GPU frente a vGPU y otras alternativas

Dentro del ecosistema VMware hay varias formas de aprovechar una tarjeta gráfica y no todas pasan por dedicarla entera a una sola VM. Las más conocidas son vDGA / VMDirectPath I/O, vGPU (NVIDIA GRID u otros) y soluciones de acceso remoto/computación como BitFusion.

En el modo de passthrough directo (vDGA), la GPU se asigna en exclusiva a una máquina virtual. No se comparten los núcleos de cómputo ni la VRAM entre varias VMs, y el hipervisor prácticamente no interviene más allá de enrutar el dispositivo PCIe hacia el invitado. Es la opción más sencilla de entender y la que más se parece a un servidor físico con una gráfica dedicada.

En el enfoque de vGPU, un software especializado (por ejemplo NVIDIA GRID vGPU sobre VMware vSphere) se encarga de virtualizar la GPU a nivel de controlador y exponer instancias virtuales de la misma que se pueden asignar a varias VMs al mismo tiempo. Cada máquina invitada ve un “trozo” de GPU con recursos garantizados o compartidos.

Las vGPU permiten que múltiples escritorios virtuales o servidores compartan una sola tarjeta, algo muy útil en VDI, entornos de ofimática con aceleración ligera, puestos gráficos de front‑line en retail u hostelería, o escenarios donde el pico de uso gráfico es disparejo entre usuarios. A cambio, hay cierta sobrecarga y no se consigue el mismo rendimiento pico que con una GPU física entera dedicándose a una sola VM.

También existen soluciones como BitFusion Flexdirect y tecnologías similares, que permiten consumir GPUs a través de la red desde distintas VMs, ideal para cargas de IA y HPC donde la GPU actúa más como un recurso de cómputo remoto que como una tarjeta de vídeo para la interfaz gráfica del usuario.

Elegir entre vDGA, vGPU o un modelo de GPU remota depende de si necesitas exprimir a fondo una GPU para una sola máquina (passthrough), si quieres repartir una tarjeta cara entre muchos usuarios con cargas medias (vGPU) o si lo clave es orquestar un pool de GPUs para cómputo distribuido (BitFusion y similares).

Requisitos de hardware para usar vDGA en ESXi

Antes de planear un despliegue de passthrough de GPU en VMware, hay que asegurarse de que la plataforma de hardware cumple una serie de condiciones que van más allá de “tener una gráfica pinchada en el servidor”.

En primer lugar, el procesador y el chipset de la placa base del host ESXi deben soportar virtualización con IOMMU. En Intel esto pasa por Intel VT‑x más VT‑d y en AMD por AMD‑V con IOMMU. En la BIOS/UEFI del servidor suele haber opciones concretas para activar las extensiones de virtualización de E/S.

En segundo lugar hay que revisar que la placa soporte mapeo de memoria MMIO por encima de 4 GB (a veces etiquetado como “Above 4G decoding”, “memory mapped I/O above 4G” o similar). Esto es especialmente importante con GPUs de gama alta como Tesla, P100, V100 y equivalentes, que declaran regiones de memoria muy grandes en sus BAR (Base Address Registers).

Algunas de estas tarjetas de gama alta pueden mapear más de 16 GB de espacio MMIO, por lo que, además de tocar la BIOS, luego habrá que ajustar ciertos parámetros en la configuración avanzada de la VM en vSphere para que pueda arrancar con esa GPU sin errores de recursos insuficientes.

Por supuesto, la GPU en sí debe ser compatible con la plataforma de servidor y estar soportada por el fabricante del host (Dell, HPE, Lenovo, etc.) cuando se usa en modo passthrough. En la práctica, la mayoría de GPUs PCIe modernas funcionan, pero conviene revisar listas de compatibilidad, especialmente si se trata de tarjetas GRID o modelos muy nuevos.

Requisitos de software y compatibilidad de versiones

A nivel de software, es importante tener claro que VMware sí soporta vDGA en vSphere 6.x y versiones posteriores, aunque algunos usuarios han reportado problemas concretos con determinadas combinaciones de hardware (por ejemplo, GPUs NVIDIA GRID en servidores Dell R720 con ESXi 6.x).

En estos casos, es habitual ver errores del tipo “device is already in use” o síntomas que hacen pensar que el passthrough ha dejado de funcionar al actualizar de ESXi 5.5 a 6.x, cuando en realidad se trata de bugs específicos, cambios en la gestión de dispositivos PCI o en los controladores, más que de una retirada oficial del soporte.

El sistema operativo invitado que vaya a usar la GPU en passthrough debe contar con controladores oficiales del fabricante instalados dentro de la VM (NVIDIA, AMD, Intel), ya que ESXi no carga ningún driver específico para esa tarjeta al usar VMDirectPath I/O; el hipervisor se limita a exponer el dispositivo al invitado.

Además, la VM debe estar configurada para arrancar en modo EFI o UEFI cuando se emplean GPUs que declaran grandes regiones de memoria MMIO. Este detalle es crítico: un firmware de VM incorrecto puede dar lugar a fallos de arranque o a que la GPU no se inicialice correctamente desde el sistema operativo invitado.

En el lado del cliente, si el acceso a la VM se produce mediante escritorio remoto (RDP u otros protocolos), habrá que activar las políticas adecuadas para que el sistema invitado use el adaptador gráfico de hardware en las sesiones remotas y no se quede anclado a un driver genérico sin aceleración.

Configuración del host ESXi para usar GPU en modo passthrough

El primer paso práctico es preparar el servidor vSphere/ESXi para exponer la GPU como dispositivo de DirectPath I/O. Esto implica tocar la BIOS, revisar el inventario de PCI en el host y marcar la tarjeta para que pueda asignarse a VMs.

Si la GPU necesita grandes regiones de memoria MMIO (16 GB o más), hay que buscar en la BIOS/UEFI del servidor opciones del tipo “Above 4G decoding” o “PCI 64‑bit resource handling above 4G” y activarlas. El nombre concreto varía según el fabricante, pero suele encontrarse en el apartado de configuración de PCI o de recursos avanzados.

Una vez arrancado ESXi con esos ajustes, en el cliente de vSphere se puede ir al host correspondiente y acceder a “Configure → Hardware → PCI Devices → Edit” para ver la lista de dispositivos PCI detectados. Ahí aparecerán las tarjetas NVIDIA, AMD o similares junto al resto de hardware PCI del servidor.

Si la GPU todavía no está habilitada para DirectPath I/O, bastará con marcar la casilla de passthrough en su entrada dentro de esa lista. Al guardar los cambios, vSphere solicitará reiniciar el host para aplicar la configuración, ya que el hipervisor debe reservar y preparar el dispositivo para ser reasignado a VMs.

Tras el reinicio, al volver a la sección “Configure → Hardware → PCI Devices” se mostrará una ventana titulada algo parecido a “DirectPath I/O PCI Devices Available to VMs”, donde se listan todos los dispositivos que han quedado disponibles para su uso en máquinas virtuales, incluyendo las GPUs y, en muchos casos, adaptadores de red avanzados tipo Mellanox.

Preparación y configuración de la máquina virtual

Con el host preparado, el siguiente paso es crear o adaptar la máquina virtual que va a utilizar la GPU. Lo primero es asegurarse de que la VM se ha creado con un firmware EFI/UEFI adecuado, sobre todo en escenarios con GPUs de gama alta y MMIO elevado.

En el cliente de vSphere, basta con seleccionar la VM, ir a “Edit Settings → VM Options → Boot Options” y verificar que en el campo “Firmware” está escogido “EFI” o “UEFI”. Si no lo está, habrá que cambiarlo (y en algunos casos recrear la VM o el sistema operativo si no soporta este cambio en caliente).

Cuando se usa passthrough con tarjetas que mapean más de 16 GB de espacio MMIO, conviene ajustar unos parámetros avanzados en la configuración de la VM, accesibles desde “Edit Settings → VM Options → Advanced → Configuration Parameters → Edit Configuration”. Ahí se pueden añadir claves relacionadas con pciPassthru para controlar cómo se reserva el espacio de direcciones.

Concretamente, se suele activar el uso de MMIO de 64 bits y se define un tamaño para esa región, calculado a partir de cuántas GPUs de gama alta se van a asignar a la VM. La regla de la casa suele ser multiplicar 16 por el número de GPUs y redondear el resultado a la siguiente potencia de dos (por ejemplo, dos GPUs de este tipo acabarían en 64 GB de MMIO de 64 bits).

Tras ajustar estos parámetros, se instala o se comprueba que el sistema operativo invitado soporta EFI/UEFI y es capaz de manejar el tamaño de memoria y la GPU en cuestión. A estas alturas todavía no se ha conectado la gráfica a la VM, simplemente se está preparando el entorno para que, cuando se haga, todo arranque sin errores por falta de recursos o firmware incompatible.

Asignar la GPU a la VM mediante VMDirectPath I/O

Una vez que el host tiene marcada la GPU como disponible para DirectPath I/O y que la VM está configurada correctamente, llega el momento de asociar físicamente la tarjeta a esa máquina virtual. Este paso debe hacerse con la VM completamente apagada.

Desde el cliente de vSphere se selecciona la VM y se entra en “Edit Settings” para revisar el hardware virtual. En la lista de dispositivos se puede pulsar “Add New Device” y elegir “PCI Device” si la GPU todavía no aparece. A continuación, se selecciona el dispositivo PCI correspondiente a la gráfica (por ejemplo, la NVIDIA o la AMD detectada en el host).

Cuando se guarda la configuración, la VM mostrará en su hardware algo como “PCI Device 0” asociado a la GPU concreta. Desde este momento, al arrancar el sistema operativo invitado, este verá un adaptador PCIe adicional correspondiente a la tarjeta gráfica física.

Es fundamental que la máquina virtual tenga reservada toda la memoria que se le ha asignado. En vSphere, esto se configura en “Edit Settings → Virtual Hardware → Memory”, estableciendo en el apartado de “Reservation” un valor igual a la RAM configurada para la VM. Sin esa reserva completa, el passthrough de PCI puede fallar o dar problemas intermitentes.

Tras encender la VM, en un sistema Linux se puede comprobar la presencia de la GPU con comandos tipo lspci | grep nvidia, mientras que en Windows aparecerá bajo “Adaptadores de pantalla” en el Administrador de dispositivos. Lo normal es ver tanto el adaptador gráfico emulado de VMware como la GPU física dedicada.

El último paso es instalar dentro del invitado los drivers oficiales del fabricante de la GPU, descargados desde las webs de NVIDIA, AMD o Intel, evitando confiar en drivers genéricos o en los que suministra Windows Update, que pueden no estar optimizados para escenarios de passthrough.

Limitaciones y funcionalidades de vSphere que no funcionan con vDGA

La cara B del passthrough de GPU en VMware es que se pierden varias funcionalidades avanzadas de la plataforma al dedicar un dispositivo físico directamente a una VM. Es el precio a pagar por ese rendimiento casi nativo.

La primera gran renuncia es vMotion y DRS. Una máquina virtual con una GPU en passthrough no puede migrarse en caliente a otro host, porque la tarjeta está físicamente anclada al servidor original. Tampoco se pueden usar políticas automáticas de distribución de carga que impliquen mover la VM entre hosts del clúster.

Tampoco están disponibles características como Snapshots tradicionales o ciertos mecanismos de alta disponibilidad para esa VM concreta. Al depender de un hardware físico muy particular, la capacidad de congelar y restaurar estados complejos se ve comprometida.

Otro aspecto a tener en cuenta es que, en este modo, la GPU no se comparte entre varias VMs. Si se necesitan varios escritorios o servidores con aceleración gráfica sobre la misma máquina, hará falta una tarjeta por VM o, alternativamente, pasar a un modelo de vGPU donde la tarjeta se virtualiza en varias instancias.

En el lado del soporte, puede haber casos específicos en los que determinadas combinaciones de hardware y drivers den problemas, como algunos usuarios han observado al actualizar a ESXi 6.x con tarjetas NVIDIA GRID en servidores concretos (por ejemplo, Dell R720). En esos escenarios es recomendable revisar documentación de VMware y del fabricante de la GPU, así como abrir casos de soporte si es necesario.

Por último, hay que tener presente que ciertas tecnologías o servicios que interactúan con gráficos, como escritorios remotos, subsistemas de Linux en Windows o funciones avanzadas del sistema operativo, pueden interferir o provocar errores de tipo “Code 43” en drivers NVIDIA si detectan que se está trabajando dentro de una VM con GPU en passthrough.

Passthrough de GPU en otros hipervisores: paralelo con Hyper‑V

Aunque el foco aquí está en VMware, merece la pena entender cómo otros hipervisores (por ejemplo virtualización con KVM y virt‑manager) abordan la misma necesidad de asignar una GPU física a una VM, ya que la terminología y las herramientas cambian, pero la idea de fondo es parecida.

En Hyper‑V, el equivalente de VMware VMDirectPath I/O es la asignación directa de dispositivos mediante DDA (Discrete Device Assignment). Esta técnica permite mapear un dispositivo PCIe concreto, como una GPU o un NVMe, directamente dentro de una máquina virtual Windows, con un nivel de control y rendimiento similar al del passthrough en ESXi.

En versiones antiguas de Windows Server se usaba la tecnología RemoteFX para ofrecer virtualización de GPU y compartir una tarjeta entre varias VMs. Con el tiempo, debido a problemas de seguridad y limitaciones de rendimiento (como el tope de 1 GB de VRAM por VM y 30 FPS), Microsoft retiró RemoteFX y dejó como camino principal DDA para escenarios de GPU dedicada.

En Windows 10 y Windows 11, especialmente a partir de ciertas compilaciones, ha ido apareciendo soporte para GPU partitioning y mecanismos reutilizados desde WSL2 y Windows Sandbox, aunque su configuración suele implicar scripts complejos y copiar drivers desde el host al invitado, algo que no es tan directo como asignar un dispositivo en vSphere.

Conocer estas alternativas permite ver que la filosofía de ofrecer un acceso casi nativo a la GPU mediante un canal PCIe directo es común a varios hipervisores, aunque cada uno tenga sus propios matices, comandos y restricciones de compatibilidad.

Todo este ecosistema de passthrough, vGPU y DDA demuestra que, bien configurado y con el hardware correcto, es perfectamente viable usar GPUs potentes dentro de máquinas virtuales para producción para cargas que van desde escritorios gráficos exigentes hasta IA y HPC, siempre asumiendo que habrá que renunciar a ciertas comodidades de la virtualización tradicional y estar muy atento a drivers, versiones de hipervisor y soporte del fabricante de la GPU.