Proxmox clustering storages has been a very changing topic in 2026, with several new developments and improvements finally bringing more possibilities to the table. However, when looking at the bigger picture, there are still some gaps compared to what we have been used to in the VMware world. One of the golden rules in VMware environments has always been VMFS, providing a shared clustered filesystem that allows multiple ESXi hosts to access the same storage and run virtual machines on top of it. In Proxmox VE, we still lack a similarly straightforward solution that covers all the typical use cases.
Of course, this does not mean that we have no alternatives. Linux has offered clustered filesystems such as GFS2 and OCFS2 for years. Both are established technologies, but they are not really the first choice for most Proxmox environments with virtualization based workloads. We could also look at distributed filesystems like Lustre or BeeGFS, but these are often far too complex for smaller clusters. They introduce additional components, operational overhead, and requirements that can quickly become excessive when all we really want is shared storage for virtual machines.
Another option is Ceph, which is well integrated into Proxmox VE and provides distributed storage with features such as replication and self-healing. However, Ceph also requires a certain amount of infrastructure, resources, and operational knowledge. Not every environment needs a distributed storage system, and many administrators already have dedicated SAN infrastructure available that they want to continue using.
For a long time, the typical approach for shared block storage has been to use technologies such as iSCSI, Fibre Channel (FC), or NVMe over Fabrics (NVMe-oF), with a thick-provisioned LVM on top. This is a well-established setup and works reliably for many environments. However, compared to what VMware administrators are used to, there have been some limitations, especially when it comes to snapshots and thin provisioning. With Proxmox VE 9, things started to change. The introduction of snapshot support for shared LVM storage through snapshot volume chains was an important step forward. It finally became possible to use snapshots with shared, thick-provisioned LVM without having to switch to a completely different storage backend. Still, one important piece was missing: thin provisioning at the LVM layer.
This is where I wanted to take things a step further. I have developed a shared LVM thin-provisioning storage plugin for Proxmox VE, bringing thin provisioning to shared block storage setups. The idea is to make better use of existing SAN infrastructure while keeping the familiar LVM approach and avoiding the need to deploy an entirely new distributed storage stack. Combined with the recent improvements in Proxmox VE 9, this opens up new possibilities for environments that need shared storage, snapshots, and more efficient capacity usage.
Looking back at 2026, the Proxmox storage ecosystem is clearly moving forward. There is still no universal replacement for VMFS that fits every scenario, but we now have more options than before. For me, the next step is making these solutions easier to deploy, maintain, and integrate into everyday Proxmox clusters. Not every environment needs Ceph, and not every administrator wants to introduce a complex clustered filesystem just to get the features expected from a modern virtualization platform. So, let's have a deeper look at the current market situation where we will focus at the following solutions:
- Shared LVM Thin
- rbdmirror
- MeshXFS
- CetraFS
Shared LVM Thin
Shared block storage has been a recurring topic when discussing Proxmox VE as an alternative to VMware. Many enterprise environments already rely on existing storage infrastructures based on iSCSI, Fibre Channel (FC), or NVMe over Fabrics (NVMe-oF). Replacing the virtualization platform should not necessarily mean replacing the entire storage architecture as well.
For a long time, administrators had to choose between shared LVM without thin provisioning and local LVM-Thin with support for thin provisioning, snapshots, and linked clones. Neither option covered all the requirements of environments that wanted to use their existing shared SAN infrastructure. Thick provisioning can waste a significant amount of capacity because the full configured size of a virtual disk must be allocated upfront, even when the guest only uses a fraction of it.
With Proxmox VE 9 and the introduction of snapshot volume chains, snapshot support for shared, thick-provisioned LVM became available. This was an important improvement, but thin provisioning remained a missing piece for many deployments.
This is where my Shared LVM Thin storage plugin for Proxmox comes into play. Instead of trying to activate a single LVM thin pool simultaneously on multiple cluster nodes, the plugin creates a dedicated thin pool for each guest inside the shared LVM volume group. Since a virtual machine or container normally runs on only one node at a time, its thin pool can be activated exclusively on that node. When the guest migrates, the pool is deactivated on the source node before being activated on the destination node.
This approach allows virtual disks to use thin provisioning while keeping the underlying block storage accessible across the cluster. The plugin also integrates with Proxmox VE's storage operations, including snapshots, rollbacks, disk resizing, templates, linked clones, and other common disk lifecycle operations. Thin pools can grow as required, with cluster-wide locking used to protect operations that modify shared LVM metadata.
Another important aspect is usability. The plugin is implemented as a custom Proxmox VE storage backend and can be managed through the command line and API. An additional web interface integration makes it possible to configure the storage directly through the familiar Datacenter and Storage menus.
The plugin is distributed as a Debian package, so it can be installed using the standard package management tools instead of requiring administrators to manually copy files and configure the integration. The Shared LVM Thin plugin is also available through the gyptazy Debian repository, making installation and future updates easier.
The main goal is to provide another option for environments that want to keep their existing SAN infrastructure while benefiting from thin provisioning and snapshots. This does not remove the need to monitor physical capacity, validate multipath behavior, and test migration and recovery scenarios, but it makes shared block storage more flexible for Proxmox VE clusters.
rbdmirror
MeshXFS
MeshXFS is a new open-source, POSIX-compatible clustered filesystem built on top of XFS. It aims to solve a common challenge in virtualization environments: allowing multiple nodes to access the same shared block device concurrently in read-write mode. In one of my recent blog posts, I also covered more details and the installation steps of MeshXFS on Proxmox VE 9 clusters.
In the VMware world, VMFS has been the established solution for this use case for years. On Linux, there are alternatives, but there is still no single, straightforward solution that fits every Proxmox VE environment. GFS2 and OCFS2 have been around for a long time, but they are not necessarily the first choice for new deployments. Distributed filesystems such as BeeGFS and Lustre offer powerful capabilities, but their architecture and operational complexity can be excessive for smaller clusters.
For many Proxmox VE environments, shared LVM has therefore been the typical alternative when working with external block storage. However, this approach has its own limitations, which is why I also developed the Shared LVM Thin plugin. MeshXFS explores a different direction: instead of allocating individual virtual disks through LVM, it provides a clustered filesystem that multiple hosts can mount on the same shared block device.
The project builds on the upstream Linux kernel XFS implementation and adds the clustering mechanisms required for concurrent access. These include distributed locking, fencing, coordination, and journal recovery. MeshXFS supports shared iSCSI SAN storage and dual-primary DRBD configurations, with network-based locking or on-disk coordination using SCSI COMPARE AND WRITE.
According to the project documentation, shared iSCSI configurations have been validated with 2, 4, 8, and 16 nodes. This makes the project particularly interesting for environments that already operate shared block storage and want to explore concurrent filesystem access without introducing a complete distributed storage system.
One particularly interesting aspect of MeshXFS is its development approach. The clustering, coordination, distributed locking, fencing, and recovery code was fully vibe-coded using AI agents, while the underlying XFS implementation originates from the upstream Linux kernel. This makes MeshXFS an interesting example of how AI-assisted development can be used to build infrastructure software and explore solutions to long-standing problems.
MeshXFS also provides DKMS-based Debian packages for supported systems, including Proxmox VE 9, Debian 12 and 13, RHEL 9, and Ubuntu 24.04 and 26.04. The DKMS approach allows the kernel module to be built for the installed kernel, provided the matching headers and supported kernel version are available. An additional Debian package provides a dedicated Proxmox VE storage plugin, making the filesystem easier to integrate into the web interface.
This means that MeshXFS can be installed directly using the shipped Debian packages rather than requiring administrators to compile and install every component manually. Once the packages are installed on the participating nodes, the shared device can be initialized, mounted, and registered as shared storage in Proxmox VE.
However, MeshXFS is still a young project. Its performance, recovery behavior, fencing mechanisms, and suitability for production workloads need to be evaluated carefully. As with any clustered filesystem, correct storage configuration and reliable fencing are essential. For now, it is an interesting candidate for lab environments, testing, and further development. For more information, visit MeshXFS on GitHub.
CetraFS
CetraFS is another approach to bringing shared-disk clustered filesystem capabilities to Linux and Proxmox VE. Like MeshXFS, it aims to allow multiple nodes to mount the same shared block device concurrently, with virtual machine disk images stored directly on the filesystem. The overall idea is similar to what administrators have been using with VMFS in VMware environments for years.
However, CetraFS has a different technical background and development approach. Rather than extending an existing filesystem such as XFS, CetraFS is developed as an independent filesystem with its own on-disk format, kernel module, and userspace tools. Its design focuses on shared block storage, coordinated allocation, crash consistency, and the requirements of virtualization workloads.
One of the central components is its use of atomic SCSI COMPARE AND WRITE operations for coordination between nodes. This allows competing operations to be coordinated through the storage device itself, rather than depending on a separate network-based locking service. The approach is conceptually similar to the atomic storage operations used by VMFS for coordinating access to shared storage.
CetraFS includes per-node write-ahead journals, checksums for on-disk structures, sparse-file support, and tools for filesystem checking and maintenance. It also uses per-node allocation groups to reduce contention when multiple nodes allocate space concurrently. For virtual machine workloads, it aims to support shared disk images, online migration workflows, and concurrent access where the appropriate locking and migration options are configured.
Unlike MeshXFS, CetraFS does not build on the upstream XFS filesystem implementation. It is an independent implementation with its own filesystem structures and recovery logic. This means the two projects explore different technical approaches to the same broader problem: making shared block storage usable as a concurrent filesystem in Linux virtualization clusters.
I have also been involved in the CetraFS project, particularly in bringing it closer to Proxmox VE users. One part of this work has been the Proxmox VE storage plugin and web interface integration. The aim is to make CetraFS manageable through the familiar Proxmox VE interface, instead of requiring administrators to perform every step manually through the command line.
The project provides Debian packages for the filesystem's DKMS kernel module and userspace tools. The packages can be installed through the gyptazy Debian repository, which also makes updates and installation on multiple cluster nodes more convenient. Additional packages provide the Proxmox VE storage plugin and its web interface integration. This allows administrators to install the components using standard Debian package management and then configure the storage within Proxmox VE. I recently contributed to the project a native Proxmox Web UI integration for CetraFS via PR#1.
There are important limitations to consider. CetraFS is a young, pre-1.0 project and is not yet as production-mature as established filesystems such as VMFS or ext4. Concurrent mounting also depends on suitable storage hardware supporting atomic COMPARE AND WRITE operations. Production deployments require appropriate host fencing, and multipath configurations must be checked carefully to ensure that path failures cannot lead to unsafe recovery behavior.
As with MeshXFS, CetraFS should be tested thoroughly before being used for critical production workloads. Crash recovery, concurrent access, migration, hardware failures, and fencing need to be validated in the target environment. Independent backups remain essential. For more information, visit CetraFS but Massimo Cetra is also quickly responding to geedback via Reddit.
Installing the Projects Through Debian Packages
An important aspect of these projects is that administrators do not have to manually compile every component or integrate the storage backends themselves. Shared LVM Thin, MeshXFS, and CetraFS provide Debian packages that simplify installation on supported systems. The packages can be installed using standard Debian tools, making it easier to deploy the components consistently across multiple Proxmox VE nodes.
Shared LVM Thin and CetraFS are also available through the gyptazy Debian repository. This provides a convenient way to install the packages and receive updates through the regular APT workflow. For clustered environments, the required packages must be installed on every node that is expected to use the respective storage backend.
MeshXFS provides its own Debian packages through its project releases. These include the filesystem kernel module and, optionally, the Proxmox VE storage plugin. Administrators should always check the release documentation for supported kernel versions and installation requirements before deploying the packages.
Packaging and integration are important parts of making these projects practical. A storage backend is not just about the filesystem or the block device itself. Administrators also need a reliable installation process, compatibility with kernel updates, consistent configuration across cluster nodes, and a way to manage the storage through the tools they already use.
Conclusion
Looking at Proxmox cluster storage in late 2026, it is clear that there is more than one direction in which the ecosystem is evolving. Shared LVM Thin focuses on making existing SAN infrastructure more efficient through thin provisioning and snapshots. MeshXFS explores concurrent shared access by extending XFS with clustering capabilities. CetraFS takes the independent-filesystem approach, with its own coordination mechanisms, on-disk format, and Proxmox VE integration. The rbdmirror project addresses another area and will be covered separately.
These projects are not direct replacements for one another. They address different requirements and come with different architectural trade-offs. Some environments need thin-provisioned virtual disks on an existing SAN, while others want a filesystem that multiple nodes can mount concurrently. The right choice depends on the existing infrastructure, operational requirements, and the level of complexity an environment is prepared to manage.
Compared to the VMware ecosystem, Proxmox VE still has a different approach to shared storage, and there is no single solution that covers every use case. However, these developments show that the available options are expanding. With Debian packages, repository-based installation, and integration into the Proxmox VE web interface, the projects are also becoming easier to test and evaluate.
All of these solutions still require appropriate testing before production use, especially regarding recovery, fencing, and failure scenarios. Nevertheless, it is encouraging to see new approaches emerging around Proxmox VE shared storage rather than treating the existing limitations as something administrators simply have to accept. I hope to provide a webinar or live demo at our next Virtualization Gathering at credativ GmbH to showcase some of them!