Proxmox VE n’a pas de système de fichiers en cluster comme VMFS, celui qui permet dans VMware à plusieurs hôtes de partager un même LUN d’un SAN, et l’entreprise qui le développe n’a pas prévu d’en créer un. Le vulgarisateur Brandon Lee a relancé le débat le 24 octobre avec une question directe, Proxmox en a-t-il besoin ?, et avec l’analyse de deux projets communautaires qui tentent de combler le vide : CetraFS et MeshXFS. Les deux fonctionnent, mais aucun n’est prêt pour la production.
Les points clés du débat sur un VMFS pour Proxmox en 20 secondes
- Proxmox Server Solutions écarte pour l’instant un système de fichiers en cluster propre.
- La voie officielle avec un SAN est un LVM partagé en mode épais, ou Ceph sans baie de stockage.
- CetraFS en est à la version 0.6 et MeshXFS à la 0.90.132, toutes deux antérieures à la 1.0.
- Les deux exigent des baies compatibles, du fencing et des tests avant de leur confier des données.
La question pèse surtout chez les entreprises qui quittent VMware après la hausse des prix de Broadcom. Dans vSphere, il suffit de présenter un LUN iSCSI ou Fibre Channel à tous les hôtes et de le formater en VMFS pour disposer d’un stockage partagé avec disques à provisionnement léger, snapshots et migration à chaud. VMFS coordonne l’accès de chaque hôte avec des verrous atomiques dans la baie elle-même (ATS) pour que personne n’écrive par-dessus un autre. Dans Proxmox, cette baie reste utilisable, mais il faut concevoir le stockage autrement.
La position officielle de Proxmox
Proxmox Server Solutions n’a annoncé aucun système de fichiers en cluster, pas même en aperçu. En janvier 2026, un membre de l’équipe Proxmox a répondu sur le forum officiel à un utilisateur qui demandait un équivalent de VMFS que l’entreprise n’a pas prévu d’en développer, car cela exigerait un effort considérable. Il a aussi expliqué qu’OCFS2 et GFS2, les deux systèmes de fichiers en cluster historiques de Linux, ont été évalués et ne bénéficient pas d’un support officiel : OCFS2 en raison de problèmes avec le noyau et GFS2 parce qu’il oblige à redémarrer l’hôte si Corosync, la couche de communication du cluster, se coupe brièvement. Certains utilisateurs emploient bien OCFS2 dans des clusters de huit nœuds, mais à leurs propres risques.
La recommandation officielle est d’utiliser LVM en mode épais sur le LUN partagé, comme stockage en mode bloc, avec multipath. Depuis Proxmox VE 9.0, publié en août 2025, ce LVM prend en charge les snapshots au moyen de chaînes de volumes, mais sans thin provisioning. L’autre voie est Ceph, qui répartit les données entre les disques des nœuds eux-mêmes et qui, selon Proxmox, ne doit pas être monté par-dessus un SAN car cela annule sa redondance. Nous avons déjà passé en revue les options de stockage partagé dans Proxmox, y compris un plugin de LVM Thin partagé de la communauté.
CetraFS : un VMFS ouvert construit de zéro
CetraFS, développé par Massimo Cetra, se définit comme une alternative ouverte à VMFS. C’est un module du noyau hors de l’arbre principal avec ses propres outils (mkfs.cetra, fsck.cetra et defrag.cetra). Les nœuds se coordonnent par l’intermédiaire de la baie elle-même avec la commande atomique SCSI COMPARE AND WRITE, la même idée que l’ATS de VMFS, sans gestionnaire de verrous par le réseau. Chaque nœud est propriétaire de ses propres groupes de zones pour allouer l’espace, utilise un journal par nœud pour se rétablir après des coupures et protège chaque structure sur disque par des sommes de contrôle CRC32C. Il gère des fichiers allant jusqu’à 16 TiB, des images à provisionnement léger et la migration à chaud avec Proxmox, et dispose d’un plugin de stockage intégré à l’interface web.
Son dépôt est clair sur les limites. La version est la 0.6, il est décrit comme jeune et antérieur à la 1.0, il n’a été testé qu’avec les noyaux 7.0.14 et 7.1.8 de Debian (celui de Proxmox VE appartient à la même famille) et il demande des sauvegardes indépendantes. Sans baie dotée de COMPARE AND WRITE, le volume ne peut être monté que sur un seul nœud ; Brandon Lee a vérifié avec sg3-utils qu’un volume iSCSI de TrueNAS le prend en charge, mais toutes les baies et toutes les cibles iSCSI logicielles ne le font pas. Pour plusieurs nœuds en production, CetraFS exige en outre un gestionnaire de cluster externe qui isole les hôtes défaillants (STONITH), et prévient que le multipath peut retenir les E/S pendant 90 secondes sur certaines baies, ce pourquoi il fixe une fenêtre de 120 secondes avant de considérer un nœud comme mort. Son auteur reconnaît avoir utilisé une assistance par IA après avoir conçu l’architecture.
MeshXFS : un XFS en cluster écrit par l’IA
MeshXFS, de Steve Shoecraft, part du code de XFS du noyau Linux et y ajoute ce qui est nécessaire pour que plusieurs nœuds le montent en lecture et en écriture en même temps : verrouillage des métadonnées, cohérence du cache, fencing par réservations persistantes SCSI et récupération des journaux. Il est sous licence GPL-2.0, propose deux modes de coordination, un gestionnaire de verrous par le réseau ou des verrous sur disque avec COMPARE AND WRITE, et prend en charge DRBD en mode primaire double pour les clusters de deux nœuds sans SAN. Il est distribué sous forme de module DKMS pour Proxmox VE 9.1 et 9.2, RHEL 9, Ubuntu et Debian, avec son plugin pour Proxmox.
Le projet se distingue par la manière dont il a été réalisé : selon son dépôt, tout le code de cluster, de verrouillage distribué et de fencing a été écrit par des agents d’IA, principalement Claude Opus dans Claude Code, et non par une personne assistée par l’IA. Sa documentation de tests est détaillée. La version 0.90.132 a été validée avec 2, 4, 8 et 16 nœuds sur un LUN iSCSI partagé, avec une batterie de 31 tests ainsi que des pannes de chemin en multipath, et sur trois hôtes Proxmox VE 9 avec migration à chaud et coupures d’alimentation. Le projet documente lui-même ses problèmes : il a retiré la version 0.90.131 après avoir détecté une erreur susceptible de laisser des incohérences, et exclut la configuration à 8 et 16 nœuds avec verrouillage par le réseau sur multipath car, lorsqu’un nœud quittait le cluster, les autres restaient bloqués entre 66 et 77 secondes.
Pourquoi Proxmox pourrait en avoir besoin
Brandon Lee soutient qu’un système de fichiers en cluster avec support officiel aiderait les organisations qui quittent VMware et disposent déjà d’un SAN payé, car cela leur éviterait de repenser leur stockage ou d’acheter du matériel pour Ceph. Il ne désigne pas de vainqueur entre les deux projets et insiste sur le fait que, avec des données en cluster, la fiabilité compte plus que les fonctions. La comparaison montre des approches différentes : CetraFS est une conception propre pensée pour les machines virtuelles et dépend toujours de la baie pour se coordonner, tandis que MeshXFS s’appuie sur XFS, peut se coordonner par le réseau et couvre le cas de deux nœuds avec DRBD.
L’argument contraire se trouve dans la réponse de Proxmox : un système de fichiers en cluster est coûteux à construire et à maintenir, et les tentatives existantes sous Linux n’ont pas apporté la stabilité que l’entreprise exige. En attendant, le LVM épais partagé avec snapshots et Ceph sont les options prises en charge. Pour qui veut essayer CetraFS ou MeshXFS, le plus prudent est un laboratoire avec la même baie qu’en production, de vérifier la compatibilité avec COMPARE AND WRITE, de provoquer des pannes de nœuds et de chemins, et de toujours conserver des sauvegardes en dehors de ce volume.
Questions fréquentes
Proxmox a-t-il un équivalent de VMFS ?
Non. Proxmox propose un LVM partagé en mode épais avec snapshots depuis la version 9.0, et Ceph, mais pas de système de fichiers en cluster sur un SAN. L’entreprise a dit sur son forum qu’elle n’a pas prévu d’en développer un.
Pourquoi Proxmox n’utilise-t-il pas OCFS2 ou GFS2 ?
Selon son équipe, il les a évalués et ne leur apporte pas de support officiel : OCFS2 en raison de problèmes avec le noyau et GFS2 parce qu’il oblige à redémarrer l’hôte si Corosync se coupe brièvement.
Que sont CetraFS et MeshXFS ?
Deux systèmes de fichiers en cluster open source avec plugin pour Proxmox. CetraFS est une conception propre inspirée de VMFS et MeshXFS adapte XFS avec du code de cluster écrit par des agents d’IA.
Peut-on les utiliser en production ?
Leurs propres auteurs ne le recommandent pas encore. CetraFS en est à la 0.6, MeshXFS à la 0.90.132, et tous deux exigent des baies compatibles, du fencing et des sauvegardes indépendantes.
Sources :
