Proxmox VE no tiene un sistema de archivos en clúster como VMFS, el que permite en VMware que varios hosts compartan un mismo LUN de una SAN, y la empresa que lo desarrolla no tiene planes de crearlo. El divulgador Brandon Lee reabrió el debate el 24 de octubre con una pregunta directa, si Proxmox lo necesita, y con el análisis de dos proyectos comunitarios que intentan cubrir el hueco: CetraFS y MeshXFS. Los dos funcionan, pero ninguno está listo para producción.
Las claves del debate sobre un VMFS para Proxmox en 20 segundos
- Proxmox Server Solutions descarta por ahora un sistema de archivos en clúster propio.
- La vía oficial con una SAN es LVM compartido en modo grueso, o Ceph sin cabina.
- CetraFS va por la versión 0.6 y MeshXFS por la 0.90.132, ambas previas a la 1.0.
- Los dos exigen cabinas compatibles, fencing y pruebas antes de confiarles datos.
La cuestión pesa sobre todo en las empresas que salen de VMware tras la subida de precios de Broadcom. En vSphere basta con presentar un LUN iSCSI o Fibre Channel a todos los hosts y formatearlo como VMFS para tener almacenamiento compartido con discos ligeros, snapshots y migración en caliente. VMFS coordina el acceso de cada host con bloqueos atómicos en la propia cabina (ATS) para que nadie escriba encima de otro. En Proxmox esa cabina sigue sirviendo, pero hay que diseñar el almacenamiento de otra manera.
La postura oficial de Proxmox
Proxmox Server Solutions no ha anunciado ningún sistema de archivos en clúster, ni siquiera como vista previa. En enero de 2026, un miembro del equipo de Proxmox respondió en el foro oficial a un usuario que preguntaba por un equivalente a VMFS que la empresa no tiene planes de desarrollarlo, porque exigiría un esfuerzo considerable. También explicó que OCFS2 y GFS2, los dos sistemas de archivos en clúster veteranos de Linux, se evaluaron y no tienen soporte oficial: OCFS2 por problemas con el kernel y GFS2 porque obliga a reiniciar el host si Corosync, la capa de comunicación del clúster, se corta brevemente. Algunos usuarios sí usan OCFS2 en clústeres de ocho nodos, pero por su cuenta.
La recomendación oficial es usar LVM en modo grueso sobre el LUN compartido, como almacenamiento de bloques, con multipath. Desde Proxmox VE 9.0, publicado en agosto de 2025, ese LVM admite snapshots mediante cadenas de volúmenes, aunque sigue sin aprovisionamiento ligero. La otra vía es Ceph, que reparte los datos entre los discos de los propios nodos y que, según Proxmox, no debe montarse encima de una SAN porque anula su redundancia. Revista Cloud ya repasó las opciones de almacenamiento compartido en Proxmox, incluido un plugin de LVM Thin compartido de la comunidad.
CetraFS: un VMFS abierto construido desde cero
CetraFS, desarrollado por Massimo Cetra, se define como una alternativa abierta a VMFS. Es un módulo del kernel fuera del árbol principal con sus propias herramientas (mkfs.cetra, fsck.cetra y defrag.cetra). Los nodos se coordinan a través de la propia cabina con la orden atómica SCSI COMPARE AND WRITE, la misma idea que el ATS de VMFS, sin un gestor de bloqueos por red. Cada nodo es dueño de sus propios grupos de zonas para asignar espacio, usa un journal por nodo para recuperarse de cortes y protege cada estructura en disco con sumas CRC32C. Admite ficheros de hasta 16 TiB, imágenes ligeras y migración en caliente con Proxmox, y tiene un plugin de almacenamiento con integración en la interfaz web.
Su repositorio es claro con los límites. La versión es la 0.6, se describe como joven y previa a la 1.0, solo se ha probado con los kernels 7.0.14 y 7.1.8 de Debian (el de Proxmox VE pertenece a la misma familia) y pide copias de seguridad independientes. Sin una cabina con COMPARE AND WRITE, el volumen solo puede montarse en un nodo; Brandon Lee comprobó con sg3-utils que un volumen iSCSI de TrueNAS lo admite, pero no todas las cabinas ni todos los destinos iSCSI por software lo hacen. Para varios nodos en producción, CetraFS exige además un gestor de clúster externo que aísle los hosts caídos (STONITH), y advierte de que multipath puede retener la E/S durante 90 segundos en algunas cabinas, por lo que fija una ventana de 120 segundos antes de dar un nodo por muerto. Su autor reconoce que usó asistencia de IA después de diseñar la arquitectura.
MeshXFS: XFS en clúster escrito por IA
MeshXFS, de Steve Shoecraft, parte del código de XFS del kernel de Linux y le añade lo necesario para que varios nodos lo monten en lectura y escritura a la vez: bloqueo de metadatos, coherencia de caché, fencing mediante reservas persistentes SCSI y recuperación de journals. Tiene licencia GPL-2.0, ofrece dos formas de coordinación, un gestor de bloqueos por red o bloqueos en disco con COMPARE AND WRITE, y admite DRBD en modo primario dual para clústeres de dos nodos sin SAN. Se distribuye como módulo DKMS para Proxmox VE 9.1 y 9.2, RHEL 9, Ubuntu y Debian, con su plugin para Proxmox.
El proyecto destaca por cómo se ha hecho: según su repositorio, todo el código de clúster, bloqueo distribuido y fencing lo escribieron agentes de IA, principalmente Claude Opus en Claude Code, y no una persona con ayuda de IA. Su documentación de pruebas es detallada. La versión 0.90.132 se ha validado con 2, 4, 8 y 16 nodos sobre un LUN iSCSI compartido, con una batería de 31 pruebas más fallos de ruta en multipath, y en tres hosts de Proxmox VE 9 con migración en caliente y cortes de alimentación. El propio proyecto documenta sus problemas: retiró la versión 0.90.131 tras detectar un error que podía dejar inconsistencias, y excluye la configuración de 8 y 16 nodos con bloqueo por red sobre multipath porque, cuando un nodo salía del clúster, el resto se quedaba parado entre 66 y 77 segundos.
Por qué Proxmox podría necesitarlo
Brandon Lee sostiene que un sistema de archivos en clúster con soporte oficial ayudaría a las organizaciones que dejan VMware y ya tienen una SAN pagada, porque les ahorraría rediseñar su almacenamiento o comprar hardware para Ceph. No declara ganador entre los dos proyectos y insiste en que, con datos en clúster, la fiabilidad importa más que las funciones. La comparación muestra enfoques distintos: CetraFS es un diseño propio pensado para máquinas virtuales y depende siempre de la cabina para coordinarse, mientras que MeshXFS se apoya en XFS, puede coordinarse por red y cubre el caso de dos nodos con DRBD.
El argumento contrario está en la respuesta de Proxmox: un sistema de archivos en clúster es caro de construir y mantener, y los intentos existentes en Linux no han dado la estabilidad que la empresa exige. Mientras tanto, LVM grueso compartido con snapshots y Ceph son las opciones con soporte. Para quien quiera probar CetraFS o MeshXFS, lo prudente es un laboratorio con la misma cabina que en producción, verificar la compatibilidad con COMPARE AND WRITE, provocar caídas de nodos y de rutas, y mantener siempre copias de seguridad fuera de ese volumen.
Preguntas frecuentes
¿Tiene Proxmox un equivalente a VMFS?
No. Proxmox ofrece LVM compartido en modo grueso con snapshots desde la versión 9.0, y Ceph, pero no un sistema de archivos en clúster sobre una SAN. La empresa ha dicho en su foro que no tiene planes de desarrollarlo.
¿Por qué no usa Proxmox OCFS2 o GFS2?
Según su equipo, los evaluó y no les da soporte oficial: OCFS2 por problemas con el kernel y GFS2 porque obliga a reiniciar el host si Corosync se corta brevemente.
¿Qué son CetraFS y MeshXFS?
Dos sistemas de archivos en clúster de código abierto con plugin para Proxmox. CetraFS es un diseño propio inspirado en VMFS y MeshXFS adapta XFS con código de clúster escrito por agentes de IA.
¿Se pueden usar en producción?
Sus propios autores no lo recomiendan todavía. CetraFS va por la 0.6, MeshXFS por la 0.90.132, y ambos exigen cabinas compatibles, fencing y copias de seguridad independientes.
Fuentes:
