Hay una pieza que lleva años faltando en las migraciones desde VMware: el sistema de ficheros que deja a varios servidores montar la misma LUN a la vez y poner los discos de las máquinas encima. Esta semana se han puesto a circular dos candidatos a la vez; ninguno de los dos nació esta semana. Los dos son libres, los dos empaquetan para Debian y los dos escriben en su propio README cosas que no recordamos haber leído en la documentación pública de ninguna cabina que hayamos operado. La que decide la conversación la firma MeshXFS y cabe en una línea: «no release has been verified on a storage array».
El hueco que notas desde que te fuiste de VMware
VMFS no es glamuroso, pero hace una cosa muy concreta y muy difícil: varios hosts montan a la vez el mismo volumen de bloque —una LUN de iSCSI o de fibra— y los discos de las máquinas virtuales viven como ficheros encima de ese volumen. Eso es lo que te deja tener un almacén central, mover máquinas entre hosts sin copiar nada y hacer snapshots por fichero. Cuando sales de vSphere con la cabina todavía amortizándose, ese es el trozo que no tiene recambio evidente.
Proxmox VE sí sabe compartir una LUN: le pones LVM encima y los volúmenes lógicos quedan visibles para todo el clúster. Lo que no tienes es un sistema de ficheros, con lo cual tampoco tienes ficheros: tienes volúmenes gruesos, y durante años tampoco tuviste snapshots. De eso escribimos hace unas semanas, cuando contamos migrar a Proxmox con tu cabina y descubrir que el snapshot no viaja. Ahí está el hueco, y ahí es donde han aterrizado los dos proyectos.
CetraFS: la coordinación la hace la propia cabina
CetraFS se presenta sin rodeos como «un sistema de ficheros en clúster, de disco compartido, para Linux; una alternativa moderna y abierta a VMFS». Es un módulo de kernel fuera del árbol más tres herramientas de espacio de usuario (mkfs.cetra, fsck.cetra, defrag.cetra), con la 0.6 como versión que empaqueta el repositorio. Lo interesante es cómo se ponen de acuerdo los nodos: no hay red. Cada reclamación en disputa —el candado del espacio de nombres, el de apertura de fichero, el registro del nodo, la propiedad de un grupo de zonas, un bit del mapa— es una sola operación atómica SCSI COMPARE AND WRITE sobre un registro de 512 bytes. Es la misma idea que el ATS de VMFS, y el propio proyecto lo dice así.
La lista de lo que trae es seria: diario de rehacer por nodo, CRC32C verificado por el kernel al leer, ficheros dispersos de hasta 16 TiB y una opción de montaje nofilelock para que una imagen pueda estar abierta en dos nodos durante el traspaso de una migración en vivo de Proxmox. No trae listas de control de acceso POSIX. Y su estado lo escribe el propio proyecto, en negrita, antes que nada: «joven, pre-1.0. Muy revisado, sometido a fuzzing y a pruebas de caída, pero no curtido en producción como lo están VMFS o ext4. Construido y probado sobre Linux 7.0.14 y 7.1.8+deb13 […]. Guarda copias independientes». Esos dos núcleos son toda la lista; retenlo para la cuarta comprobación de más abajo.
MeshXFS: XFS con clúster encima, y una declaración de autoría
El segundo proyecto es MeshXFS (GPL-2.0), y toma otro camino: parte del XFS del kernel y le añade lo que hace falta para que varios nodos monten el mismo dispositivo en lectura y escritura. Trae gestor de candados por red o por disco —de nuevo COMPARE AND WRITE—, módulo DKMS y un plugin de almacenamiento para Proxmox VE. Y lleva en la portada un párrafo que no habíamos leído nunca en un repositorio de este tipo: «MeshXFS fue escrito enteramente por IA, a lo largo de muchas sesiones de desarrollo. Ningún humano escribió, editó a mano ni revisó línea a línea el código de clustering». Nombra al agente principal —Claude Opus corriendo de forma autónoma en Claude Code, que escribió «buena parte» del código— y nombra también a los modelos que consultó en los problemas más duros, el diseño del protocolo de candados, las carreras de recuperación y la corrección del vallado: Claude Fable, GPT, Gemini y Astra, de los que escribe que sin ellos el proyecto no se habría terminado. Y acota la parte humana: «dirigir el trabajo, fijar los requisitos y ejecutar las pruebas, no escribir la implementación». El propósito que declara el proyecto es literalmente averiguar si una IA podía escribir un controlador de dispositivo de esta complejidad.
Nuestra postura sobre esto, ya que va a ser lo único que se comente: es la pregunta menos interesante que plantea ese repositorio. Un sistema de ficheros en clúster no se juzga por quién lo tecleó, sino por lo que ha sobrevivido y por lo que su autor admite que no ha probado. Y justamente ahí MeshXFS documenta mejor que la mayoría de productos de pago. Declara quince configuraciones publicadas, nombradas con un formato de cuatro campos (nodos/clase/método/conexión), y el listón para publicar una es explícito: ningún defecto abierto que pueda perder datos ni tumbar, colgar o parar un nodo. La cola de defectos es pública y se lee con una herramienta del propio repositorio. Con un matiz que el propio fichero no resuelve: su tabla dice que las quince se verificaron en la 0.90.132, y unas secciones más abajo los ejemplos de esa misma herramienta dicen que varias configuraciones con gestor de candados por red se verificaron por última vez en la 0.90.130. No concuerda consigo mismo, y lo señalamos precisamente porque es el documento que estamos elogiando.
Dos ejemplos de que ese listón no es decorativo. La versión 0.90.131 fue retirada: comprobaciones que terminaron después de publicarla encontraron que podía dejar una entrada apuntando a un inodo que otro nodo acababa de liberar, y el proyecto escribe que no debería haberse publicado antes de que acabaran las comprobaciones. Y en la 0.90.132, la configuración de ocho nodos con gestor de candados por red sobre multipath dejó de reclamarse porque, al salir un nodo del clúster, los demás se quedaron esperando el candado de un directorio entre 66 y 77 segundos. La de dieciséis se retiró con ella, sin medirla, hasta que el arreglo se verifique también ahí. No falló ninguna operación ni se perdió nada; aun así, el proyecto lo llama defecto y retira la reclamación. Ese es el comportamiento que te gustaría ver en el portal de soporte de tu fabricante.
La pregunta incómoda: ¿quién mata al nodo partido?
Aquí es donde el asunto deja de ser de almacenamiento y pasa a ser de arquitectura, y donde los dos proyectos contestan cosas distintas a la misma pregunta. Un sistema de ficheros compartido sobrevive mientras solo escriba quien debe. Cuando un nodo se queda aislado pero sigue vivo y con la LUN delante, alguien tiene que apagarlo de verdad. CetraFS lo dice sin maquillaje: para producción multinodo hace falta un gestor de clúster externo que haga vallado de hosts (STONITH), porque su propio mecanismo es un tiempo de espera de latido y un autovallado del nodo reclamado, pero «no mata a un host partido». Y añade la comparación que lo explica todo: es «el mismo reparto de responsabilidad que VMFS (el arrendamiento sobre el almacenamiento) y vSphere HA (el aislamiento del host)».
Ahí está la tesis de todo esto: lo que perdiste al salir de vSphere no fue VMFS, fue que las dos mitades vinieran de fábrica y compartieran reloj. Si sustituyes solo la de almacenamiento y das por hecha la otra, tienes medio clúster. MeshXFS contesta distinto: valla al nodo muerto con reservas persistentes SCSI sobre la propia LUN, salvo en DRBD y en el modo de disco compartido por hipervisor, donde el vallado lo hace una autoridad externa —un IPMI, una regleta gestionada, el propio hipervisor— o una confirmación del operador. Consecuencia práctica y poco comentada: un dispositivo sin reservas persistentes (virtio-blk, NVMe, un RAID por software con md) es rechazado al montar. Sin aviso previo: simplemente no monta.
En Proxmox la otra mitad existe: el gestor de alta disponibilidad apaga por perro guardián al nodo que pierde el quórum. Pero existe si la has configurado, y tiene su propio reloj, que no es el del sistema de ficheros. Esa distancia entre los dos relojes es exactamente el sitio donde se pierden datos, y de ella hablamos al contar por qué la alta disponibilidad de Proxmox no evita la caída, la acorta.
Los 120 segundos que casi nadie ha mirado
El fragmento más valioso de los dos repositorios está en los requisitos de CetraFS, en el apartado de multipath, y describe una trampa que no es de software nuevo: es de cómo funciona dm-multipath desde siempre. Cuando caen todos los caminos a la LUN, multipath no falla la entrada/salida: la encola durante no_path_retry × polling_interval segundos. El proyecto pone el ejemplo de la entrada de fábrica para una HPE 3PAR: 90 segundos. Y añade la parte que pocos atan: durante esos 90 segundos el nodo tampoco puede mandar su latido, porque el latido está encolado detrás de los mismos caminos muertos.
Con eso montado, la secuencia se escribe sola. Si el encolado de multipath dura más que la ventana de obsolescencia del sistema de ficheros, los demás nodos declaran muerto al nodo callado y le reclaman sus grupos de zonas mientras sus escrituras siguen pendientes. Luego vuelven los caminos, la cola se drena y esas escrituras aterrizan sobre espacio que ya pertenece a otro. CetraFS pone la ventana por defecto en 120 segundos, precisamente para que quepan los 90 de fábrica, y deja ajustarla entre 15 y 240 —siempre al menos el triple del intervalo de latido— con stale_secs.
Lo accionable es de esta tarde y no depende de que instales nada: mira tu configuración efectiva de multipath con multipath -t, busca el no_path_retry y el polling_interval que aplican a tu cabina, multiplícalos y guarda el número. Conviene ser preciso con lo que significa. La ventana de corrupción que describe CetraFS necesita además un sistema de ficheros que reclame el espacio de otro nodo; si hoy corres LVM grueso compartido, los volúmenes tienen dueño fijo y esa ventana no la tienes. Lo que sí tienes es el número: gobierna cuánto se queda colgada tu entrada/salida antes de dar error, y por tanto cuánto tarda en reaccionar todo lo que hay encima, empezando por el perro guardián de la alta disponibilidad de Proxmox y siguiendo por los tiempos de espera de dentro del invitado. Que esté escrito en el README de un proyecto pre-1.0 y no en la guía de tu fabricante es, francamente, lo más incómodo de todo esto.
Las dos, lado a lado
La frase que decide la conversación
MeshXFS tiene un apartado titulado «lo que esto no cubre», y abre con lo siguiente: «Todos los nodos con almacenamiento compartido son máquinas virtuales. El banco de desarrollo y los conjuntos de plataformas son invitados KVM sobre un mismo anfitrión, y las LUN compartidas son LUN iSCSI servidas desde ese anfitrión. Ninguna versión publicada se ha verificado sobre una cabina de almacenamiento.» La única excepción que admite es la configuración de dos nodos sobre DRBD, verificada además en dos máquinas físicas con Proxmox VE 9 y sus discos locales.
Junta eso con lo demás que el mismo apartado reconoce y el cuadro queda cerrado: fibra y SAS no están verificados, solo los núcleos y los tamaños de clúster que la portada nombra uno a uno —«cualquier otro núcleo está sin probar, incluso en la misma distribución»—, la prueba de remojo dura treinta segundos salvo que se pida más larga, y la pérdida de corriente en la cabina queda fuera porque la caché de escritura tiene que sobrevivirla. Y una frase más, de las que uno se apunta: «la primera vez que se mataron dos nodos a la vez, bajo carga, aparecieron defectos que todas las pruebas de una sola muerte habían pasado por alto».
CetraFS no hace esa declaración porque no publica lista de configuraciones verificadas, pero tampoco afirma lo contrario: su batería automática corre sobre imágenes en bucle, «nunca sobre un dispositivo real», y las suites destructivas o de hardware real son opcionales y hay que nombrarles el dispositivo a mano. Ninguno de los dos, por tanto, puede enseñarte hoy una cabina verificada. Traducido a la decisión que tienes delante: si estás saliendo de VMware con una cabina de fibra —el caso que más nos encontramos— hoy ninguno de los dos te cubre. Uno no ha verificado tu transporte; el otro no ha verificado ninguna cabina, de ningún tipo. No es un reproche a los proyectos, que lo dicen ellos mismos y en su portada.
La opción oficial también lleva la etiqueta de vista previa
Antes de que esto suene a que lo libre va por detrás: la respuesta oficial de Proxmox a este mismo problema está en la misma situación. Proxmox VE 9.0 (5 de agosto de 2025) introdujo los snapshots como cadenas de volúmenes, que es justo lo que te permite hacer instantáneas de máquinas sobre almacenamiento LVM grueso compartido, el típico montado sobre una LUN de iSCSI o de fibra. Venía marcado como vista previa tecnológica. Hoy, 25 de octubre de 2026, sigue marcado igual: lo dice la hoja de ruta pública del proyecto, donde el objetivo «sacar los snapshots como cadenas de volúmenes (vista previa desde Proxmox VE 9.0) de la vista previa en LVM grueso, Directorio, NFS y CIFS, incluido el borrado en caliente del snapshot de más arriba» todavía está en la lista de lo que falta por hacer. Son 446 días con la etiqueta puesta.
Y unas líneas más abajo, en la misma sección de la hoja de ruta, aparece otro pendiente que describe el terreno entero: «mejorar la integración y la experiencia de configuración de multipath para despliegues de fibra e iSCSI». Es decir, los tres caminos que tienes hoy para poner una cabina debajo de un clúster Proxmox —los dos sistemas de ficheros nuevos y la vía oficial— llevan los tres, por escrito, la palabra «todavía». La diferencia entre ellos no es la madurez: es a quién llamas cuando se rompe, y eso sí es una decisión de dirección y no de sistemas.
Qué haríamos nosotros, y cuándo no tocaríamos nada
Operamos Proxmox VE con Ceph en producción, en más de una sala, y hemos movido empresas de VMware a Proxmox; también hemos dicho que no a alguna migración que no salía a cuenta. Con eso por delante, lo que haríamos hoy con una cabina depende de una pregunta: si el hierro está amortizado o no.
Si a la cabina le quedan años, se queda: LVM grueso compartido para los discos de las máquinas, y la vista previa de las cadenas de volúmenes activada primero en un almacenamiento que no sostenga nada crítico, con el plan de copias intacto. Es menos elegante que un sistema de ficheros, pero el camino está recorrido por mucha gente. Si el hierro toca renovarlo de todas formas, la conversación cambia de sitio: con discos locales en los nodos y almacenamiento distribuido Ceph desaparece la LUN compartida, y con ella el problema del sistema de ficheros, el del vallado y la ventana del multipath entera. Lo que no desaparece es el coste: Ceph tiene sus propias reglas, empieza en tres nodos y conviene saber qué hace y qué no cuando pierdes una pieza, que es lo que contamos en un Ceph de tres nodos no se cura solo, aguanta.
Con CetraFS y MeshXFS sí recomendamos una cosa: probarlos. En laboratorio, con datos que no importen, matando nodos a pares y reportando lo que salga; los dos llevan cola de defectos y un proceso de versiones que convierten un informe bien hecho en una mejora real. Lo que no haríamos —y aquí no hay matiz— es ponerlos bajo producción esta semana porque funcionaron en el laboratorio. Una prueba de remojo de treinta segundos no dice nada sobre el martes que viene.
Siete comprobaciones antes de acercar un sistema de ficheros en clúster a una LUN de producción
- ¿Tu transporte está en la lista de verificados? No en la de implementados: en la de verificados en la versión que vas a instalar. Fibra y SAS no lo están en MeshXFS. CetraFS exige COMPARE AND WRITE atómico, y se prueba sin montar nada:
modprobe cetrafs caw_probe=<dispositivo>y mirar endmesgquemax_caw_blockssea al menos 1. - ¿Quién mata al nodo partido, con qué aparato y en cuántos segundos? Si no puedes nombrar el aparato —un IPMI, una regleta gestionada, un hipervisor, una reserva SCSI— no tienes vallado: tienes un tiempo de espera y buena suerte.
- Multiplica
no_path_retryporpolling_interval(los ves conmultipath -t) y compáralo con la ventana de obsolescencia del sistema de ficheros. Si el producto es mayor, tendrás una ventana de corrupción el día que montes uno de estos. Si hoy corres LVM grueso, lo que tienes es entrada/salida colgada más tiempo del que tu alta disponibilidad tarda en dar por muerto al nodo, que tampoco es inocuo. - ¿Tu versión exacta de núcleo está en la lista? El núcleo, no la distribución. «Cualquier otro núcleo está sin probar, incluso en la misma distribución», y en un módulo fuera del árbol eso no es una fórmula legal, es literal.
- ¿La caché de escritura de la cabina sobrevive a un corte de corriente? MeshXFS lo exige y rechaza el montaje en clúster si no se lo declaras. Si tu respuesta es «creo que sí», la respuesta es no hasta que alguien enseñe la ficha de la batería.
- ¿Has matado dos nodos a la vez, bajo carga? Es la prueba que en MeshXFS encontró defectos que todas las de un solo nodo habían pasado por alto. Matar uno y ver que aguanta es el calentamiento.
- ¿Tienes copias independientes del volumen y las has restaurado? «Guarda copias independientes» es la última línea del aviso de estado de CetraFS, y es la más barata de cumplir. Una copia que no has restaurado es una hipótesis, y aquí la hipótesis es el plan B del plan B.
Y con todo esto, qué haces mañana
Si estás en mitad de una migración de VMware a Proxmox y la cabina es el nudo que no desatas, lo útil no es elegir entre estos dos nombres: es decidir si tu destino lleva LUN compartida o no, porque esa decisión arrastra el vallado, el multipath y los snapshots en bloque. Es media tarde de conversación y se puede tener antes de comprar nada. Si quieres que la tengamos contigo —incluida la cuenta de los no_path_retry de tu cabina actual, que es gratis y suele sorprender—, hablamos.
Fuentes. La existencia y la puesta en circulación de los dos proyectos: artículo de Brandon Lee en Virtualization Howto, 24 de octubre de 2026 (virtualizationhowto.com), única fuente secundaria usada y solo para eso: la existencia de los proyectos. Todo lo demás está leído directamente de los repositorios, descargados el 25 de octubre de 2026. CetraFS (github.com/cetrafs/cetrafs): la definición como «alternativa moderna y abierta a VMFS», el aviso de estado «joven, pre-1.0 […] no curtido en producción como lo están VMFS o ext4 […] guarda copias independientes», la coordinación por un único SCSI COMPARE AND WRITE sobre un registro de 512 bytes con la referencia explícita al ATS de VMFS, los grupos de zonas por nodo, el diario de rehacer, el CRC32C, los 16 TiB por fichero, la ausencia de listas de control de acceso POSIX, la opción nofilelock, la versión 0.6 del empaquetado, el reparto de licencias (módulo GPL-2.0 o posterior; herramientas AGPL-3.0 o posterior o comercial), el requisito de STONITH externo con la frase «no mata a un host partido» y la comparación con el reparto VMFS / vSphere HA, el párrafo del multipath con el encolado de no_path_retry × polling_interval, los 90 segundos de la entrada de fábrica de HPE 3PAR, la ventana de 120 segundos por defecto y el rango 15-240 de stale_secs, el «un paquete construido no es un paquete probado» y que el conjunto de dos nodos es lo único que ejercita los caminos entre nodos. MeshXFS (github.com/sshoecraft/meshxfs): la licencia GPL-2.0 y la base en XFS, la declaración «escrito enteramente por IA […] ningún humano escribió, editó a mano ni revisó línea a línea el código de clustering», la mención de Claude Opus en Claude Code y la delimitación de la parte humana, las quince configuraciones publicadas con su nomenclatura de cuatro campos, el listón de publicación y la cola de defectos pública, la retirada de la 0.90.131, los 66 a 77 segundos que dejaron sin reclamar las configuraciones de 8 y 16 nodos con gestor de candados por red sobre multipath en la 0.90.132, el vallado por reservas persistentes SCSI y el rechazo al montar de dispositivos sin ellas (virtio-blk, NVMe, md), la no verificación de fibra y SAS, el apartado «lo que esto no cubre» con «ninguna versión publicada se ha verificado sobre una cabina de almacenamiento», la excepción de los dos nodos sobre DRBD en máquinas físicas con Proxmox VE 9, los treinta segundos de la prueba de remojo, el «cualquier otro núcleo está sin probar, incluso en la misma distribución» y el hallazgo al matar dos nodos a la vez. Proxmox VE: las citas de la hoja de ruta pública (pve.proxmox.com/wiki/Roadmap, sección Roadmap → Storage & Snapshots) sobre sacar los snapshots como cadenas de volúmenes de la vista previa y sobre mejorar la integración de multipath para fibra e iSCSI, y la fecha de publicación de Proxmox VE 9.0 (5 de agosto de 2025) de la misma página; los 446 días son nuestra cuenta hasta el 25 de octubre de 2026. No hemos probado ninguno de los dos sistemas de ficheros: este artículo lee su documentación, no mide su comportamiento, y lo dice así a propósito.
Microsoft 365
ES 
CAT 
EN