There is a piece that has been missing from VMware migrations for years: the filesystem that lets several servers mount the same LUN at once and put the machines' disks on top of it. This week two candidates started circulating together; neither of them was born this week. Both are free software, both package for Debian, and both write things in their own README that we do not remember reading in the public documentation of any array we have operated. The one that settles the conversation is MeshXFS's, and it fits on one line: "no release has been verified on a storage array".
The gap you have felt since leaving VMware
VMFS is not glamorous, but it does one very specific and very hard thing: several hosts mount the same block volume at the same time — an iSCSI or Fibre Channel LUN — and the virtual machines' disks live as files on top of that volume. That is what gives you central storage, machine movement between hosts without copying anything, and per-file snapshots. When you leave vSphere with the array still being written down, that is the piece with no obvious replacement.
Proxmox VE can share a LUN: you put LVM on it and the logical volumes become visible to the whole cluster. What you do not have is a filesystem, and therefore you do not have files either: you have thick volumes, and for years you had no snapshots. We wrote about that a few weeks ago, in moving to Proxmox with your array and finding that the snapshot does not travel. That is the gap, and that is where both projects have landed.
CetraFS: the array itself does the coordination
CetraFS introduces itself bluntly as "a clustered, shared-disk filesystem for Linux — a modern, open alternative to VMFS". It is an out-of-tree kernel module plus three userspace tools (mkfs.cetra, fsck.cetra, defrag.cetra), with 0.6 as the version the repository packages. The interesting part is how the nodes agree: there is no network. Every contested claim — the namespace lock, the whole-file open lock, node registration, zone-group ownership, a bitmap bit — is a single atomic SCSI COMPARE AND WRITE on one 512-byte record. It is the same idea as VMFS's ATS, and the project says so itself.
The feature list is serious: a per-node redo journal, CRC32C verified by the kernel on read, sparse files up to 16 TiB, and a nofilelock mount option so an image can be open on two nodes during a Proxmox live-migration handoff. It has no POSIX ACLs. And the project writes its own status, in bold, before anything else: "young, pre-1.0. Heavily reviewed, fuzzed and crash-tested, but not production-aged the way VMFS or ext4 are. Built and tested on Linux 7.0.14 and 7.1.8+deb13 […]. Keep independent backups." Those two kernels are the whole list; hold on to that for the fourth check below.
MeshXFS: XFS with clustering on top, and a declaration of authorship
The second project is MeshXFS (GPL-2.0), and it takes a different route: it starts from the kernel's XFS and adds what is needed for several nodes to mount the same device read-write. It brings a lock manager over the network or over the disk — again COMPARE AND WRITE — a DKMS module and a storage plugin for Proxmox VE. And it carries a paragraph on its front page that we had never read in a repository of this kind: "MeshXFS was written entirely by AI, across many development sessions. No human wrote, hand-edited, or line-by-line reviewed the clustering code." It names the lead agent — Claude Opus running autonomously in Claude Code, which wrote "a large share" of the code — and it also names the models it consulted on the hardest problems, lock-protocol design, recovery races and fencing correctness: Claude Fable, GPT, Gemini and Astra, of which it writes that without them the project would never have been completed. And it bounds the human part: "directing the work, setting the requirements and running the testing, not writing the implementation". The project states its purpose literally as finding out whether AI could write a device driver this complex.
Our position on that, since it will be the only thing anyone comments on: it is the least interesting question the repository raises. A clustered filesystem is not judged by who typed it, but by what has survived and by what its author admits has not been tested. And on exactly that, MeshXFS documents better than most paid products. It declares fifteen released configurations, named in a four-field format (nodes/class/method/attach), and the bar for releasing one is explicit: no open defect that can lose data or crash, hang or shut down a node. The defect queue is public and is read with a tool in the repository itself. With one caveat the file does not resolve: its table says all fifteen were verified on 0.90.132, and a few sections further down the examples for that same tool say several network-lock-manager configurations were last verified on 0.90.130. It does not agree with itself, and we point that out precisely because it is the document we are praising.
Two examples that the bar is not decorative. Version 0.90.131 was withdrawn: checks that finished after it was published found it could leave an entry pointing at an inode another node had just freed, and the project writes that it should not have been published before those checks finished. And in 0.90.132 the eight-node configuration with the network lock manager over multipath stopped being claimed, because when a node left the cluster the others waited on one directory's lock for 66 to 77 seconds. The sixteen-node one was withdrawn alongside it, unmeasured, until the fix is verified there too. No operation failed and nothing was lost; even so, the project calls it a defect and withdraws the claim. That is the behaviour you would like to see on your vendor's support portal.
The uncomfortable question: who kills the partitioned host?
This is where the subject stops being about storage and becomes about architecture, and where the two projects answer the same question differently. A shared filesystem survives as long as only the right node writes. When a node is isolated but still alive with the LUN in front of it, somebody has to actually kill it. CetraFS says it without make-up: for multi-node production you need an external cluster manager providing host fencing (STONITH), because its own mechanism is a heartbeat timeout and self-fencing of the reclaimed node, but it "does not kill a partitioned host". And it adds the comparison that explains everything: it is "the same split of responsibility as VMFS (storage lease) and vSphere HA (host isolation)".
There is the thesis of the whole thing: what you lost when you left vSphere was not VMFS, it was the two halves coming from the factory sharing one clock. If you replace only the storage one and take the other for granted, you have half a cluster. MeshXFS answers differently: it fences the dead node with SCSI persistent reservations on the LUN itself, except on DRBD and in hypervisor-shared-disk mode, where fencing is done by an external authority — an IPMI, a managed PDU, the hypervisor itself — or by operator confirmation. A practical and under-discussed consequence: a device without persistent reservations (virtio-blk, NVMe, a software RAID with md) is refused at mount. With no prior warning: it simply does not mount.
In Proxmox the other half does exist: the high-availability manager watchdog-fences the node that loses quorum. But it exists if you have configured it, and it has its own clock, which is not the filesystem's. The distance between those two clocks is exactly where data is lost, and we covered it when we explained why Proxmox HA does not prevent the outage, it shortens it.
The 120 seconds almost nobody has looked at
The most valuable fragment in either repository is in CetraFS's requirements, in the multipath section, and it describes a trap that is not about new software: it is about how dm-multipath has always worked. When every path to the LUN drops, multipath does not fail the I/O: it queues it for no_path_retry × polling_interval seconds. The project gives the stock entry for an HPE 3PAR as its example: 90 seconds. And it adds the part few people connect: during those 90 seconds the node cannot send its heartbeat either, because the heartbeat is queued behind the same dead paths.
With that in place the sequence writes itself. If multipath's queueing lasts longer than the filesystem's stale window, the other nodes declare the silent node dead and reclaim its zone groups while its writes are still pending. Then the paths come back, the queue drains, and those writes land on space that now belongs to somebody else. CetraFS sets the default window at 120 seconds, precisely so the stock 90 fits inside it, and lets you tune it between 15 and 240 — always at least three times the heartbeat interval — with stale_secs.
The actionable part is for this afternoon and does not depend on installing anything: look at your effective multipath configuration with multipath -t, find the no_path_retry and polling_interval that apply to your array, multiply them and keep the number. It is worth being precise about what it means. The corruption window CetraFS describes also needs a filesystem that reclaims another node's space; if you run shared thick LVM today, the volumes have a fixed owner and you do not have that window. What you do have is the number: it governs how long your I/O hangs before erroring, and therefore how long everything above it takes to react, starting with Proxmox's high-availability watchdog and continuing with the timeouts inside the guest. That it is written in the README of a pre-1.0 project and not in your vendor's guide is, frankly, the most uncomfortable part of all this.
The two of them, side by side
The sentence that settles the conversation
MeshXFS has a section titled "what this does not cover", and it opens with this: "Every shared-storage node is a virtual machine. The development rig and the platform sets are KVM guests on one host, and the shared LUNs are iSCSI LUNs served from that host. No release has been verified on a storage array." The only exception it admits is the two-node DRBD configuration, additionally verified on two physical Proxmox VE 9 hosts with their own local disks.
Put that together with the rest the same section admits and the picture is complete: Fibre Channel and SAS are not verified; only the kernels and cluster sizes the front page names one by one — "any other kernel is untested, even on the same distribution" — the soak test runs for thirty seconds unless a longer one is asked for, and power loss at the storage is out of scope because the write cache is required to survive it. And one more sentence, the kind you write down: "the first time two nodes were killed at once, under load, it found defects that every single-death row had passed over".
CetraFS does not make that declaration because it publishes no list of verified configurations, but neither does it claim the opposite: its automated suite runs on loop-backed images, "never a real device", and the destructive or real-hardware suites are opt-in and have to be pointed at a device by hand. Neither of them, therefore, can show you a verified array today. Translated into the decision in front of you: if you are leaving VMware with a Fibre Channel array — the case we run into most — today neither of them covers you. One has not verified your transport; the other has not verified any array, of any kind. This is not a reproach to the projects, which say so themselves and on their front page.
The official option also carries the preview label
Before this sounds like free software lagging behind: Proxmox's official answer to the same problem is in the same place. Proxmox VE 9.0 (5 August 2025) introduced snapshots as volume chains, which is exactly what lets you snapshot machines on shared thick-provisioned LVM storage, the kind typically sitting on an iSCSI or Fibre Channel LUN. It shipped marked as a technology preview. Today, 25 October 2026, it is still marked the same: the project's public roadmap says so, with the goal of "bring snapshots as volume chains (tech preview since Proxmox VE 9.0) out of tech preview on LVM-thick, Directory, NFS, and CIFS storages, including support for online removal of the top-most snapshot" still on the to-do list. That is 446 days with the label on.
And a few lines further down, in the same roadmap section, there is another pending item that describes the whole terrain: "improve multipath integration and setup experience for Fibre Channel and iSCSI deployments". In other words, the three roads available today for putting an array underneath a Proxmox cluster — the two new filesystems and the official route — all three carry the word "yet", in writing. The difference between them is not maturity: it is who you call when it breaks, and that is a management decision, not a sysadmin one.
What we would do, and when we would touch none of it
We run Proxmox VE with Ceph in production, in more than one room, and we have moved companies from VMware to Proxmox; we have also said no to migrations that did not add up. With that said, what we would do today with an array in front of us comes down to one question: whether the hardware is written down or not.
If the array has years left, it stays: shared thick LVM for the machines' disks, and the volume-chain preview enabled first on a storage that holds nothing critical, with the backup plan intact. It is less elegant than a filesystem, but plenty of people have walked that path. If the hardware needs replacing anyway, the conversation moves: with local disks in the nodes and Ceph distributed storage the shared LUN disappears, and with it the filesystem problem, the fencing problem and the whole multipath window. What does not disappear is the cost: Ceph has its own rules, it starts at three nodes, and it is worth knowing what it does and does not do when you lose a piece, which is what we covered in a three-node Ceph does not heal itself, it holds on.
With CetraFS and MeshXFS we do recommend one thing: test them. In a lab, with data that does not matter, killing nodes in pairs and reporting what comes out; both run a defect queue and a release process that turn a well-made report into a real improvement. What we would not do — and there is no nuance here — is put them under production this week because they worked in the lab. A thirty-second soak test says nothing about next Tuesday.
Seven checks before letting a clustered filesystem near a production LUN
- Is your transport on the verified list? Not the implemented list: the list verified in the release you are about to install. Fibre Channel and SAS are not on MeshXFS's. CetraFS requires atomic COMPARE AND WRITE, and you can probe without mounting anything:
modprobe cetrafs caw_probe=<device>and check indmesgthatmax_caw_blocksis at least 1. - Who kills the partitioned host, with which device, and in how many seconds? If you cannot name the device — an IPMI, a managed PDU, a hypervisor, a SCSI reservation — you do not have fencing: you have a timeout and good luck.
- Multiply
no_path_retrybypolling_interval(visible withmultipath -t) and compare it against the filesystem's stale window. If the product is larger, you will have a corruption window the day you mount one of these. If you run thick LVM today, what you have is I/O hanging for longer than your HA takes to declare the node dead, which is not harmless either. - Is your exact kernel version on the list? The kernel, not the distribution. "Any other kernel is untested, even on the same distribution", and for an out-of-tree module that is not legal boilerplate, it is literal.
- Does the array's write cache survive a power loss? MeshXFS requires it and refuses a clustered mount unless you declare it. If your answer is "I think so", the answer is no until somebody produces the battery datasheet.
- Have you killed two nodes at once, under load? That is the test that found defects in MeshXFS which every single-node test had passed over. Killing one and seeing it hold is the warm-up.
- Do you have independent copies of the volume, and have you restored them? "Keep independent backups" is the last line of CetraFS's status notice, and it is the cheapest one to honour. A copy you have not restored is a hypothesis, and here the hypothesis is the plan B behind the plan B.
And with all this, what do you do tomorrow
If you are in the middle of a VMware to Proxmox migration and the array is the knot you cannot untie, the useful move is not picking between these two names: it is deciding whether your destination has a shared LUN at all, because that decision drags fencing, multipath and snapshots along with it. It is half an afternoon of conversation and you can have it before buying anything. If you want us to have it with you — including working out your current array's no_path_retry figure, which is free and usually surprises people — let us talk.
Sources. The existence and circulation of both projects: Brandon Lee's article on Virtualization Howto, 24 October 2026 (virtualizationhowto.com), the only secondary source used and only for that: the existence of the projects. Everything else is read directly from the repositories, downloaded on 25 October 2026. CetraFS (github.com/cetrafs/cetrafs): the description as "a modern, open alternative to VMFS", the status notice "young, pre-1.0 […] not production-aged the way VMFS or ext4 are […] keep independent backups", coordination by a single SCSI COMPARE AND WRITE on one 512-byte record with the explicit reference to VMFS's ATS, per-node zone groups, the redo journal, CRC32C, 16 TiB per file, the absence of POSIX ACLs, the nofilelock option, the 0.6 packaging version, the licence split (module GPL-2.0-or-later; tools AGPL-3.0-or-later or commercial), the external STONITH requirement with the phrase "it does not kill a partitioned host" and the comparison with the VMFS / vSphere HA split, the multipath paragraph with queueing for no_path_retry × polling_interval, the 90 seconds of the stock HPE 3PAR entry, the 120-second default window and the 15-240 range of stale_secs, "a built package is not a tested one", and that the two-node suite is the only thing exercising cross-node paths. MeshXFS (github.com/sshoecraft/meshxfs): the GPL-2.0 licence and the XFS base, the declaration "written entirely by AI […] no human wrote, hand-edited, or line-by-line reviewed the clustering code", the mention of Claude Opus in Claude Code and the bounding of the human part, the fifteen released configurations with their four-field naming, the release bar and public defect queue, the withdrawal of 0.90.131, the 66 to 77 seconds that left the 8- and 16-node network-lock-manager-over-multipath configurations unclaimed in 0.90.132, fencing by SCSI persistent reservations and the mount refusal for devices without them (virtio-blk, NVMe, md), the non-verification of Fibre Channel and SAS, the "what this does not cover" section with "no release has been verified on a storage array", the two-node DRBD exception on physical Proxmox VE 9 hosts, the thirty-second soak test, "any other kernel is untested, even on the same distribution", and the finding from killing two nodes at once. Proxmox VE: the quotations from the public roadmap (pve.proxmox.com/wiki/Roadmap, Roadmap → Storage & Snapshots section) about bringing snapshots as volume chains out of tech preview and about improving multipath integration for Fibre Channel and iSCSI, and the Proxmox VE 9.0 release date (5 August 2025) from the same page; the 446 days are our own count to 25 October 2026. We have not tested either filesystem: this article reads their documentation, it does not measure their behaviour, and it says so deliberately.
Microsoft 365
ES 
CAT 
EN