La virtualización de GPUs con NVIDIA vGPU sobre VMware vSphere ha dejado de ser un lujo reservado a grandes centros de datos. Hoy, cualquier organización que necesite ejecutar aplicaciones gráficas intensivas, estaciones de trabajo virtuales o cargas de computación acelerada puede beneficiarse de esta tecnología. Sin embargo, implementarla correctamente no es trivial. Requiere un enfoque metódico, una validación minuciosa de cada capa del stack y una comprensión clara de las interdependencias entre hardware, firmware, hipervisor y controladores. En este artículo, exploramos cómo desplegar NVIDIA vGPU en vSphere desde una perspectiva técnica y empresarial, incluyendo recomendaciones para integrar esta infraestructura con servicios modernos como cloud AWS/Azure, inteligencia artificial y Business Intelligence.
Antes de tocar un solo servidor, es imprescindible construir una matriz de compatibilidad que cruce el modelo exacto del servidor, la GPU física, la versión de ESXi, el release de NVIDIA vGPU, el sistema operativo invitado, el perfil seleccionado y el esquema de licenciamiento. Muchos equipos confían en validaciones independientes – la GPU contra NVIDIA, ESXi contra Broadcom – pero el verdadero soporte está en la intersección de todas esas variables. Una combinación no listada en la matriz oficial puede funcionar en laboratorio pero fracasar en producción o quedar fuera de soporte. Por eso, antes de descargar un solo paquete, recomendamos documentar la combinación exacta en una hoja de trabajo de compatibilidad. Esta disciplina, que aplicamos desde Q2BSTUDIO en nuestros proyectos de cloud AWS/Azure, es la base de cualquier despliegue predecible.
El siguiente paso es preparar el firmware del servidor. Habilitar IOMMU (VT-d en Intel, AMD-Vi en AMD) es obligatorio para que el hipervisor pueda mapear correctamente los dispositivos PCI en los espacios de dirección de las máquinas virtuales. En GPUs de generaciones Ampere, Ada o Blackwell, NVIDIA exige además SR-IOV y Alternative Routing-ID Interpretation (ARI). Cada fabricante de servidores denomina estas opciones de forma distinta, pero la mayoría las agrupa bajo menús de virtualización o PCIe. También hay que activar Above 4G Decoding y, en algunos casos, asignar espacio MMIO de 64 bits adicional. Un error frecuente es copiar configuraciones de paso directo (passthrough) a un diseño vGPU; no son intercambiables. La GPU destinada a vGPU no debe ser el adaptador de pantalla primario del host; hay que usar la controladora de gestión (BMC) o un adaptador VGA embebido. Actualizar toda la cadena de firmware – BIOS, BMC, firmware de GPU, firmware de switch PCIe – antes de instalar el software NVIDIA evita sorpresas desagradables. Un ciclo de alimentación completo (power cycle) es necesario tras cambios en PCIe o SR-IOV; un reinicio en caliente no siempre resetea todos los estados.
Con el hardware listo, pasamos al plano del hipervisor. La instalación del vGPU Manager de NVIDIA en ESXi se compone de dos paquetes: el controlador del host y el daemon de gestión de GPUs. Ambos deben copiarse a un datastore accesible y aplicarse con esxcli software vib install. Tras reiniciar, validamos que los módulos del kernel NVIDIA estén cargados (vmkload_mod -l | grep nvidia), que el daemon esté en ejecución (/etc/init.d/nvdGpuMgmtDaemon status) y que nvidia-smi muestre las GPUs físicas con su memoria y temperatura. Si falla aquí, no sirve de nada añadir un perfil a una VM; el problema está en la base. Una vez confirmado, configuramos el modo gráfico del host en Shared Direct desde la interfaz de vSphere. Este modo indica a ESXi que las GPUs expondrán perfiles vGPU directamente a las máquinas virtuales. Si el modo queda en Shared (sin Direct), la VM no podrá encenderse aunque vea la GPU.
Ahora toca preparar la máquina virtual. Elegir el perfil vGPU adecuado es una decisión estratégica. Los perfiles se dividen en series: A (aplicaciones, streaming), B (VDI empresarial) y Q (estaciones de trabajo profesionales con gráficos avanzados). La asignación de framebuffer determina cuántas VMs pueden compartir la GPU física. Recomendamos dimensionar con datos de pilotaje – consumo pico de memoria, uso de codificadores/descodificadores, resolución de pantalla – y no basarse en suposiciones. Empezar con el perfil más grande oculta problemas de densidad; empezar demasiado pequeño provoca fallos por falta de memoria. Además, las cargas de IA no siempre encajan en un perfil Q estándar; NVIDIA AI Enterprise tiene su propio esquema de perfiles y licencias. Aquí, la experiencia de Q2BSTUDIO en automatización de procesos software ayuda a integrar el aprovisionamiento de perfiles en flujos de CI/CD, garantizando que cada workload recibe exactamente los recursos que necesita sin intervención manual.
Antes de añadir el dispositivo PCI a la VM, asegúrese de que dispone de un acceso remoto alternativo (RDP, SSH, consola de gestión). Una vez asignado el perfil vGPU, la consola de vSphere puede quedar inactiva. Con la VM apagada, agregamos un nuevo dispositivo PCI desde Edit Settings y seleccionamos el perfil deseado. No encendemos la VM hasta tener el controlador invitado correcto. El controlador invitado debe ser el específico de NVIDIA vGPU para el release correspondiente; un controlador gráfico genérico no sirve. En Windows, se instala con privilegios administrativos y se verifica en el Administrador de dispositivos. En Linux, se ejecuta el instalador .run y se reinicia. Tras el arranque, nvidia-smi debe mostrar el perfil asignado con su memoria y versión de driver.
El licenciamiento es el talón de Aquiles de muchos despliegues. Un vGPU sin licencia funciona en modo degradado, con prestaciones reducidas. NVIDIA ofrece servicios de licencia en cloud o un servicio delegado local (DLS). El proceso consiste en generar un token de configuración desde el portal de licencias, copiarlo al directorio adecuado del invitado (en Windows, %ProgramFiles%\NVIDIA Corporation\vGPU Licensing\ClientConfigToken; en Linux, /etc/nvidia/ClientConfigToken/) y reiniciar el servicio nvidia-gridd. Luego, dentro del invitado, nvidia-smi -q muestra el estado de licencia. No confíe en la validación a nivel de host; la licencia se verifica dentro de la VM. En entornos donde la gestión de licencias se integra con paneles de BI, Q2BSTUDIO puede ayudar a diseñar cuadros de mando Power BI que monitoricen el estado de licencias, el uso de memoria y las tendencias de rendimiento de cada VM vGPU, facilitando la toma de decisiones de capacidad.
La validación no termina con la VM encendida. Hay que probar la migración en vivo (vMotion) antes de confiar en ella en producción. NVIDIA vGPU soporta vMotion siempre que el destino tenga el mismo tipo de GPU física, mismo perfil, misma configuración de ECC y misma versión del vGPU Manager. Es necesario activar el ajuste avanzado vgpu.hotmigrate.enabled en vCenter. Recomendamos hacer una migración controlada con una VM piloto, midiendo el tiempo de interrupción (stun time) y verificando que la aplicación se recupera correctamente. No asuma que el modo mantenimiento de un host evacuará automáticamente las VMs vGPU; en algunos casos requiere migración manual o apagado programado. Definir dos caminos: uno preferente (vMotion a un host compatible) y otro de contingencia (apagado ordenado y migración en frío). Esta planificación es clave en entornos de cloud híbrido donde la infraestructura on-premise se integra con servicios AWS o Azure para burst de capacidad.
El orden de actualización es crítico. La regla de oro: actualice primero el vGPU Manager del host y luego los controladores invitados. Un manager más reciente puede soportar controladores invitados de ramas anteriores definidas; lo contrario no está soportado. Si se salta este orden, las VMs pueden no arrancar o perder funcionalidad. Para entornos VCF, el vGPU Manager forma parte de la imagen de ESXi; cualquier actualización del SDDC Manager debe tener en cuenta la compatibilidad con la rama NVIDIA seleccionada. Q2BSTUDIO recomienda mantener un repositorio de paquetes de las versiones anteriores aprobadas, tanto del host como del invitado, para facilitar un rollback rápido si la actualización falla.
La resolución de problemas requiere un enfoque estructurado. Si no aparecen perfiles vGPU, compruebe el modo gráfico del host, que el daemon esté activo y que la GPU sea compatible. Si la VM reporta recursos insuficientes, verifique la capacidad disponible en el host y el modo gráfico. Si nvidia-smi falla en el invitado, el controlador instalado no es el correcto o hay incompatibilidad entre versiones de host e invitado. Si el rendimiento es bajo, revise el estado de licencia. Los logs principales son: vmkernel.log en ESXi, vmware.log de la VM, y los logs del servicio nvidia-gridd en el invitado. Capture el error exacto antes de reiniciar; perderá la evidencia del fallo.
Finalmente, documente todo: modelo de servidor y firmware, GPU física, versiones de ESXi y vCenter, release de vGPU Manager, controladores invitados, perfiles asignados, token de licencia, resultados de validación, tiempo de stun en vMotion, y procedimiento de rollback. El equipo de operaciones debe poder responder tres preguntas sin tener que redescubrir el entorno: ¿qué perfil puede usar este workload? ¿qué hosts pueden ejecutar o recibir esta VM? ¿qué combinaciones de controladores host e invitado están soportadas? Solo así se garantiza un despliegue sostenible.
En Q2BSTUDIO, entendemos que la tecnología vGPU es un habilitador estratégico para la transformación digital. Ya sea integrando esta infraestructura con soluciones de inteligencia artificial para entrenar modelos, o conectándola a plataformas de Business Intelligence para visualizar datos en tiempo real, nuestro equipo de desarrollo de software a medida puede acompañarle en cada paso. La clave está en la disciplina de validación, la automatización de procesos y la documentación rigurosa. Implementar NVIDIA vGPU no es un proyecto de un fin de semana; es una inversión que, bien gestionada, transforma la capacidad de su organización para ejecutar cargas de trabajo gráficas, de IA y de visualización con la agilidad que exige el mercado actual.
