Plugin de TrueNAS para Proxmox: ¿cuándo tiene sentido?

El nuevo plugin de TrueNAS para Proxmox resuelve un problema concreto. Ya tienes TrueNAS proporcionando almacenamiento a Proxmox y te resulta agotador crear y mapear almacenamiento en bloque manualmente cada vez que cambia un disco de máquina virtual.

No convertirá TrueNAS en Proxmox, no dejará obsoleto el ZFS local de Proxmox ni dotará a un servidor TrueNAS Community Edition de alta disponibilidad de almacenamiento empresarial. Lo que hace es lograr que un sistema TrueNAS independiente se comporte de forma muy parecida a un backend de almacenamiento nativo de Proxmox.

Creas un disco en la interfaz de Proxmox y el plugin puede generar el volumen ZFS correspondiente en TrueNAS, exponerlo mediante iSCSI o NVMe/TCP y conectarlo a la VM. La misma integración abarca snapshots, redimensionamiento, clonación, migración y borrado. Resulta indudablemente práctico, aunque determinar si tu arquitectura lo necesita es una cuestión aparte.

¿Qué reemplaza realmente el plugin de TrueNAS para Proxmox?

La mayor parte del trabajo manual entre Proxmox VE y el almacenamiento en bloque de TrueNAS. Sin el plugin, un flujo de trabajo típico de iSCSI exige crear un zvol en TrueNAS, definir un extent, asociarlo con un target, confirmar el mapeo LUN, volver a escanear el almacenamiento desde Proxmox y finalmente asignar el dispositivo de bloques resultante a la VM. Dos veces al año es algo asumible. Se vuelve tedioso con rapidez cuando Proxmox es tu plataforma principal de virtualización y los discos de VM se crean, redimensionan, clonan, mueven y eliminan de forma continua. El plugin convierte esas operaciones de almacenamiento en llamadas a la API.

TrueNAS lo describe como un backend de almacenamiento de Proxmox VE para TrueNAS 25.10 o superior. Se instala en los nodos de Proxmox, no en el servidor TrueNAS. Proxmox se comunica con la API de TrueNAS para crear y gestionar dispositivos de bloque respaldados por ZFS, mientras que la ruta de datos utiliza iSCSI o NVMe/TCP. Así, el plano de control opera a través de la API, mientras que el tráfico de almacenamiento real de las máquinas virtuales sigue circulando por un protocolo de almacenamiento en bloque.

Para un administrador, las operaciones con discos de VM pueden permanecer dentro de la interfaz de Proxmox sin necesidad de acudir a construir objetos de almacenamiento a mano. Una de las reacciones más claras tras el anuncio resumió el beneficio como pasar de:

create zvol -> map extent -> map target -> rescan -> attach

a básicamente:

create new disk

El hub de Proxmox de Mr.PlanB cubre las decisiones más amplias sobre almacenamiento y clústeres que sustentan este tipo de integración.

¿Resulta útil si Proxmox ya soporta ZFS?

Solo si el almacenamiento ZFS reside en otra máquina. Este fue el principal debate surgido en torno al anuncio.

Proxmox VE admite ZFS de forma nativa. Si los discos están físicamente instalados dentro del host de Proxmox y todo lo que necesitas son discos de VM sobre ZFS, intercalar TrueNAS entre Proxmox y esos mismos discos añade una capa innecesaria sin resolver un problema evidente. En ese escenario, ZFS local en Proxmox suele ser más simple.

El plugin cobra sentido cuando TrueNAS actúa como un sistema de almacenamiento independiente. Imagina tres nodos de computación Proxmox conectados a un servidor TrueNAS dedicado. Ningún almacenamiento de VM es local a los nodos de computación, y los tres hosts deben ver el mismo almacenamiento en bloque para que las cargas de trabajo puedan migrar entre ellos. En esa configuración, TrueNAS funciona como almacenamiento compartido centralizado, una tarea diferente a la de ZFS local en Proxmox.

Proxmox puede ejecutar ZFS sin duda. El plugin responde a la facilidad con la que Proxmox puede consumir almacenamiento gestionado por otro sistema ZFS, y ahí es donde se gana su lugar.

¿Por qué no usar simplemente NFS?

Sigues pudiendo hacerlo. NFS es una de las vías más directas para conectar TrueNAS y Proxmox, y en muchos entornos pequeños resulta suficiente. Creas un dataset NFS, lo exportas, lo añades como almacenamiento en Proxmox y múltiples nodos pueden utilizarlo.

El plugin se dirige a administradores que buscan específicamente almacenamiento en bloque y un comportamiento de snapshots más cercano al almacenamiento nativo. TrueNAS sostiene que los discos de VM basados en NFS pueden acarrear sobrecostes en snapshots, porque Proxmox suele depender de formatos copy-on-write de QEMU en almacenamiento de archivos. Con discos virtuales de gran tamaño, esas operaciones pueden ralentizarse hasta degradar las cargas de trabajo. El almacenamiento en bloque evita ese inconveniente, y el plugin permite que TrueNAS gestione los snapshots de ZFS por debajo de la operación de Proxmox, lo que encaja con lo que los administradores esperan de una integración con cabinas de almacenamiento.

Esto no convierte a iSCSI en una opción automáticamente superior a NFS. NFS resulta más sencillo de comprender y depurar, requiere menos fontanería de almacenamiento en bloque y funciona bien para ISO, copias de seguridad, plantillas y muchas cargas de trabajo habituales de VM. El plugin se vuelve más interesante cuando el rendimiento de los snapshots, el thin provisioning, el multipathing, la gestión independiente de discos virtuales o el acceso en bloque de alto rendimiento son prioridades.

El propio equipo de TrueNAS sugiere un diseño mixto: el plugin para el almacenamiento en bloque de las VM, junto con NFS o SMB en el mismo sistema para imágenes ISO, copias de seguridad o carpetas compartidas habituales.

¿Por qué no usar iSCSI normal sin ningún plugin?

El iSCSI convencional aporta conectividad, pero no automatiza el ciclo de vida del almacenamiento. Un target iSCSI presenta dispositivos de bloque a Proxmox perfectamente. La complicación empieza cuando necesitas otro dispositivo de bloques, porque alguien tiene que crearlo a mano. En un laboratorio doméstico eres tú. En una empresa puede implicar abrir un ticket al equipo de almacenamiento.

El plugin traslada esa tarea a Proxmox. Cuando se crea un disco de VM, la API de TrueNAS puede generar el zvol correspondiente y su asignación de almacenamiento. Cuando el disco se borra, el plugin puede eliminar los objetos de almacenamiento subyacentes. El redimensionamiento y los snapshots siguen el mismo esquema. Eso se acerca mucho más a lo que los administradores de VMware esperan del comportamiento de una integración de almacenamiento.

Esto explica además por qué las empresas pueden prestar más atención a esta función de lo que sugerían las primeras reacciones en el ámbito de los homelabs. Quien tiene un homelab puede decir con lógica: "Creo un zvol una vez al año, ¿para qué necesito una integración?". Un equipo de virtualización que aprovisiona cientos de discos responderá de otra manera, porque suprimir tickets de almacenamiento repetitivos ahorra tiempo operativo real.

¿Qué aporta NVMe/TCP?

Un acceso en bloque con menor sobrecarga, lo que constituye uno de los puntos más interesantes del plugin, aunque conlleva requisitos de versión. La documentación de TrueNAS indica que el plugin admite iSCSI y NVMe/TCP, y el modo NVMe/TCP requiere Proxmox VE 9.x o posterior.

Esto convierte al plugin en algo más que un simple envoltorio de automatización para iSCSI. Con almacenamiento NVMe rápido y redes Ethernet modernas, NVMe/TCP puede ser un camino más natural entre los hosts de virtualización y el almacenamiento flash que los antiguos protocolos basados en SCSI. El anuncio despertó interés precisamente por este aspecto: varios administradores valoraban menos la integración en la GUI que el hecho de contar con un backend de almacenamiento de terceros nativo exponiendo NVMe/TCP hacia Proxmox.

Las cuestiones habituales de diseño de almacenamiento no desaparecen con un nuevo protocolo. La redundancia de red, el multipathing y la latencia siguen importando. Y si el sistema TrueNAS es una máquina con una sola controladora, sigue constituyendo un punto único de fallo. Un protocolo de transporte más rápido no convertirá un dispositivo de almacenamiento sin alta disponibilidad en un sistema tolerante a fallos.

¿Convierte el plugin a TrueNAS en una alternativa a Ceph?

Puede ser una alternativa, pero representa una arquitectura distinta. Un clúster típico de Ceph en Proxmox distribuye el almacenamiento entre los propios nodos de Proxmox, de modo que la computación y el almacenamiento están hiperconvergidos. Si pierdes un nodo de almacenamiento, los nodos restantes continúan sirviendo datos replicados, siempre que el clúster se haya diseñado con suficiente tolerancia a fallos.

Un diseño basado en TrueNAS suele separar las capas: los nodos Proxmox se encargan del cómputo y TrueNAS del almacenamiento. Esto puede ser más simple, en especial si la organización ya posee una cabina de almacenamiento importante o prefiere nodos de computación sin grandes conjuntos de discos locales. Un sistema dedicado puede ofrecer además un rendimiento de almacenamiento muy elevado. Un administrador comentó en el debate que utilizaba TrueNAS como target SCSI con MPIO sobre enlaces dobles de 100GbE porque rendía mejor para su carga de trabajo que Ceph. Es el resultado de un despliegue concreto y no debe interpretarse como un benchmark universal.

La contrapartida arquitectónica tiene más peso. Con un único servidor TrueNAS convencional, la máquina de almacenamiento se convierte en una dependencia central. TrueNAS Enterprise puede ofrecer alta disponibilidad con doble controladora en hardware empresarial certificado, pero Community Edition no convierte un par arbitrario de servidores en esa arquitectura de controladora dual. Por eso TrueNAS insiste en tratar el plugin como computación y almacenamiento independientes, no como un sustituto hiperconvergente de Ceph.

Si tu objetivo es aprender o desplegar Ceph, el Proxmox Health Check es un recordatorio útil de que el quorum, las redes de almacenamiento, el diseño de réplicas y los dominios de fallo importan mucho más que lograr que el pool aparezca en la interfaz.

¿Está este plugin listo para producción hoy?

No, según la documentación actual de TrueNAS, así que conviene tener esto en cuenta antes de ejecutar el comando de instalación de GitHub. TrueNAS cataloga actualmente el plugin de almacenamiento para Proxmox VE como:

• en desarrollo activo
• sin pruebas completas
• destinado a TrueNAS Community Edition
• aún no compatible con sistemas TrueNAS Enterprise
• no recomendado para cargas de trabajo en producción

El anuncio de septiembre indica que el soporte Enterprise está en validación activa. Leídas con atención, ambas afirmaciones coinciden: el código existe, los usuarios de Community Edition pueden probarlo, la validación Enterprise avanza y el soporte oficial de producción todavía no ha llegado.

Esto tiene peso porque el entorno que más se beneficia del plugin, almacenamiento compartido bajo múltiples hipervisores, es también donde se debe ser más prudente. Un fallo en el plugin de almacenamiento puede afectar a la creación de VM, snapshots, migración, borrado o al acceso al volumen subyacente. Que algo esté en GitHub no significa que esté listo para el clúster central de producción.

TrueNAS recomienda probarlo primero en un clúster que no sea de producción, y ese es el enfoque adecuado.

¿Cuáles son las contrapartidas de seguridad?

El plugin logra su automatización otorgando a Proxmox mayor autoridad sobre TrueNAS. La documentación actual de TrueNAS exige que los nodos de Proxmox alcancen la API WebSocket de TrueNAS mediante HTTPS en el puerto 443 y el servicio de almacenamiento mediante iSCSI en TCP 3260. NVMe/TCP utiliza su propia ruta de almacenamiento. La configuración de almacenamiento de Proxmox guarda además una clave de API de TrueNAS con privilegios suficientes para crear y gestionar datasets y recursos de almacenamiento en bloque. Es un nivel de confianza superior al de un host que solo accede a una LUN iSCSI previamente creada por un administrador.

Una de las primeras dudas planteadas en la comunidad era si el plugin requeriría acceso SSH desde Proxmox hacia TrueNAS. La documentación oficial actual no contempla SSH como mecanismo de control habitual; el plugin utiliza la API de TrueNAS. Esto resulta más conveniente para el control de accesos, pero la clave de API sigue siendo crítica. Si un host Proxmox se ve comprometido, un atacante podría heredar los permisos de gestión de almacenamiento asignados a esa clave.

Gestiona la red de almacenamiento y la API de administración como redes de infraestructura, separadas del tráfico habitual de red de los clientes. En la práctica, esto implica utilizar los permisos de API más restringidos que admita el plugin, limitar qué nodos de Proxmox pueden comunicarse con la API de TrueNAS y aislar la red de almacenamiento de forma independiente.

La automatización práctica no reduce los privilegios. Por lo general ocurre lo contrario, puesto que la cuenta de automatización necesita permisos suficientes para realizar las tareas que ya no ejecutas a mano.

¿Qué hay de ejecutar TrueNAS como una VM dentro de Proxmox?

Ese es un diseño distinto al objetivo de este plugin. Puede funcionar, y muchos homelabs lo aplican. Se hace passthrough de una HBA o de discos físicos hacia una VM con TrueNAS, se deja que TrueNAS gestione el pool ZFS y luego se exporta el almacenamiento hacia otras máquinas o VM.

La complicación evidente radica en la dependencia circular. Si Proxmox necesita almacenamiento de una VM de TrueNAS que a su vez requiere que Proxmox arranque, el orden de inicio y recuperación se vuelve crítico. Un usuario en la comunidad explicó que mantenía fuera de la instancia virtualizada de TrueNAS cualquier elemento necesario para arrancar Proxmox o las VM críticas, utilizándola solo para datos masivos. Es un criterio prudente para mitigar dependencias circulares.

Aun así, no es el escenario idóneo para este plugin, pensado para un sistema TrueNAS dedicado que atiende a múltiples nodos de Proxmox. Eso aporta a la capa de almacenamiento su propio hardware, ciclo de vida, interfaces de red y perímetro de fallo.

¿Quién debería probar realmente este plugin?

Tres perfiles deberían encontrarlo interesante desde el primer momento. Primero, quienes ya operan Proxmox junto a TrueNAS sobre iSCSI gestionado manualmente. El plugin ataca directamente tareas repetitivas conocidas.

Segundo, un proyecto de migración desde VMware donde la organización busca Proxmox para computación pero no quiere rediseñar el almacenamiento de forma simultánea. Conservar una arquitectura de almacenamiento compartido independiente permite que el cambio de hipervisor sea menos disruptivo.

Tercero, un laboratorio que evalúe almacenamiento en bloque mediante iSCSI o NVMe/TCP antes de decidir cómo diseñar un entorno Proxmox a mayor escala.

¿Quién probablemente no lo necesite? Un host Proxmox único con discos locales y ZFS local, un laboratorio pequeño satisfecho con NFS, un clúster concebido alrededor de Ceph o quien use TrueNAS exclusivamente para carpetas SMB y archivos multimedia.

El alcance concreto del plugin es lo que le confiere valor. Conecta dos productos que muchos administradores ya utilizan juntos y elimina una capa de gestión manual de almacenamiento.

Dónde reside la responsabilidad del almacenamiento

El debate deriva con frecuencia en "ZFS de TrueNAS frente a ZFS de Proxmox", lo que pierde de vista el propósito del plugin. Ambos utilizan OpenZFS y ambos pueden gestionar almacenamiento. La discrepancia radica en dónde se sitúa la responsabilidad del almacenamiento.

Si los discos pertenecen a un único host Proxmox, el ZFS nativo de Proxmox es imbatible en simplicidad. Si varios hosts de Proxmox precisan almacenamiento compartido desde un sistema TrueNAS dedicado, el plugin tiene mucho más sentido. Y si requieres almacenamiento hiperconvergente capaz de sobrevivir a caídas de nodos de computación sin depender de una cabina externa, Ceph responde a una necesidad diferente.

El plugin no anula ninguna de estas opciones, pero hace que una de ellas resulte mucho más sencilla de operar.

Por el momento, conviene probarlo sin comprometer cargas críticas de producción. Si TrueNAS pasa el plugin de fase preliminar a una integración Enterprise plenamente respaldada, podría convertirse en una de las opciones de almacenamiento más prácticas para organizaciones que migran cargas de virtualización hacia Proxmox sin rehacer toda su arquitectura de almacenamiento al mismo tiempo.