Quien ha trabajado con vSphere y una cabina SAN conoce la comodidad: se presenta un LUN por iSCSI o Fibre Channel a todos los hosts, se formatea como VMFS y ya hay un datastore compartido con discos ligeros, snapshots y vMotion. VMFS coordina el acceso de cada host con bloqueos atómicos en la propia cabina (ATS, Atomic Test and Set) para que dos hosts no escriban a la vez sobre el mismo bloque de metadatos.
En Proxmox VE esa cabina sigue sirviendo, pero no de la misma manera. Y la pregunta pesa justo ahora, cuando muchas empresas salen de VMware por los precios de Broadcom, con renovaciones que multiplican la factura, y tienen una SAN a medio amortizar. El divulgador Brandon Lee reabrió el debate el 24 de octubre en Virtualization Howto y en su boletín Between the Clouds con una pregunta directa: ¿necesita Proxmox un sistema de archivos en clúster? Y presentó los dos proyectos que intentan dar la respuesta: CetraFS y MeshXFS.
La postura oficial está en un hilo del foro de Proxmox del 14 de enero de 2026. Un usuario preguntó por un equivalente a VMFS y Aaron, del equipo de Proxmox, respondió a cada punto:
En el mismo hilo, un usuario cuenta que lleva años con ocho nodos de Proxmox sobre OCFS2 en una SAN. Funciona, con buen rendimiento, pero sin soporte y con sustos en kernels recientes, porque el desarrollo de OCFS2 parece haberse detenido. Es la foto exacta del problema: se puede hacer, pero por tu cuenta.
LVM grueso sobre un LUN compartido es lo que Proxmox soporta y lo que conviene entender bien antes de buscar alternativas. Cada disco de máquina virtual es un volumen lógico; todos los nodos ven el grupo de volúmenes y Proxmox se encarga, con sus bloqueos de clúster, de que solo uno active cada volumen a la vez. La migración en caliente funciona, la alta disponibilidad también.
Lo que no da:
Para muchas instalaciones esto basta. Para quien venía de VMFS, con discos ligeros y snapshots sin pensar, es un paso atrás, y ese es el hueco que quieren cubrir los dos proyectos.
CetraFS, de Massimo Cetra, se presenta como «una alternativa moderna y abierta a VMFS». Es un módulo del kernel fuera del árbol principal más tres herramientas propias (mkfs.cetra, fsck.cetra y defrag.cetra), y está pensado para lo mismo que VMFS: imágenes de disco de máquinas virtuales sobre un único LUN que montan varios nodos.
Cómo funciona:
nofilelock. La 0.8.2 permite además soltar y retomar el bloqueo de un solo fichero durante la migración, en lugar de desactivarlo para todo el volumen.Lo que conviene leer dos veces, porque la propia página de estado del proyecto lo dice sin rodeos:
no_path_retry × polling_interval segundos en vez de devolver error (90 segundos en la entrada de serie de HPE 3PAR), y el latido del nodo se queda en esa misma cola. Si los demás lo dan por muerto antes, recuperan sus zonas mientras sus escrituras siguen pendientes, y esas escrituras aterrizan después. CetraFS espera 120 segundos por defecto antes de dar un nodo por muerto; si tu multipath reintenta más tiempo, hay que subirlo.La primera prueba completa entre nodos se hizo en un clúster Proxmox de tres nodos arm64 con una HPE 3PAR por Fibre Channel de 32 Gb, y otra en tres nodos amd64 con un LUN iSCSI corriente. El módulo es GPL-2.0 o posterior; las herramientas de usuario son AGPL-3.0 o licencia comercial, a elección.
MeshXFS, de Steve Shoecraft, toma otro camino: parte del XFS del kernel de Linux y le añade lo que le falta para que varios nodos lo monten en lectura y escritura a la vez: bloqueo de metadatos, coherencia de caché, fencing con reservas persistentes SCSI y recuperación de journals. Licencia GPL-2.0, módulo DKMS para Proxmox VE 9.1 y 9.2, RHEL 9, Ubuntu 24.04 y 26.04 y Debian 12 y 13, y plugin de almacenamiento para Proxmox.
Lo que lo distingue:
Su documentación de pruebas es de las más detalladas que hemos visto en un proyecto de este tamaño. Cada configuración se nombra con cuatro campos (nodos, método de bloqueo y forma de conexión) y la 0.90.132 declara quince como publicadas, de 2 a 16 nodos, con una batería de 31 pruebas más fallos de camino en multipath y, en tres hosts de Proxmox VE 9, migración en caliente y cortes de alimentación con alta disponibilidad.
Y también documenta lo que falla:
| CetraFS | MeshXFS | |
|---|---|---|
| Versión (27-oct-2026) | 0.8.2 | 0.90.132 |
| Base | Diseño propio, pensado para imágenes de VM | XFS del kernel con capa de clúster |
| Coordinación entre nodos | Solo COMPARE AND WRITE en la cabina | Red o COMPARE AND WRITE |
| Aislamiento de nodos caídos | Autoaislamiento + STONITH externo | Reservas persistentes SCSI |
| Sin cabina compartida | No (un solo nodo) | Dos nodos con DRBD |
| Kernels / plataformas | 7.0.14 y 7.1.8 (Debian, Proxmox) | Proxmox 9.1/9.2, RHEL 9, Ubuntu, Debian |
| Licencia | GPL-2.0+ (módulo); AGPL-3.0+ o comercial (herramientas) | GPL-2.0 |
| Plugin Proxmox | Sí, con interfaz web | Sí |
| Lo que avisa su autor | Beta; el formato puede cambiar sin migración | Una versión retirada; configuraciones excluidas |
Brandon Lee no declara ganador y lo resume con una idea que compartimos: en un sistema de archivos de clúster, la fiabilidad importa más que las funciones. Un fallo de un hipervisor se arregla reiniciando; uno en los metadatos compartidos afecta a todas las máquinas del volumen a la vez.
El argumento a favor es sencillo: una empresa que sale de VMware con una cabina pagada no debería tener que rediseñar el almacenamiento ni comprar discos para Ceph para conservar lo que ya tenía. Un sistema de archivos en clúster con soporte oficial le quitaría al cambio de plataforma una de sus fricciones más caras.
El argumento en contra está en la respuesta de Proxmox: es caro de construir, más caro de mantener con cada kernel, y los dos intentos veteranos de Linux no dieron la estabilidad que exige un hipervisor. Proxmox ha preferido mejorar lo que tiene, con las cadenas de volúmenes sobre LVM compartido, y apostar por Ceph para el almacenamiento distribuido.
Nuestra lectura es que la pregunta de fondo no es si Proxmox necesita un VMFS, sino si tu instalación lo necesita. Lo que se echa de menos de VMFS son tres cosas concretas: discos ligeros, snapshots y un único sitio donde verlo todo. Las tres tienen hoy respuestas parciales con soporte, y hay que ver cuál importa de verdad en cada caso.
| Situación | Opción con soporte | Lo que se pierde |
|---|---|---|
| SAN por FC o iSCSI que se quiere conservar | LVM grueso compartido + multipath | Discos ligeros desde Proxmox; snapshots solo en technology preview |
| La cabina también sirve NFS | NFS con discos qcow2 | Rendimiento frente a bloques; depende de la cabina |
| Se renueva hardware | Ceph en los propios nodos, mínimo tres | La inversión en la cabina |
| Dos nodos sin cabina | Replicación ZFS con QDevice | RPO cero: se pierden los minutos desde la última réplica |
| Ya hay experiencia con OCFS2 | OCFS2 por cuenta propia | El soporte de Proxmox |
Dos detalles prácticos que suelen pasarse por alto al traer una SAN de VMware:
discard en los discos de las VMs, el espacio que libera el sistema invitado vuelve a la cabina, aunque Proxmox vea el volumen lógico como grueso. Conviene comprobar que la cabina lo admite y vigilar la ocupación real, porque Proxmox no avisará de que el LUN se llena.Si la decisión es esperar a CetraFS o MeshXFS, lo prudente es preparar desde ya un laboratorio:
modprobe cetrafs caw_probe=<dispositivo> y buscar max_caw_blocks >= 1 en dmesg.multipathd show config, valores no_path_retry y polling_interval) contra la ventana de 120 segundos de CetraFS o el tiempo de recuperación de MeshXFS.Y seguir de cerca los dos repositorios: los dos han publicado varias versiones en una semana, y lo que hoy es una excepción documentada puede estar resuelto, o roto, en la siguiente.
Cuando ayudamos a migrar de VMware a Proxmox, la cabina existente es una de las primeras preguntas, y casi nunca tiene una respuesta única. A veces compensa conservarla con LVM compartido; otras, el momento de la migración es el mejor para pasar a Ceph o a almacenamiento gestionado en red y no arrastrar una cabina que vence el soporte en dos años. Si estás en ese punto, cuéntanos qué cabina tienes y cuántos hosts: con eso suele quedar claro qué camino tiene sentido y cuál es un experimento.
No. Con una cabina SAN, Proxmox VE usa LVM grueso compartido, que es almacenamiento de bloques y no un sistema de archivos. Su equipo dijo en enero de 2026 en el foro oficial que no tiene planes de desarrollar un sistema de archivos en clúster porque es un problema complejo que exigiría muchos recursos.
Los evaluó y decidió no darles soporte oficial. OCFS2 tiende a dar problemas con los kernels nuevos y GFS2 obliga a reiniciar el host si la conexión de Corosync se corta, aunque sea un momento. Hay quien usa OCFS2 con Proxmox, pero sin soporte.
Desde Proxmox VE 9.0, sí, mediante las cadenas de volúmenes, que guardan el estado en un volumen y las escrituras nuevas en otro en formato qcow2. En Proxmox VE 9.2 esa función sigue siendo technology preview, y no permite borrar el snapshot más reciente con la VM encendida.
Dos sistemas de archivos en clúster de código abierto con plugin para Proxmox, que permiten que varios nodos monten a la vez un mismo LUN. CetraFS es un diseño propio inspirado en VMFS que se coordina con COMPARE AND WRITE en la cabina. MeshXFS adapta XFS, puede coordinarse por red o en disco, y su código de clúster lo escribieron agentes de IA.
Sus propios autores no lo recomiendan todavía. CetraFS va por la 0.8.2, se declara beta y su formato en disco puede cambiar sin migración. MeshXFS va por la 0.90.132, retiró la versión anterior por un error y excluye algunas configuraciones. Los dos piden cabinas compatibles, fencing y copias independientes.
Proxmox lo desaconseja. Ceph reparte los datos entre los discos de varios nodos para que la caída de uno no importe; si todos esos discos salen de la misma cabina, la cabina vuelve a ser el punto único de fallo y se paga la complejidad de Ceph sin su ventaja.
Proxmox VE vuelve a ofrecer el número de una máquina borrada a la siguiente que se crea. Veeam ha pedido en el Bugzilla del proyecto una identidad permanente para cada VM, y Proxmox estudia terminar el parche que impide reutilizar VMID. Explicamos qué se hereda de verdad (lo hemos comprobado en el código), qué no, y cómo protegerse hoy.
Una oferta de empleo de Tesco describe la migración de la virtualización de sus tiendas de VMware a Proxmox. Es el caso más visible de un patrón que sirve también a una empresa española con sedes, clínicas o almacenes: nodos pequeños en cada sitio y un centro que lo gobierna todo. Lo explicamos, junto con lo que movieron esta semana Red Hat, VergeIO, Sidero Labs, Nutanix y la propia VMware.
Toda máquina virtual nace leyendo una nota de configuración: nombre, zona horaria, un usuario con su clave y un par de paquetes. En Debian 13, el programa que la lee llega con Python y varias decenas de paquetes y se ejecuta en cada arranque. FreeBSD la lee desde la 14.1 con nuageinit, unas 1.700 líneas de Lua del sistema base que solo corren la primera vez. Medimos lo que trae cada uno, qué cubre nuageinit y qué hay que tocar en Proxmox VE para que una VM FreeBSD reciba su IP fija.