NVIDIA vGPU en Proxmox VE: guía completa para compartir una GPU física entre varias máquinas virtuales

X (Twitter) Facebook Pinterest LinkedIn Email WhatsApp

La virtualización de GPU ya es una realidad en entornos on-prem gracias a NVIDIA vGPU Software y Proxmox VE. La propuesta es conocida: una sola GPU física puede dividirse en múltiples vGPU para diferentes máquinas virtuales (MV) sin renunciar a aceleración 3D, cómputo CUDA o codificación de vídeo. Lo que sigue es una guía práctica —y actualizada— sobre qué hace falta (hardware, licencias y versiones), cómo instalar y configurar la solución de extremo a extremo, y qué comprobar para no perder tiempo en incidencias comunes.

Plataforma soportada… con condiciones claras

Desde NVIDIA vGPU Software 18, Proxmox VE figura como plataforma oficialmente soportada. Para poder abrir un ticket de soporte es necesario cumplir dos requisitos en el cluster:

Entitlement válido de NVIDIA vGPU.
Suscripción de Proxmox VE activa (Basic, Standard o Premium).

En cuanto al hardware, la regla de oro es sencilla: comprobar la tarjeta en el Qualified System Catalog de NVIDIA y verificar compatibilidad de servidor y versión. En algunos modelos workstation (por ejemplo, RTX A5000), la función de vGPU existe pero no viene activada por defecto; en estos casos hay que cambiar el modo de display con la herramienta NVIDIA Display Mode Selector, lo que deshabilita los puertos de vídeo de la GPU.

Versiones y alineamiento de stack

Proxmox VE publica combinaciones probadas de pve-manager, kernel, rama vGPU y driver host de NVIDIA. Algunas referencias recientes:

PVE 8.4.1 con kernel 6.8/6.11/6.14 y vGPU 18.3 (driver host 570.158.02).
PVE 9.0.x con kernel 6.14.x y ramas vGPU 18.4 y 19.2 (drivers 570.172.07 y 580.95.02).

Con kernels ≥ 6.8 (GRID ≥ 17.3), es imprescindible tener qemu-server ≥ 8.2.6 en el host, ya que cambió la interfaz de bajo nivel del driver. Además, NVIDIA mantiene una tabla de correspondencia entre versiones de vGPU y drivers que conviene revisar antes de descargar los instaladores.

Desde vGPU 16.0, algunas tarjetas dejan de estar soportadas por vGPU y pasan a NVIDIA AI Enterprise. El procedimiento técnico es similar, pero se trata de productos distintos con licenciamiento diferente y, por ahora, NVIDIA AI Enterprise no figura como soportado oficialmente con Proxmox VE.

Requisitos previos en el host: BIOS/UEFI, repos y helper

1) Habilitar PCIe Passthrough y opciones de firmware

En BIOS/UEFI active:

Intel VT-d o AMD-V / IOMMU.
SR-IOV (obligatorio en GPUs Ampere y posteriores).
Above 4G decoding.
ARI (Alternative Routing ID Interpretation; innecesario para pre-Ampere).

En el kernel, habilite IOMMU para que los grupos PCIe queden bien aislados.

2) Repositorios y actualizaciones

Tenga Proxmox VE al día (repositorio enterprise o no-subscription según el caso). En producción, la recomendación es usar enterprise.

3) pve-nvidia-vgpu-helper

Desde pve-manager ≥ 8.3.4, Proxmox incluye un asistente que ahorra pasos iniciales:

apt install pve-nvidia-vgpu-helper
pve-nvidia-vgpu-helper setup

El asistente añade headers, instala DKMS, y bloquea nouveau. Si nouveau estaba cargado, reinicie el host tras este paso.

Si más adelante instala un kernel opt-in, recuerde instalar el paquete proxmox-headers correspondiente para que DKMS pueda recompilar los módulos.

Instalación del driver vGPU en el host

Descargue el driver host desde el portal de NVIDIA (elija Linux KVM como hipervisor).
Copie el .run al nodo y ejecútelo con DKMS:

chmod +x NVIDIA-Linux-x86_64-525.105.14-vgpu-kvm.run
./NVIDIA-Linux-x86_64-525.105.14-vgpu-kvm.run --dkms

Responda sí a registrar las fuentes con DKMS.
Tras la instalación, reinicie el host.

Secure Boot: con secure boot activo, los módulos deben ir firmados; véase más abajo el apartado Secure Boot.

Activar SR-IOV (Ampere y posteriores)

En GPUs Ampere+ hay que habilitar SR-IOV para que aparezcan funciones virtuales (VF) de la tarjeta. Puede hacerse con el script oficial de NVIDIA o, más cómodo, con el servicio incluido en Proxmox:

systemctl enable --now pve-nvidia-sriov@ALL.service
Lenguaje del código: CSS (css)

Sustituya ALL por un PCI ID concreto (ej. 0000:01:00.0) si quiere aplicarlo sólo a una GPU. Compruebe que existen VFs con:

lspci -d 10de:

Debería ver la tarjeta física (01:00.0) y varias VFs (01:00.4, 01:00.5, …).

Resource Mapping para GPU (opcional, recomendable)

En Datacenter → Resource mappings cree un mapeo que incluya todas las VFs de la GPU y marque Use with mediated devices. Cuando una MV arranque, asignará automáticamente la primera VF disponible del grupo. Facilita la operación y separa privilegios.

Crear la MV y preparar acceso remoto

Cree la MV sin vGPU y con la plantilla habitual (asistente o CLI qm). Importante: la consola web (noVNC/SPICE) no mostrará la salida de la vGPU; es necesario preparar acceso remoto dentro del invitado:

Windows 10/11: active Escritorio remoto (RDP) en Configuración → Sistema → Escritorio remoto.
Linux: emplee VNC; por ejemplo, LightDM + x11vnc (en Rocky Linux puede requerir EPEL y abrir el 5900/tcp en firewalld).

Añadir la vGPU a la MV

Con la MV apagada, asigne una VF de la GPU y el tipo mediado que corresponda.

CLI (ejemplo):

qm set VMID -hostpci0 01:00.4,mdev=nvidia-660
Lenguaje del código: JavaScript (javascript)

Web UI: Hardware → Add → PCI Device, seleccione la VF y el mdev type.
Para listar tipos disponibles en su nodo:

pvesh get /nodes/NOMBRE-NODO/hardware/pci/NOMBRE-MAPEO/mdev
Lenguaje del código: JavaScript (javascript)

La lista depende de la versión de driver y kernel.

Drivers del invitado (Windows y Linux)

Windows 10/11

Descargue el driver GRID compatible con su driver host (consulte la matriz de NVIDIA). Ejecute el instalador (…_grid_win10_win11_….exe) y reinicie. A partir de aquí, entre por RDP: la consola web ya no verá la salida de la vGPU.

Ubuntu / Rocky Linux

Instale el paquete GRID para su distribución:

# Ubuntu (.deb)
apt install ./nvidia-linux-grid-550_550.127.05_amd64.deb

# Rocky (.rpm)
dnf install nvidia-linux-grid-550-550.127.05-1.x86_64.rpm
Lenguaje del código: PHP (php)

Genere la configuración de X.org:

nvidia-xconfig

Reinicie y acceda por VNC. Si usará CUDA, instale el CUDA Toolkit compatible con su versión de driver.

Licenciamiento de la vGPU en el invitado

Cada MV con vGPU debe obtener licencia. NVIDIA ofrece varias opciones, incluido DLS (Delegated License Service). Recomendaciones clave:

Sincronización horaria del invitado vía NTP (si la hora es incorrecta, no solicitará licencia).
Verifique conectividad entre la MV y el servidor de licencias.

Problemas habituales y cómo evitarlos

Windows 10/11 – “Arranque rápido”. Con la opción activa, un apagado híbrido puede terminar en BSOD y vGPU deshabilitada. Solución: desactive Arranque rápido:
Panel de control → Opciones de energía → Elegir la acción de los botones de encendido → Desmarcar “Activar inicio rápido”
o por consola de administrador: powercfg -h off
Advertencia QEMU (AER) al iniciar: vfio ... Could not enable error recovery for the device Suele aparecer en hardware de consumo sin PCIe AER completo. No impacta en uso normal; sólo indica que ciertos errores de enlace podrían no recuperarse por software.
Consola web sin vídeo tras instalar el driver en el invitado. Es normal: el framebuffer lo expone la vGPU, no la VGA emulada del hipervisor. Acceda por RDP/VNC.

Secure Boot: firmar el módulo NVIDIA

Con Secure Boot activo, el kernel sólo carga módulos firmados:

Instale prerequisitos:

apt install shim-signed grub-efi-amd64-signed mokutil

Ejecute el instalador del driver con DKMS pero sin cargar:

./NVIDIA-Linux-x86_64-525.105.14-vgpu-kvm.run --dkms --skip-module-load
Lenguaje del código: JavaScript (javascript)

Responda no a que el instalador firme el módulo.
3) Reconstruya y firme con DKMS (ajuste la versión a la suya):

dkms status
dkms build  -m nvidia -v 550.144.02 --force
dkms install -m nvidia -v 550.144.02 --force
Lenguaje del código: CSS (css)

Enrole la clave MOK en UEFI (se requiere acceso a la consola del servidor para aceptar la importación en el arranque).
Verifique:

lspci -d 10de: -nnk
# Debe mostrar: Kernel driver in use: nvidia
Lenguaje del código: PHP (php)

Lista de comprobación (de 0 a vGPU, sin sobresaltos)

BIOS/UEFI: active IOMMU, SR-IOV (Ampere+), Above 4G y ARI.
Proxmox VE al día y qemu-server ≥ 8.2.6 si el kernel es ≥ 6.8.
Ejecute pve-nvidia-vgpu-helper setup y reinicie si bloqueó nouveau.
Instale el driver host de NVIDIA con --dkms y reinicie.
Habilite SR-IOV (servicio pve-nvidia-sriov@...) y confirme que aparecen VFs.
(Opcional) Cree Resource Mapping con todas las VFs.
Prepare RDP/VNC en el invitado.
Añada la vGPU (VF + mdev type correcto).
Instale el driver guest GRID y, si aplica, CUDA.
Configure licenciamiento (p. ej., DLS) y NTP en el invitado.

Preguntas frecuentes (FAQ)

¿Qué requisitos de licencia y soporte existen para NVIDIA vGPU en Proxmox VE?
Para soporte oficial se requiere un entitlement activo de NVIDIA vGPU y una suscripción válida de Proxmox VE (Basic, Standard o Premium). Cada MV con vGPU necesita licencia de invitado (por ejemplo, usando DLS). Sin licencia, la vGPU puede funcionar con limitaciones.

¿Es obligatorio habilitar SR-IOV para usar vGPU?
En GPUs Ampere y posteriores, sí: debe habilitar SR-IOV para exponer funciones virtuales (VFs). En generaciones previas, vGPU puede funcionar sin SR-IOV. Proxmox incluye el servicio pve-nvidia-sriov@... para automatizarlo en cada arranque.

La consola web de Proxmox no muestra imagen tras instalar el driver del invitado. ¿Es normal?
Sí. La vGPU expone el adaptador gráfico del invitado y la consola integrada (noVNC/SPICE) no puede visualizarlo. Acceda por Escritorio remoto (Windows) o VNC (Linux) para interactuar con la MV.

¿Cómo elijo el modelo de vGPU (mdev) para mi carga de trabajo?
Liste los tipos disponibles con:

pvesh get /nodes/NODO/hardware/pci/NOMBRE-MAPEO/mdev
Lenguaje del código: JavaScript (javascript)

Elija el perfil vGPU que se ajuste a su MV (memoria de vídeo, número de MVs por GPU, uso 3D o cómputo). La visibilidad de modelos depende de la versión del driver host y del kernel.

Conclusión. La dupla NVIDIA vGPU + Proxmox VE permite densificar la GPU física —y amortizarla— repartiendo su potencia entre varias MV. El éxito está en alinear versiones, automatizar SR-IOV, configurar correctamente el invitado (drivers y acceso remoto), y licenciar cada vGPU. Con esa base, la aceleración gráfica y de cómputo deja de ser un recurso exclusivo por servidor y se convierte en un pool bajo control del hipervisor.