¿Alguien ha probado virtualizar un router pfSense en Proxmox con PCI passthrough de NICs reales? ¿Merece la pena vs bridges?

Ski

Llevo un tiempo con mi homelab en Proxmox y siempre he usado bridges para las VMs de red (pfSense, OPNsense). Pero he leído por ahí que algunos hacen PCI passthrough de NICs físicas directamente a la VM del firewall para 'mejor rendimiento y aislamiento'.

La teoría suena bien: la VM maneja el hardware directamente, sin overhead del hypervisor. Pero me da miedo perder flexibilidad (migrar la VM, snapshots) y que sea un lío de configuración.

Mi duda concreta: ¿Realmente se nota la diferencia en rendimiento (sobre todo latencia y throughput) en un escenario doméstico/SoHo con conexión de 1 Gbps? ¿O es más un tema de 'porque se puede'?

Si alguien lo ha hecho, ¿qué trampas encontraste en la configuración de IOMMU, grupos de dispositivos, etc.?

Calligraphy

Yo lo hice hace un año con una Intel i350-T4. La configuración no es trivial, tienes que habilitar IOMMU en el kernel, aislar los dispositivos, y asegurarte de que el grupo de IOMMU de la NIC no incluye otros dispositivos críticos (como un controlador SATA).

En cuanto a rendimiento, con iperf3 entre dos clientes en LANs distintas pasando por el pfSense virtualizado, el passthrough me daba unos 950 Mbps constantes, mientras que con virtio en un bridge linux se quedaba en unos 880-900 Mbps con picos de CPU un pelín más altos. Para 1 Gbps, la diferencia es marginal. Donde noté mejora fue en la consistencia de la latencia (ping), menos microvariaciones.

El mayor inconveniente: olvídate de snapshots y backups online de esa VM. Y migrar en caliente, imposible.

Drones

Discrepo un poco en el enfoque. Para un escenario doméstico, el passthrough es overkill y te ata las manos. La virtualización de red en Proxmox (con bridges y virtio) está hiperoptimizada. El cuello de botella casi nunca es el hypervisor, sino las reglas de firewall, inspección de estados, o paquetes pequeños.

Lo que sí recomiendo es usar vmxnet3 o virtio con las opciones multiqueue activadas y asignar más de un vCPU a la VM. Con eso saturas 1 Gbps sin problemas y mantienes toda la flexibilidad de la virtualización.

El passthrough tiene sentido si tienes NICs de 10 Gbps o más, o necesitas un aislamiento de seguridad extremo (que en un homelab...).

Ski

Gracias por los datos concretos de throughput. Esa diferencia del 5-8% coincide con lo que había leído en algún benchmark. Lo de la latencia más estable es interesante, sobre todo si haces VoIP o gaming.

La parte de perder snapshots y migración es un palo importante. Ahora mismo puedo mover la VM de un nodo a otro sin cortar el servicio (tengo dos nodos en cluster). Con passthrough, sería un corte seguro.

¿Alguien ha tenido problemas con updates de Proxmox o del kernel rompiendo la configuración de IOMMU/IDs de PCI? Eso es otro miedo.

Meditation

Respondiendo a tu última pregunta: SÍ, me ha pasado. Un update de Proxmox 7 a 7.1 (creo recordar) cambió el orden de enumeración PCI y mi VM no arrancaba porque el dispositivo PCI que le pasaba ya no existía en la misma dirección. Tuve que editar manualmente el .conf de la VM desde la shell. No es frecuente, pero pasa.

Mi recomendación: si quieres probar, hazlo en un segundo disco o en una instalación de prueba. No lo hagas en tu producción un viernes por la tarde. Otra opción intermedia es usar SR-IOV si tu NIC lo soporta (las Intel i350 sí). Creas VFs (Virtual Functions) y se las pasas a la VM. Es más elegante y flexible que el passthrough completo.

# Ejemplo para crear 2 VFs en una i350 lspci | grep Ethernet # Anotar ID echo '2' > /sys/bus/pci/devices/0000:02:00.0/sriov_numvfs

AI

Un apunte que no han mencionado: el passthrough de PCI te obliga a tener una IP de gestión para Proxmox en una NIC separada. Si pasas todas las NICs físicas a la VM, tu hypervisor se queda sin red (a menos que uses una IP en una VLAN manejada por la VM, pero es un lío).

Yo empecé con passthrough y al final volví a bridges por pura comodidad. El rendimiento, como dicen, es casi idéntico para 1 Gbps. El tiempo que perdí configurando y depurando el IOMMU no valió la pena por ganar 50 Mbps en un test sintético.

Ahora uso bridges VLAN-aware y le paso los tags a la VM. Una maravilla. Puedo tener el firewall y varios servicios en VMs distintas compartiendo el mismo uplink físico con total aislamiento.

Ski

El punto de la IP de gestión es clave, sí. Yo tengo una placa base con 2 NICs, así que una la usaría para Proxmox y la otra para el passthrough. Pero vuestra experiencia me convence: para mi caso (1 Gbps, sin cargas extremas) no vale la pena el dolor de cabeza.

Lo de SR-IOV suena interesante, pero mi NIC (una Realtek común) probablemente no lo soporte. Me quedo con la configuración actual de bridges VLAN-aware y virtio multiqueue. Al menos por ahora.

Gracias a todos por compartir vuestra experiencia, me habéis ahorrado un fin de semana de frustración.

Hiking

Un último consejo: si quieres exprimir al máximo la configuración con bridges, activa vmxnet3 en lugar de virtio para la VM de pfSense (requiere que instales los drivers de VMware en la VM, hay un paquete). En algunos tests da un pelín mejor rendimiento de CPU, sobre todo con interrupciones. Y en la configuración del bridge de Proxmox, asegúrate de tener txqueuelen alto y desactivar offloading si ves checksum errors.

# En el host Proxmox, para la interfaz del bridge ifconfig vmbr0 txqueuelen 10000 ethtool -K vmbr0 tx off sg off tso off gso off

Con esos tweaks, tienes un 99% del rendimiento del passthrough con el 100% de la flexibilidad.

Metal

Coincido con el último mensaje sobre los tweaks de bridges, pero añadiría que vmxnet3 puede ser contraproducente si no tienes una infraestructura VMware homogénea. En Proxmox, virtio con multiqueue suele ser más estable y recibe mejor soporte en pfSense. Respecto al offloading, desactivarlo es clave para evitar problemas de checksum en bridges VLAN-aware, pero también afecta el rendimiento de CPU en tráfico pesado; recomiendo probar primero con offloading activo y solo desactivar si aparecen errores.

En cuanto al debate passthrough vs bridges, para la mayoría de usuarios domésticos o pequeñas oficinas con 1 Gbps, los bridges con optimizaciones como txqueuelen 10000 son más que suficientes. El passthrough solo justifica su complejidad si necesitas aislamiento absoluto de hardware o estás manejando 10 Gbps+ con cargas intensivas de paquetes pequeños. La flexibilidad de los bridges para compartir NICs entre múltiples VMs es un punto ganador indiscutible.

Plants

El debate sobre passthrough vs bridges está bien enfocado, pero me gustaría matizar un punto: la estabilidad de vmxnet3 en Proxmox no es tan problemática si se usan los drivers oficiales de VMware, aunque sí requiere más mantenimiento. Para pfSense, prefiero virtio multiqueue por su integración nativa y menor overhead de configuración. Sobre el offloading, desactivarlo preventivamente puede ser excesivo; monitorear con herramientas como netstat o tcpdump para detectar checksum errors antes de ajustar es más eficiente. En cuanto al rendimiento, en pruebas con iperf3 en un entorno de 1 Gbps, la diferencia entre bridges optimizados y passthrough fue marginal (<2% en throughput), pero el passthrough mostró menor latencia en cargas de paquetes pequeños. Aún así, para la mayoría de casos, los bridges con txqueuelen alto son la opción más práctica.