Passthrough PCIe en Proxmox vs ESXi: GPUs, HBAs, NICs — qué es más fácil y qué es más rápido

La conclusión breve: qué elegir

Si buscas “más predecible para un homelab promedio y muchas PYMEs”

Proxmox suele ser más fácil de entender porque es Linux de punta a punta. Puedes ver cada perilla: grupos IOMMU, vinculación de controladores, enrutamiento de interrupciones, peculiaridades de reset. Cuando falla, falla en voz alta, y puedes inspeccionar el host como un equipo Linux normal.

Si vas a pasar HBAs para ZFS, Proxmox resulta especialmente cómodo: ZFS en el host más passthrough para la VM es tema de debate, pero Proxmox te da ambos patrones con menos momentos de “caja negra”.

Si buscas “guardarraíles empresariales y ciclo de vida predecible”

ESXi es la historia corporativa más limpia: listas de compatibilidad de dispositivos, un plano de gestión estable y patrones operativos que escalan con equipos. Para passthrough en particular, ESXi es excelente cuando tu hardware está en la senda esperada y tus requisitos coinciden con lo que VMware espera.

Cuando te sales de la senda—GPUs de consumo, comportamientos raros de reset, NICs de nicho—ESXi se convierte en un portero cortés: no te pelea, simplemente no te deja entrar.

GPUs

• Facilidad: Proxmox suele ganar para passthrough DIY de GPU. ESXi es bueno si estás dentro de GPUs soportadas / modos soportados (y en cuanto a licencias si usas vGPU).
• Velocidad: casi nativo en ambos cuando está bien configurado. Tu cuello de botella probablemente será el escalonado de CPU, la topología PCIe o la gestión de energía/controladores más que el hipervisor.

HBAs (controladoras SAS/SATA)

• Facilidad: Proxmox gana si tu objetivo es “darle a la VM la HBA entera y que corra ZFS/TrueNAS”. ESXi está bien, pero pasarás más tiempo en compatibilidad y en “¿está esto permitido?”.
• Velocidad: el passthrough es efectivamente nativo, pero la historia real de rendimiento es profundidad de colas, moderación de interrupciones y comportamiento de firmware/controlador.

NICs (10/25/40/100G, SR-IOV, cargas tipo DPDK)

• Facilidad: empate, dependiendo del objetivo. ESXi tiene flujos SR-IOV maduros; Proxmox tiene herramientas Linux y menos restricciones de producto.
• Velocidad: SR-IOV o passthrough total pueden ser excelentes en ambos. Para redes VM generales, a menudo las NICs paravirtuales (vmxnet3/virtio-net) son “lo suficientemente rápidas” y operativamente más amables.

Verdad seca y graciosa: el passthrough te da rendimiento nativo más problemas nativos.

Hechos interesantes y breve historia (útil, no para trivias)

1. Intel VT-d y AMD-Vi (IOMMU) son lo que hacen posible un aislamiento DMA serio. Antes de eso, el “passthrough” era una ruleta de seguridad y estabilidad.
2. VFIO (Virtual Function I/O) se volvió el enfoque Linux predominante porque separa limpiamente el acceso al dispositivo del espacio de usuario (QEMU) y se apoya en el IOMMU para seguridad.
3. El remapeo de interrupciones es muy importante para corrección y seguridad. Sin él, algunas plataformas no pueden virtualizar MSI/MSI-X de forma segura a escala.
4. SR-IOV (Single Root I/O Virtualization) fue creado para evitar la asignación completa de dispositivos dividiendo una NIC en “funciones virtuales” con aislamiento aplicado por hardware.
5. Los bugs de reset de GPU no son folclore. Algunas GPUs no implementan un reset a nivel de función (FLR) correcto, por eso “funciona tras ciclo de energía” es una categoría real de incidente.
6. ACS (Access Control Services) afecta los grupos IOMMU. Las placas de consumo frecuentemente agrupan ranuras, obligándote a pasar más de lo deseado—o a usar un ACS override con compromisos.
7. NVMe fue diseñado para colas profundas y baja latencia. Virtualizarlo mal se ve como “funciona” hasta que pones una base de datos y ves p99 raro.
8. VMware DirectPath I/O lleva años y es maduro, pero es intencionalmente conservador: prioriza soportabilidad y comportamiento predecible sobre “déjame hackearlo”.
9. vMotion y passthrough siempre han tenido una relación incómoda. No puedes migrar en vivo una VM que posee un dispositivo físico, salvo que uses tecnologías específicas de mediación/compartición.

Cómo funciona el passthrough (y dónde falla)

Los dispositivos PCIe hacen dos cosas que importan aquí: exponen espacio de configuración (registros, capacidades) y realizan DMA en la memoria del sistema. El passthrough significa que el SO invitado obtiene acceso directo al dispositivo, y el hipervisor se aparta en gran medida—excepto que aún debe mantener el host a salvo.

Los tres pilares: IOMMU, aislamiento y resets

• IOMMU mapea el DMA del dispositivo a la memoria del invitado. Sin él, un dispositivo asignado a una VM podría hacer DMA en el kernel del host y garabatear la realidad.
• El aislamiento depende de los grupos IOMMU. Si dos dispositivos comparten el mismo grupo, a menudo no puedes asignar solo uno con seguridad (porque potencialmente pueden hacer DMA entre sí o compartir peculiaridades de traducción upstream).
• El comportamiento de reset importa. Cuando una VM reinicia, el dispositivo debe volver a un estado limpio. Si el dispositivo no puede resetearse (o la plataforma no lo hace), obtendrás problemas de “funciona una vez”.

Ruta Proxmox: VFIO + QEMU + controladores Linux

En Proxmox, típicamente:

1. Habilitas IOMMU en firmware y en la línea de comandos del kernel.
2. Enlazas el dispositivo PCIe objetivo a vfio-pci (no a su controlador normal del host).
3. Agregas líneas hostpci al config de la VM, controlando opcionalmente ROM bar, MSI y otras peculiaridades.
4. Dejas que el controlador del invitado tome el dispositivo.

La ventaja: puedes ver todo y cambiarlo. La desventaja: puedes ver todo y cambiarlo. Ahora eres el equipo de integración.

Ruta ESXi: DirectPath I/O bajo reglas vSphere

En ESXi, tú:

1. Habilitas IOMMU en firmware.
2. Marcas el dispositivo para passthrough en la configuración del host.
3. Reinicias el host (a menudo requerido para volver a enlazar el dispositivo).
4. Agregas el dispositivo a una VM, aceptando restricciones como la falta de vMotion.

ESXi es menos “ajustable” pero más “con guardarraíles”. Cuando rechaza una configuración, por lo general es porque no puede garantizar soportabilidad o seguridad en esa plataforma.

Dónde se rompe en la vida real

• Mal agrupamiento IOMMU (común en placas de consumo): no puedes aislar una GPU de su función de audio o de un controlador USB detrás del mismo puente upstream.
• Fallos de reset: el dispositivo no vuelve tras apagar la VM; el host lo ve pero el controlador del invitado agota tiempos; solo un reinicio del host lo arregla.
• Tormentas de interrupciones o picos de latencia: pasaste un dispositivo de alto IOPS y ahora la CPU 0 está sufriendo porque las interrupciones están mal distribuidas.
• Desajuste firmware/controlador: la BIOS del host es vieja; el firmware del HBA es antiguo; el controlador del invitado espera otra cosa; ahora tienes una historia de fantasmas en almacenamiento.

Una cita, porque encaja con la vida ops: La esperanza no es una estrategia. — James R. Schlesinger

Broma #1: Si tu GPU solo se resetea tras reiniciar el host, felicitaciones—has inventado “alta disponibilidad por paciencia”.

Qué es más fácil: Proxmox vs ESXi por tipo de dispositivo

Passthrough de GPU

Proxmox es más fácil cuando estás fuera de las vías empresariales de GPU. Puedes pasar casi cualquier GPU PCIe si puedes aislarla, enlazarla a VFIO y lidiar con peculiaridades de reset. Existe lore comunitario porque los problemas son comunes y reproducibles.

ESXi es más fácil cuando tu GPU está soportada y tu flujo de trabajo encaja con las expectativas de VMware. Si necesitas vGPU (GPU en tiempo compartido, varias VMs compartiendo una GPU), el ecosistema de ESXi históricamente es más fuerte, pero ahí empiezan a importar licencias y habilitación por parte del proveedor.

Realidad práctica: la parte más difícil rara vez es “hacer clic en passthrough”. Es mantener comportamiento estable entre reinicios, actualizaciones de controladores y eventos de energía. Proxmox te da más palancas. ESXi te da menos, pero más seguras.

Passthrough de HBA (HBAs SAS, tarjetas RAID en modo IT)

Si haces ingeniería de almacenamiento, ya conoces la regla: el firmware RAID miente. Si quieres ZFS o cualquier stack que espere visibilidad directa de discos, quieres una HBA en modo IT (o una HBA real) y que la VM la posea.

Proxmox hace que esto sea natural: enlaza la HBA a VFIO, pásala, deja que TrueNAS/OmniOS/Linux vea los discos, gestione SMART y haga su trabajo. Aún puedes mantener dispositivos de arranque y gestión en el host.

ESXi también está bien, pero pasarás más tiempo asegurando que el controlador y el firmware estén en una combinación soportada y que el host no intente hacer cosas inteligentes. En organizaciones grandes, esto es una ventaja: menos rarezas.

Passthrough de NIC: dispositivo completo vs SR-IOV vs paravirtual

Para muchas cargas, no necesitas passthrough completo de NIC. virtio-net (Proxmox) y vmxnet3 (ESXi) son excelentes. También preservan migración y hacen la vida operativa más calmada.

Cuando lo necesitas—NFV, latencia ultra-baja, tasas de paquetes altas, o una VM que actúa como firewall/ruteador a 25/100G—entonces decides entre:

• Passthrough completo: concepto más simple, pero mata la movilidad y puede complicar la red del host.
• VFs SR-IOV: mejor compromiso para muchos diseños; mantienes cierto control en el host y puedes mapear varias VMs a un puerto físico.
• Stacks DPDK/en espacio de usuario: a menudo van con passthrough o SR-IOV; el rendimiento puede ser excelente, pero heredas un problema de afinamiento.

El ganador en facilidad depende del equipo: los equipos centrados en Linux encuentran SR-IOV y el afinamiento de IRQ en Proxmox directos; los equipos centrados en VMware encuentran más sencillo operacionalizar los flujos y la consistencia de ESXi.

Qué es más rápido: realidad de rendimiento por carga

Rendimiento GPU: usualmente casi nativo, hasta que no

Cuando una GPU está pasada correctamente, te acercas al metal desnudo en throughput bruto. Las pérdidas de rendimiento suelen venir de:

• Planificación de CPU: tus vCPUs no están ancladas, el host está sobrecommitido o hilos sensibles a latencia rebotan entre núcleos.
• Desajustes NUMA: GPU en un socket, memoria de la VM en otro. Las penalizaciones de ancho de banda y latencia pueden ser agudas.
• Gestión de energía: ASPM agresivo o estados C pueden hacer la latencia irregular (depende de la plataforma).

Proxmox te da acceso directo a herramientas Linux para anclaje NUMA y hugepages; ESXi también tiene controles maduros de CPU/memoria, pero el “por qué va más lento” a veces es menos transparente.

Passthrough de HBA: el hipervisor rara vez es el cuello de botella

Para HBAs, el passthrough es básicamente “conectar el dispositivo al invitado”. Los problemas de rendimiento casi siempre se rastrean a:

• Modo de firmware incorrecto (IR/RAID en lugar de IT/HBA).
• Desajustes de profundidad de colas y moderación de interrupciones.
• Comportamiento de discos (SMR, gestión de energía, temporizadores de recuperación de errores).

Ambos hipervisores pueden ofrecer rendimiento cercano al nativo. La diferencia es operativa: Proxmox facilita correlacionar logs del host, errores PCIe y mensajes del kernel. ESXi mantiene el entorno consistente pero puede ocultar detalles de bajo nivel detrás de abstracciones.

Rendimiento NIC: lo paravirtual es subestimado

A 10G, tanto virtio-net como vmxnet3 son generalmente excelentes. A 25/100G, comienzas a preocuparte por:

• Offloads (TSO/GSO/GRO/LRO) y si tu carga se beneficia.
• Distribución de IRQ y colas RSS.
• Overhead del vSwitch frente a colas hardware directas.

El passthrough completo y SR-IOV pueden reducir overhead, pero también reducen tu capacidad de migración en vivo y políticas centralizadas. Si tu objetivo principal es “rápido”, el passthrough puede ganar. Si tu objetivo es “rápido y sensato”, lo paravirtual a menudo gana.

Broma #2: La NIC más rápida es la que no depuras a las 3 a.m.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las cosas que realmente ejecuto cuando una construcción de passthrough huele extraño. Cada tarea incluye: un comando, salida realista, qué significa y la decisión que tomas.

1) Confirmar que IOMMU está habilitado (host Proxmox/Linux)

cr0x@server:~$ dmesg | grep -E "DMAR|IOMMU|AMD-Vi" | head
[    0.812345] DMAR: IOMMU enabled
[    0.812901] DMAR: Intel(R) Virtualization Technology for Directed I/O
[    0.813210] DMAR: Interrupt remapping enabled

Significado: IOMMU y remapeo de interrupciones están activos. Esa es la base para un passthrough seguro.

Decisión: Si no ves esto, detente. Arregla las opciones del BIOS (VT-d/AMD-Vi) y la línea de comandos del kernel antes de tocar configuraciones de VM.

2) Verificar que la línea de comandos del kernel incluya flags IOMMU (Proxmox)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.12-4-pve root=/dev/mapper/pve-root ro quiet intel_iommu=on iommu=pt

Significado: intel_iommu=on habilita VT-d; iommu=pt usa modo passthrough para dispositivos del host y reduce overhead.

Decisión: Si falta, actualiza GRUB y reinicia. No “lo intentes igualmente”. Perderás horas.

3) Mapear el dispositivo que quieres pasar (ID PCI)

cr0x@server:~$ lspci -nn | egrep -i "vga|3d|ethernet|sas|raid|nvme"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)
05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] (rev 02)

Significado: Tienes tres candidatos clásicos para passthrough: GPU (más su función de audio), una HBA y una NIC 10GbE.

Decisión: Anota las direcciones BDF (01:00.0, 03:00.0, 05:00.0). Las usarás en la configuración de la VM o en los pasos de vinculación.

4) Comprobar grupos IOMMU (¿puedes aislar el dispositivo?)

cr0x@server:~$ for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename $g):"; ls -1 $g/devices/; done | sed -n '1,20p'
Group 0:
0000:00:00.0
Group 1:
0000:00:01.0
0000:01:00.0
0000:01:00.1
Group 2:
0000:00:03.0
0000:03:00.0
Group 3:
0000:05:00.0

Significado: Las funciones GPU 01:00.0 y 01:00.1 están juntas (bien), la HBA está aislada, la NIC está aislada. Esto es lo que deseas.

Decisión: Si tu GPU comparte grupo con dispositivos aleatorios, o mueves ranuras, cambias ajustes BIOS “PCIe ACS” o aceptas un ACS override (con compromisos de seguridad/aislamiento).

5) Confirmar qué controlador posee actualmente el dispositivo (antes de enlazar VFIO)

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: mpt3sas
	Kernel modules: mpt3sas

Significado: El host está usando actualmente el controlador HBA. Si lo pasas, el host debe soltarlo.

Decisión: Si el host usa esto para su propio almacenamiento, no procedas. Arranca el host desde otra cosa primero (mirrored SATADOM, NVMe separado, etc.).

6) Enlazar un dispositivo a vfio-pci (Proxmox/Linux)

cr0x@server:~$ echo "options vfio-pci ids=1000:0087,10de:2204,10de:1aef" | sudo tee /etc/modprobe.d/vfio.conf
options vfio-pci ids=1000:0087,10de:2204,10de:1aef

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.12-4-pve

Significado: Le has dicho al host que vincule esos IDs PCI a VFIO al arrancar.

Decisión: Reinicia el host durante una ventana de mantenimiento. El hot-rebinding es posible, pero la gente de producción prefiere repetibilidad aburrida.

7) Verificar que vfio-pci está en uso

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI Device 0087
	Kernel driver in use: vfio-pci
	Kernel modules: mpt3sas

Significado: El driver del host está desprendido; VFIO posee el dispositivo. Este es el estado que quieres para passthrough.

Decisión: Si sigue en el driver nativo, tienes un problema de initramfs u orden de módulos. Arregla eso antes de tocar configs de VM.

8) Agregar passthrough a un config de VM Proxmox (hostpci)

cr0x@server:~$ sudo qm set 120 --hostpci0 01:00,pcie=1 --hostpci1 03:00,pcie=1
update VM 120: -hostpci0 01:00,pcie=1 -hostpci1 03:00,pcie=1

Significado: La VM 120 recibirá la GPU (ambas funciones cuando especificas 01:00) y la HBA.

Decisión: Si necesitas el audio de la GPU también y Proxmox no lo detecta implícitamente, pasa ambas funciones explícitamente. Luego arranca la VM y verifica la detección en el invitado.

9) Comprobar que QEMU arranca con los dispositivos adjuntos (Proxmox)

cr0x@server:~$ sudo journalctl -u pvedaemon -n 20 | tail
Dec 28 10:12:41 server pvedaemon[2123]:  starting task UPID:server:00003A1B:0002C2F9:676FFB29:qmstart:120:root@pam:
Dec 28 10:12:43 server pvedaemon[2123]: VM 120 started with pid 14592

Significado: La VM arrancó. Esto no prueba que el dispositivo se inicializó, pero descarta una negativa inmediata de QEMU.

Decisión: Si la VM no arranca, inspecciona la salida de la tarea por errores VFIO/IOMMU y ve directo a comprobaciones de aislamiento de grupo y vinculación de drivers.

10) En el invitado, confirmar que la GPU/HBA es visible (invitado Linux)

cr0x@server:~$ lspci -nn | egrep -i "vga|sas|scsi"
00:10.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
00:11.0 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
00:12.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0087] (rev 02)

Significado: La VM ve el hardware real. Ahora la batalla es controladores y estabilidad, no la conexión.

Decisión: Si falta, probablemente pasaste el BDF equivocado, el dispositivo sigue ligado al driver del host, o el tipo de máquina/ajuste PCIe de la VM es incorrecto.

11) Buscar errores PCIe/AER en el host (estabilidad de enlace)

cr0x@server:~$ dmesg | egrep -i "aer|pcie bus error|vfio|DMAR" | tail -n 8
[  912.344120] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
[  912.344141] pcieport 0000:00:01.0: AER: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[  912.344148] pcieport 0000:00:01.0: AER:   device [8086:1901] error status/mask=00000001/00002000
[  912.344152] pcieport 0000:00:01.0: AER:    [ 0] RxErr

Significado: Los errores corregidos ocurren, pero ráfagas frecuentes pueden correlacionarse con cuelgues de GPU, caídas de NIC o rarezas NVMe. Puede ser integridad de señal, risers, alimentación o BIOS.

Decisión: Si ves errores corregidos repetidos bajo carga, revisa cableado/risers, vuelve a asentar tarjetas, actualiza BIOS y considera forzar la velocidad PCIe una generación abajo para estabilidad.

12) Comprobar distribución de interrupciones (host) para una NIC/HBA pasada

cr0x@server:~$ cat /proc/interrupts | egrep -i "vfio|ixgbe|i40e|mpt3sas" | head
  55:   182934   0   0   0  IR-PCI-MSI  524288-edge      vfio-pci
  56:   176211   0   0   0  IR-PCI-MSI  524289-edge      vfio-pci

Significado: Las interrupciones aterrizan solo en CPU0 (la primera columna). Eso puede estar bien a bajas tasas, pero es una razón clásica de picos de latencia.

Decisión: Si la latencia p99 importa, configura balanceo/anquilado de IRQ para que se distribuyan entre núcleos alineados con la localidad NUMA.

13) Medir latencia de almacenamiento dentro del invitado (chequeo rápido)

cr0x@server:~$ iostat -x 1 3
Linux 6.6.15 (vm-storage) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await  r_await  w_await  svctm  %util
sda            120.0   250.0    6.0    18.0      96.0     3.20    8.50     4.10    10.60   0.70  25.2

Significado: await es la latencia promedio en ms. Si esperabas comportamiento NVMe y ves 8–15ms, algo upstream está mal (dispositivo, discos, encolamiento, modo del controlador).

Decisión: Si la latencia es alta, verifica que la HBA esté en modo IT, revisa los discos e inspecciona errores PCIe del host. No culpes primero al hipervisor.

14) ESXi: comprobar si un dispositivo es elegible para passthrough (tarea de paridad conceptual)

cr0x@server:~$ esxcli hardware pci list | egrep -n "0000:03:00.0|Passthru" -A2
214:0000:03:00.0
215:   Class Name: Serial Attached SCSI controller
216:   Passthru Capable: true

Significado: ESXi reconoce el dispositivo y dice que puede pasarlo.

Decisión: Si Passthru Capable es false, detente y revisa soporte de plataforma/BIOS/IOMMU y si ESXi tiene soporte/quirks para ese dispositivo.

Guion de diagnóstico rápido: encuentra el cuello de botella sin adivinar

Este es el “entra a la sala de guerra y sé útil en 10 minutos”. Está ordenado. No te saltes pasos porque te aburras.

Primero: verifica conexión y aislamiento

1. ¿Está IOMMU habilitado? (dmesg/cmdline o ajustes del host ESXi). Si no, nada más importa.
2. ¿Está el dispositivo aislado en su grupo IOMMU? Si no, espera inestabilidad o rechazo de inicio.
3. ¿Está el dispositivo ligado al driver correcto? Proxmox: vfio-pci. ESXi: marcado para passthrough y requiere reinicio.

Segundo: verifica comportamiento de reset y ciclo de vida

1. Arranque en frío del host → iniciar VM → detener VM → iniciar VM de nuevo. Repite una vez.
2. Si falla en el segundo inicio, sospecha limitaciones de FLR/reset. Esto es muy común en GPUs.
3. Revisa logs del host por errores de reset VFIO o problemas de reentrenamiento de enlace PCIe.

Tercero: revisa las realidades de hardware aburridas

1. Errores PCIe (AER) en dmesg o logs ESXi. Errores corregidos en ráfagas son un olor a problema.
2. Térmicas y alimentación: GPU + HBA + NIC en un chasis pueden provocar transientes de potencia.
3. Alineación de firmware: BIOS, VBIOS de GPU, firmware HBA. Firmware antiguo causa dolor nuevo.

Cuarto: mide en el invitado con la lente correcta

1. GPU: revisa clocks y utilización, no solo FPS. Si los clocks se throttlean, no es el hipervisor.
2. Almacenamiento: mira latencia (iostat -x) y profundidades de cola, no solo throughput.
3. Red: mira pérdidas de paquetes, CPU de IRQ y distribución RSS, no solo números de iperf.

Quinto: solo entonces afina

1. Anclaje NUMA y hugepages para latencia consistente.
2. Balanceo/anquilado de IRQ para estabilidad de NIC/HBA bajo carga.
3. Deshabilitar estados de energía agresivos si la variación de latencia te mata.

Errores comunes (síntoma → causa raíz → solución)

1) La VM no arranca tras agregar hostpci

Síntoma: Tarea de Proxmox falla; QEMU se queja de VFIO o “group not viable”.

Causa raíz: El dispositivo comparte un grupo IOMMU con otro dispositivo en uso, o IOMMU no está habilitado.

Solución: Habilita VT-d/AMD-Vi, verifica dmesg; mueve la tarjeta a otra ranura; evita ACS override a menos que aceptes el compromiso de aislamiento.

2) La GPU funciona una vez, luego pantalla negra al reiniciar la VM

Síntoma: Primer arranque bien; después de apagar/reiniciar, el controlador del invitado cuelga o el dispositivo desaparece.

Causa raíz: La GPU carece de soporte fiable de FLR/reset; el host no puede resetear la función limpiamente.

Solución: Prueba otro modelo de GPU; usa vendor-reset cuando sea aplicable; prefiere GPUs de servidor/workstation para uptime; planifica reinicio del host como recuperación (y documéntalo).

3) El rendimiento de almacenamiento es “aceptable” hasta la carga de la base de datos, luego p99 explota

Síntoma: Los benchmarks se ven bien; la carga real tiene picos de latencia y timeouts.

Causa raíz: HBA en modo RAID/IR, desajuste de colas, o interrupciones ancladas a un core; a veces discos SMR haciendo lo suyo.

Solución: Asegura modo IT; ajusta profundidades de cola; distribuye interrupciones; valida modelos de disco y comportamiento de escritura.

4) VM con passthrough de NIC tiene gran throughput pero pérdida aleatoria de paquetes

Síntoma: iperf muestra línea completa; tráfico real tiene pérdidas y retransmisiones.

Causa raíz: Desequilibrio de IRQ, mala configuración RSS, buffers de anillo muy pequeños, o errores PCIe bajo carga.

Solución: Revisa interrupciones, ajusta parámetros del driver en el invitado, verifica estabilidad del enlace (AER) y alinea NUMA (NIC cerca de CPU/memoria usada).

5) Dispositivo en passthrough en ESXi aparece como “no capaz” aunque el hardware lo soporte

Síntoma: ESXi rechaza el dispositivo para DirectPath I/O.

Causa raíz: IOMMU en BIOS deshabilitado, bug en firmware de la plataforma o dispositivo/controlador no en la ruta soportada que ESXi espera.

Solución: Habilita IOMMU en BIOS, actualiza BIOS, valida soporte del dispositivo y considera usar SR-IOV/paravirtual en vez de un dispositivo raro.

6) Pasaste una HBA… y ahora el almacenamiento del host desapareció

Síntoma: El host a veces arranca; tras cambios, disco root faltante o pool ZFS no encontrado.

Causa raíz: Pasaste el controlador que aloja tus dispositivos de arranque o datos. Autogol clásico.

Solución: Separa el almacenamiento de arranque del passthrough. Trátalo como un requisito de diseño estricto, no una sugerencia.

Tres micro-historias corporativas (anonimizadas, plausibles, dolorosamente familiares)

Incidente causado por una suposición equivocada: “Los grupos IOMMU son por ranura, ¿no?”

El equipo heredó un pequeño cluster que había crecido orgánicamente: un par de servidores de muchos núcleos, NICs mezcladas y un nodo “especial” con GPU para experimentos ML. El plan era simple: mover una segunda GPU a una ranura vacía, pasarlas a VMs separadas y dejar que el equipo de data science se autosirviera.

Hicieron la configuración en Proxmox con cuidado—VFIO binding, entradas hostpci, incluso documentaron qué VM tenía qué tarjeta. La primera GPU funcionó. La segunda… funcionó, pero solo cuando la primera VM estaba apagada. Cuando ambas estaban encendidas, una VM se congelaba bajo carga y la otra registraba errores PCIe.

La suposición equivocada fue sutil: asumieron que la placa madre aislaba cada ranura en su propio grupo IOMMU. En realidad, dos ranuras compartían el mismo puente PCIe upstream sin separación ACS, y la plataforma agrupó múltiples dispositivos juntos. La “ranura vacía” no era operativamente independiente. Solo estaba físicamente vacía.

La solución no fue un parámetro de kernel ingenioso. Movieron una GPU a una ranura en un complejo raíz distinto, actualizaron BIOS y aceptaron que la topología de la placa—no el hipervisor—era la restricción real. La nota post-incidente fue corta y directa: “La topología PCIe es un dato de diseño, no un detalle.”

Optimización que salió mal: “Forcemos rendimiento máximo en todas partes”

Una tienda tipo fintech tenía servicios sensibles a latencia y la costumbre de tunear. Movieron una VM appliance de red a Proxmox y le dieron VFs SR-IOV para alcanzar tasas de paquetes que no lograban con solo virtio-net. Funcionó. Así que aplicaron rituales de rendimiento: desactivar estados C de CPU, poner el gobernador en performance y subir la coalescencia de interrupciones de la NIC para reducir overhead.

El throughput mejoró en papel. El uso de CPU bajó. Todos aplaudieron. Luego la latencia tail orientada al cliente empeoró, intermitente, y solo durante ciertos patrones de tráfico. Tomó tiempo ver la correlación: ráfagas pesadas causaban micro-rafagas dentro de la VM appliance, y los nuevos ajustes de coalescencia convirtieron “muchas interrupciones pequeñas y puntuales” en “pocas interrupciones gruesas”.

Peor aún, desactivar estados C cambió el comportamiento térmico. Los ventiladores fluctuaron y un host empezó a registrar errores PCIe corregidos bajo carga sostenida. Nada se cayó, pero el sistema vivía más cerca del borde. La “optimización” gastó múltiples pequeños colchones de seguridad.

El rollback fue aburrido: volver a coalescencia por defecto, mantener ajustes de energía razonables y solo anclar CPU/tunear IRQs donde la medición lo justificara. Mantuvieron SR-IOV porque resolvió el problema central, pero dejaron de intentar engañar al hardware sin un objetivo p99 claro. Lección: tunear sin un modelo de latencia es cargo cult con mejor vocabulario.

Práctica aburrida pero correcta que salvó el día: “Hicimos una prueba de reinicio”

Una empresa de medios corría VMs de transcodificación aceleradas por GPU en ESXi. Tenían una ventana de cambios para parches: firmware del host, actualizaciones ESXi y controladores invitados. El entorno había sido estable, así que la tentación fue hacer los updates y listo.

En cambio, su líder de ops insistió en una “prueba de ciclo de vida de reinicio” para un host: parchearlo, luego ciclar cada VM con start/stop/start dos veces y hacer un reinicio completo del host entre pases. Pareció excesivo. También consumió tiempo que no querían gastar.

En el segundo reinicio de VM después del parche, un dispositivo GPU falló al inicializarse. No ocurría siempre. No aparecía en pruebas de humo básicas. Pero era real, y el modo de fallo era exactamente el que se vuelve un incidente a las 2 a.m. cuando un host se reinicia inesperadamente.

Como lo atraparon en staging, pudieron revertir la combinación de controladores y programar una actualización de firmware soportada por el proveedor más tarde. Sin drama. Sin impacto al cliente. Solo una invitación de calendario y un runbook arreglado. La práctica aburrida—probar comportamiento de ciclo de vida, no solo primer arranque—marcó la diferencia entre “retraso menor” y “gran caída”.

Listas de verificación / plan paso a paso

Lista de diseño (antes de tocar archivos de configuración)

• Define lo no negociable: ¿necesitas migración en vivo, reinicio HA, snapshots, o es una “VM mascota” atada a un host?
• Elige estrategia de dispositivo: passthrough completo vs SR-IOV vs paravirtual. Por defecto, paravirtual salvo que puedas nombrar el cuello de botella.
• Valida topología: ¿a qué socket CPU está conectada la ranura? ¿Qué grupo IOMMU? No adivines.
• Separa arranque de dispositivos en passthrough: el host debe arrancar y ser gestionable sin el controlador pasado.
• Documenta recuperación de reset: ¿qué haces cuando el dispositivo no se reinicializa? ¿Reinicio del host? ¿Ciclo de energía? ¿Detach/reattach scriptado?

Proxmox paso a paso (línea base pragmática)

1. Habilita VT-d/AMD-Vi en BIOS/UEFI. Activa “Above 4G decoding” si usas GPUs/NVMe con BARs grandes.
2. Agrega parámetros de kernel (intel_iommu=on o amd_iommu=on, más iommu=pt), reinicia.
3. Revisa grupos IOMMU; reubica tarjetas si es necesario.
4. Vincula dispositivos a vfio-pci vía /etc/modprobe.d/vfio.conf, actualiza initramfs, reinicia.
5. Agrega entradas hostpci a la VM; usa pcie=1 para dispositivos modernos.
6. Arranca el invitado, instala controladores del proveedor, valida estabilidad en varios ciclos start/stop.
7. Solo entonces: anclaje NUMA, hugepages y afinamiento de IRQ si tienes objetivos de latencia medidos.

ESXi paso a paso (línea base operativa segura)

1. Habilita IOMMU en BIOS/UEFI.
2. Confirma que el dispositivo se ve y es “passthru capable”.
3. Marca el dispositivo para passthrough en la configuración del host; reinicia el host.
4. Agrega el dispositivo a la VM; acepta que vMotion típicamente queda fuera de juego.
5. Valida controladores del invitado y comportamiento de ciclo de vida (start/stop/reboot loops).
6. Si necesitas movilidad, evalúa SR-IOV (para NIC) o opciones mediadas/vGPU (para GPU) dentro de tus restricciones de soporte.

Lista operativa (lo que pones en el runbook)

• Cómo confirmar que el dispositivo está adjunto (comandos host e invitado).
• Cómo recuperar de fallo de reset (pasos exactos, requisitos de ventana de mantenimiento).
• Cómo parchear de forma segura (orden: firmware, hipervisor, controladores invitados; bucles de validación).
• Qué logs recoger para escalado (dmesg/AER del host, logs de VM, logs de controladores del invitado).
• Qué características quedan deshabilitadas (migración, snapshots, suspend/resume), para que nadie se sorprenda después.

Preguntas frecuentes

1) ¿El passthrough PCIe es “más rápido” que virtio/vmxnet3?

A veces. Para tasas altas de paquetes, latencia baja o offloads especializados, passthrough/SR-IOV puede ganar. Para cargas generales, los dispositivos paravirtuales suelen estar a distancia de golpe y son mucho más fáciles de operar.

2) ¿Por qué mi passthrough de GPU funciona en el primer arranque pero falla tras reiniciar la VM?

Comportamiento de reset. Algunas GPUs no implementan FLR fiable, o la plataforma no puede resetear el dispositivo limpiamente. Terminas necesitando reiniciar el host o ciclo de energía para recuperar.

3) ¿Debería pasar una HBA a una VM TrueNAS/ZFS?

Si quieres que la VM tenga propiedad directa de los discos con visibilidad completa (SMART, manejo de errores), sí—passthrough de HBA es un diseño común y sensato. Solo asegúrate de que el host no dependa de esa HBA para arranque o almacenamiento de gestión.

4) ¿Es seguro el ACS override en Proxmox?

Pueda hacer que las cosas “funcionen” dividiendo grupos IOMMU, pero no es aislamiento mágico. Estás intercambiando garantías de seguridad por flexibilidad. En producción, prefiere hardware que te dé grupos limpios sin overrides.

5) ¿Puedo migrar en vivo una VM que usa passthrough?

Generalmente, no. El passthrough completo ata la VM al host físico. Algunas aproximaciones mediadas (SR-IOV, vGPU) pueden restaurar movilidad parcial, pero vienen con restricciones de plataforma.

6) ¿Cuál es la trampa de rendimiento más grande con passthrough?

NUMA e interrupciones. Un NIC/HBA/GPU pasado puede ser “rápido” pero entregar latencia tail terrible si las interrupciones y la localidad de memoria están mal.

7) ¿Necesito hugepages para passthrough de GPU?

No estrictamente. Hugepages pueden reducir la presión de TLB y mejorar la consistencia para algunas cargas, pero también añaden restricciones de asignación. Úsalas cuando tengas beneficios medidos o patrones de carga conocidos.

8) Para NICs, ¿debo preferir SR-IOV sobre passthrough completo?

A menudo sí. SR-IOV da rendimiento cercano al passthrough mientras deja al host controlar la función física. Pero añade complejidad operativa (ciclo de vida de VFs, matching de drivers, postura de seguridad).

9) ¿Por qué ESXi dice que mi dispositivo no es passthrough-capable?

Lo más común: IOMMU deshabilitado en BIOS, firmware desactualizado o el dispositivo no está en la ruta soportada que ESXi espera. ESXi es conservador; rechaza configuraciones que no puede respaldar.

10) ¿Cuál es “más fácil” en general para un host mixto GPU + HBA + NIC en passthrough?

Proxmox es más fácil si quieres trastear y depurar a nivel kernel Linux. ESXi es más fácil si quieres guardarraíles y tu hardware es mainstream y soportado.

Conclusión: siguientes pasos que funcionan

Si estás eligiendo una plataforma para passthrough PCIe, no empieces por la ideología. Empieza por tu presupuesto de fallos y tus necesidades de migración.

• Si necesitas movilidad y operaciones de flota, por defecto usa dispositivos paravirtuales, y usa passthrough solo donde importe mediblemente. ESXi suele brillar aquí.
• Si necesitas control máximo del dispositivo y estás cómodo viviendo en logs del kernel y topología PCIe, Proxmox es una gran opción—especialmente para trasteo con GPU y passthrough de HBA.
• Elijas lo que elijas, trata el passthrough como un proyecto de integración de hardware: valida agrupamiento IOMMU, comportamiento de reset y estabilidad de ciclo de vida antes de prometer nada a stakeholders.

Paso práctico siguiente: elige una carga objetivo, construye un host único y ejecuta el bucle de prueba de ciclo de vida (start/stop/reboot dos veces) antes de escalar. Ese ejercicio aburrido previene las sorpresas más caras.