Proxmox « pmxcfs n’est pas monté » : pourquoi /etc/pve est vide et comment récupérer

janvier 14, 2026 • février 3, 2026 • Lecture : 29 min • Views: 10

Cet article vous a aidé ?

Vous vous connectez à un nœud Proxmox et l’interface web a l’air d’avoir tout oublié. Aucune VM. Aucune définition de stockage. Aucun paramètre de cluster. Vous ouvrez un shell et découvrez l’horreur véritable : /etc/pve est vide. Puis vous exécutez une commande au hasard (parce que c’est ce qu’on fait sous stress) et elle affiche : pmxcfs is not mounted.

Cette panne donne l’impression que « mes configs ont disparu ». En général, ce n’est pas le cas. La plupart du temps, vous regardez un système de fichiers de cluster (pmxcfs) mort ou non monté, pas un disque effacé. Le travail consiste à identifier lequel des trois suspects habituels tient le couteau : pve-cluster, corosync ou quorum. Puis récupérer de façon à ne pas scinder silencieusement l’état du cluster et provoquer une catastrophe future.

Ce qu’est réellement pmxcfs (et pourquoi /etc/pve est spécial)

/etc/pve sur Proxmox n’est pas un répertoire normal comme votre mémoire musculaire l’attend. C’est un système de fichiers monté via FUSE appelé pmxcfs (Proxmox cluster filesystem). Le processus qui le monte et le sert fait partie de pve-cluster. Il stocke la configuration à l’échelle du cluster dans une petite base de données et l’expose sous forme de fichiers.

Donc, lorsque vous voyez « pmxcfs is not mounted » et que /etc/pve semble vide, cela signifie généralement :

pmxcfs ne s’est pas monté (service arrêté, crash, problèmes de permissions, problème FUSE).
pmxcfs est monté mais est en mauvais état (verrouillage de la base, corruption ou incapacité à atteindre le quorum du cluster).
vous regardez le point de montage sans le montage (donc vous voyez un répertoire vide sur le système de fichiers racine).

Et oui : vous pouvez aggraver la situation. La mauvaise « solution » peut créer un split-brain, écraser une bonne configuration avec une copie obsolète ou faire diverger définitivement l’état du cluster. Évitez l’improvisation.

Vérité sèche : la configuration Proxmox est « juste des fichiers » et « pas seulement des fichiers ». pmxcfs donne cette impression de simplicité tout en dépendant silencieusement de l’appartenance au cluster corosync et des règles de quorum.

Faits intéressants et contexte historique

pmxcfs est basé sur FUSE : ce n’est pas un système de fichiers noyau ; il fonctionne en espace utilisateur, ce qui signifie que les crashs et échecs de montage ressemblent à une « disparition » du répertoire.
/etc/pve est à l’échelle du cluster : même sur un nœud unique, Proxmox utilise l’abstraction du système de fichiers de cluster pour des outils et un comportement UI uniformes.
Le quorum bloque les écritures : dans les clusters multi-nœuds, pmxcfs peut refuser les écritures sans quorum pour éviter le split-brain.
Corosync vient du monde HA : c’est un système de communication de groupe historiquement utilisé dans les clusters haute disponibilité ; Proxmox l’utilise pour l’appartenance et la messagerie.
Proxmox a hérité de la logique « fichiers comme API » : éditer des fichiers sous /etc/pve revient à appeler l’API de configuration ; l’UI et la CLI convergent vers cet endroit.
pmxcfs conserve une copie locale : les nœuds portent l’état localement, c’est pourquoi un nœud peut souvent récupérer les configs même si le réseau est en feu.
Les clusters à deux nœuds sont historiquement délicats : la mathématique du quorum pénalise les nombres pairs. Proxmox supporte une configuration à deux nœuds, mais vous devez connaître les modes de défaillance.
Le QDevice existe parce que la physique existe : un troisième participant de quorum peut être virtuel (qnetd/qdevice) pour éviter d’acheter un troisième serveur complet.

Une citation qui reste pertinente en exploitation, surtout quand l’UI est vide et que votre pouls monte : l’espoir n’est pas une stratégie. — attribué à Gordon R. Sullivan (paraphrase).

Symptômes qui ressemblent à une perte de données (mais ne le sont généralement pas)

Quand pmxcfs n’est pas monté, vous ne perdez pas seulement la liste d’un répertoire. Les composants Proxmox qui s’attendent à des fichiers de configuration de cluster commencent à échouer en cascade :

L’interface web n’affiche aucune VM/CT, ou retourne des erreurs lors du chargement de la configuration.
pvesm status affiche les stockages manquants parce que /etc/pve/storage.cfg est « introuvable ».
Les fichiers de configuration des VM sous /etc/pve/qemu-server/*.conf semblent absents.
Les commandes de cluster comme pvecm status échouent ou affichent « no quorum ».
Les tâches de sauvegarde, de réplication et de gestion HA se plaignent car elles lisent l’état du cluster.

Voici la question diagnostique clé : Avons-nous perdu les VM, ou avons-nous perdu la vue sur la configuration ? Dans la plupart des cas, les disques/LVM/volumes ZFS sont toujours présents ; seule la couche de configuration est hors ligne.

Blague n°1 : si /etc/pve est vide, ce n’est pas du « minimalisme », c’est votre système de fichiers de cluster qui a pris un jour de congé.

Guide de diagnostic rapide

Lorsque la production est impactée, vous n’avez pas besoin d’un cours. Vous avez besoin d’une boucle serrée : identifiez s’il s’agit d’un problème de montage, d’un service ou d’un quorum. Faites-le dans cet ordre.

Premier point : est-ce que /etc/pve est vraiment monté ?

Si ce n’est pas monté : concentrez-vous sur pve-cluster et les problèmes FUSE/montage.
Si c’est monté mais vide/illisible : concentrez-vous sur la santé de pmxcfs et les logs.

Deuxième point : le service pve-cluster tourne-t-il et est-il sain ?

Si pve-cluster est arrêté ou redémarre : vérifiez les logs pour verrou DB/corruption, problèmes de permissions ou échecs FUSE.

Troisième point : corosync fonctionne-t-il et avez-vous le quorum ?

Si corosync est arrêté : pmxcfs peut ne pas former correctement l’appartenance au cluster.
Si corosync est actif mais pas de quorum : décidez si vous êtes dans une panne multi-nœuds (doit restaurer le quorum) ou dans un environnement nœud unique où vous pouvez temporairement forcer les votes attendus (avec précaution).

Quatrième point : les disques des VM sont-ils toujours là ?

Confirmez que les datasets ZFS, volumes LVM ou contenus de stockage par répertoire existent. S’ils existent, vous traitez probablement un problème de disponibilité de configuration, pas une perte de données.

Cinquième point : choisissez la voie de récupération

Voie cluster : restaurez la connectivité corosync/quorum ; évitez toute étape de « reconstruction » tant que le quorum n’est pas rétabli.
Voie autonome : corrigez les services locaux ; envisagez de restaurer /etc/pve depuis des sauvegardes si la DB pmxcfs est endommagée.

Tâches pratiques : commandes, sorties attendues et décisions

Vous trouverez ci-dessous des tâches réelles avec les commandes, ce que signifient les sorties et la décision à prendre ensuite. Exécutez-les en root ou via sudo. Prenez des notes. Sous stress, vous oublierez ce que vous avez déjà vérifié.

Tâche 1 : Confirmer si pmxcfs est monté

cr0x@server:~$ mount | grep -E '/etc/pve|pmxcfs' || true
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Sens : Si vous voyez pmxcfs on /etc/pve, le montage existe. Si vous ne voyez rien, ce n’est pas monté.

Décision : Si ce n’est pas monté, passez aux vérifications de service (Tâche 3). Si c’est monté mais vide, vérifiez le quorum et les logs de pmxcfs (Tâches 4–7).

Tâche 2 : Vérifier si /etc/pve est vide parce qu’il n’est pas monté

cr0x@server:~$ ls -la /etc/pve
total 0
drwxr-xr-x  2 root root  40 Dec 25 11:03 .
drwxr-xr-x 98 root root  80 Dec 25 10:58 ..

Sens : Un /etc/pve « vide » avec seulement . et .. est typique d’un point de montage non monté sur le système de fichiers racine.

Décision : Traitez cela comme un problème de montage/service, pas comme des configs manquantes. Ne commencez pas à recréer les configs des VM de mémoire.

Tâche 3 : Vérifier le statut du service pve-cluster

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: failed (Result: exit-code) since Thu 2025-12-25 10:59:33 UTC; 2min ago
    Process: 2210 ExecStart=/usr/bin/pmxcfs (code=exited, status=1/FAILURE)
     Main PID: 2210 (code=exited, status=1/FAILURE)

Sens : S’il est en échec, pmxcfs ne sert pas /etc/pve. S’il est actif, passez à corosync/quorum.

Décision : Un service en échec signifie lire les logs et corriger la cause racine avant de redémarrer à l’aveugle.

Tâche 4 : Vérifier le statut du service corosync

cr0x@server:~$ systemctl status corosync --no-pager
● corosync.service - Corosync Cluster Engine
     Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
     Active: active (running) since Thu 2025-12-25 10:55:02 UTC; 6min ago
       Docs: man:corosync
   Main PID: 1020 (corosync)
      Tasks: 9 (limit: 15400)
     Memory: 23.4M

Sens : corosync est votre transport d’appartenance au cluster. S’il est arrêté, le quorum et le comportement de pmxcfs seront affectés.

Décision : Si corosync est inactif/en échec, corrigez-le d’abord (réseau, configuration, certificats ne sont pas le problème ici ; c’est corosync).

Tâche 5 : Vérifier rapidement le quorum avec pvecm

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 25 11:01:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.23
Quorate:          No

Sens : « Quorate: No » est souvent la raison pour laquelle pmxcfs refuse de se comporter en cluster, notamment pour les écritures. Les lectures peuvent aussi être dégradées selon les cas.

Décision : Si vous êtes dans un cluster multi-nœuds et qu’il n’y a pas quorum, concentrez-vous sur la restauration de la connectivité des nœuds ou du qdevice. Évitez les étapes de « reconstruction pmxcfs » tant que le quorum n’est pas rétabli.

Tâche 6 : Vérifier l’appartenance corosync depuis ce nœud

cr0x@server:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
	addr	= 10.10.10.11
	status:
		nodeid:          1:	connected
		nodeid:          2:	disconnected
		nodeid:          3:	disconnected

Sens : Ce nœud ne voit pas ses pairs. C’est généralement un problème réseau ou de pare-feu, ou les pairs sont arrêtés.

Décision : Si les pairs devraient être opérationnels, vérifiez les chemins réseau et le MTU. Si les pairs sont arrêtés, décidez de les remettre en service ou (avec prudence) d’utiliser un contournement de quorum.

Tâche 7 : Lire les logs de pve-cluster pour connaître la raison réelle

cr0x@server:~$ journalctl -u pve-cluster -b --no-pager -n 80
Dec 25 10:59:33 server pmxcfs[2210]: [main] notice: starting pmxcfs
Dec 25 10:59:33 server pmxcfs[2210]: [main] crit: Unable to acquire pmxcfs lock: Resource temporarily unavailable
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Main process exited, code=exited, status=1/FAILURE
Dec 25 10:59:33 server systemd[1]: pve-cluster.service: Failed with result 'exit-code'.

Sens : La contention de verrou peut survenir après un crash ou si un processus obsolète traîne. C’est exploitable.

Décision : Cherchez des processus pmxcfs obsolètes ou un état de verrou laissé ; ne faites pas rm -rf sur des répertoires au hasard comme thérapie.

Tâche 8 : Chercher des processus pmxcfs obsolètes

cr0x@server:~$ ps aux | grep -E 'pmxcfs|pve-cluster' | grep -v grep
root       1987  0.0  0.1  45620  9400 ?        Ss   10:58   0:00 /usr/bin/pmxcfs

Sens : Si pmxcfs tourne déjà, le redémarrer peut échouer avec une erreur de verrou. Si plusieurs pmxcfs existent, c’est le bazar.

Décision : S’il y a un pmxcfs orphelin, arrêtez le service proprement et assurez-vous qu’il termine avant de le redémarrer.

Tâche 9 : Redémarrer les services dans un ordre contrôlé

cr0x@server:~$ systemctl restart corosync
cr0x@server:~$ systemctl restart pve-cluster
cr0x@server:~$ systemctl restart pvedaemon pveproxy

Sens : corosync d’abord (appartenance), puis pmxcfs, puis les démons qui servent l’UI/API.

Décision : Si pve-cluster échoue toujours, retournez aux logs. S’il démarre mais que le quorum est absent, n’éditez pas les configs.

Tâche 10 : Confirmer le montage et le contenu de /etc/pve après redémarrage

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
cr0x@server:~$ find /etc/pve -maxdepth 2 -type f | head
/etc/pve/corosync.conf
/etc/pve/storage.cfg
/etc/pve/user.cfg
/etc/pve/domains.cfg
/etc/pve/qemu-server/101.conf

Sens : Si vous voyez ces fichiers, pmxcfs est monté et sert à nouveau des données.

Décision : Vous pouvez maintenant passer à la réparation de l’état du cluster ou des problèmes d’exécution des VM. Si c’est encore vide, arrêtez-vous et réévaluez.

Tâche 11 : Valider la santé du système de fichiers de cluster et les opérations sur fichiers

cr0x@server:~$ pvecm status | grep -E 'Quorate|Nodes|Name'
Name:             prod-cluster
Nodes:            3
Quorate:          Yes
cr0x@server:~$ test -r /etc/pve/storage.cfg && echo "read ok"
read ok

Sens : Quorum « Yes » plus fichiers lisibles signifie que le système de fichiers de cluster est stable.

Décision : Si Quorate est « No », évitez les modifications de configuration. Si c’est « Yes », poursuivez les opérations normales et le nettoyage.

Tâche 12 : Confirmer que les disques des VM existent toujours (exemple ZFS)

cr0x@server:~$ zfs list -o name,used,avail,mountpoint | grep -E 'rpool/data|vm-'
rpool/data                 128G  1.72T  /rpool/data
rpool/data/vm-101-disk-0   64G   1.72T  -
rpool/data/vm-102-disk-0   64G   1.72T  -

Sens : Les disques existent. Vous avez probablement « perdu » seulement la couche de configuration, pas les données des VM.

Décision : Si les disques sont présents, concentrez-vous sur la récupération des configs ; ne réinitialisez pas le stockage.

Tâche 13 : Confirmer que les disques des VM existent toujours (exemple LVM-thin)

cr0x@server:~$ lvs -a -o lv_name,vg_name,lv_attr,lv_size,data_percent,metadata_percent
LV              VG   Attr       LSize   Data%  Meta%
data            pve  twi-aotz--  <1.80t  42.11  3.02
vm-101-disk-0    pve  Vwi-a-tz--  64.00g
vm-102-disk-0    pve  Vwi-a-tz--  64.00g

Sens : Vos volumes VM sont intacts.

Décision : Ne touchez pas au thin pool. Votre urgence concerne la configuration et la santé du cluster.

Tâche 14 : Chercher des copies de sauvegarde de /etc/pve

cr0x@server:~$ ls -la /var/lib/pve-cluster/
total 20
drwxr-xr-x  5 root root 4096 Dec 25 10:59 .
drwxr-xr-x 50 root root 4096 Dec 25 10:58 ..
drwxr-xr-x  2 root root 4096 Dec 25 10:58 backup
drwxr-xr-x  2 root root 4096 Dec 25 10:59 config
drwx------  2 root root 4096 Dec 25 10:59 db
cr0x@server:~$ ls -la /var/lib/pve-cluster/backup | head
total 64
-rw------- 1 root root 65536 Dec 24 02:05 config-2025-12-24_02_05_01.tar

Sens : Proxmox conserve souvent des sauvegardes locales de la config de cluster. C’est votre parachute « ennuyeux mais efficace ».

Décision : Si la DB pmxcfs est corrompue, restaurer depuis ces sauvegardes locales est généralement plus sûr que de reconstruire les configs à la main.

Tâche 15 : Confirmer le chemin réseau de base pour corosync (knet)

cr0x@server:~$ ip -br addr show
lo               UNKNOWN        127.0.0.1/8 ::1/128
eno1             UP             10.10.10.11/24
eno2             DOWN
cr0x@server:~$ ping -c 2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.412 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.398 ms

--- 10.10.10.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Sens : Si la connectivité de base vers les pairs est rompue, corosync ne formera pas d’appartenance. Si le ping fonctionne mais corosync ne fonctionne pas, pensez pare-feu, MTU ou filtrage de ports.

Décision : Corrigez le réseau avant de toucher à la configuration du cluster. Les problèmes corosync se résolvent rarement en éditant des fichiers au hasard pendant une panne.

Tâche 16 : Vérifier les problèmes de disque ou de système de fichiers qui peuvent planter pmxcfs

cr0x@server:~$ dmesg -T | tail -n 20
[Thu Dec 25 10:57:10 2025] EXT4-fs error (device sda2): ext4_journal_check_start:83: Detected aborted journal
[Thu Dec 25 10:57:10 2025] EXT4-fs (sda2): Remounting filesystem read-only

Sens : Si le système de fichiers racine est remonté en lecture seule, pmxcfs peut échouer à mettre à jour sa DB/son verrou et les services vont se dégrader.

Décision : Arrêtez de traiter cela comme « Proxmox qui fait des siennes ». C’est un problème de stockage. Réparez le disque, remontez et redémarrez si nécessaire.

Trajectoires de récupération (nœud unique vs cluster)

Voie A : Nœud unique (ou « je me fiche de l’appartenance au cluster, je veux mes configs »)

Sur un vrai système Proxmox mono-nœud (ou un nœud que vous avez volontairement détaché du cluster), vous vous souciez surtout de faire fonctionner pve-cluster pour monter pmxcfs et présenter /etc/pve. Le quorum n’est généralement pas le verrou principal comme dans un cluster multi-nœuds.

Causes typiques sur un nœud unique :

pve-cluster n’a pas pu démarrer à cause d’une contention de verrou ou de processus obsolètes.
Le système de fichiers racine est en lecture seule après un problème disque.
La DB pmxcfs est corrompue après un crash ou une coupure de courant.

Ce que je fais en premier : réparer le FS racine et les services. Ce n’est que si les logs indiquent une DB pmxcfs cassée que je restaure depuis une archive locale.

Quand pmxcfs ne monte pas à cause d’un verrou/processus obsolète

Si journalctl mentionne une impossibilité d’acquérir le verrou pmxcfs, identifiez le processus obsolète, arrêtez les services et redémarrez proprement. N’utilisez pas « kill -9 » sauf si l’arrêt normal a échoué et qu’il est bloqué.

cr0x@server:~$ systemctl stop pve-cluster
cr0x@server:~$ pkill -TERM pmxcfs || true
cr0x@server:~$ sleep 2
cr0x@server:~$ ps aux | grep pmxcfs | grep -v grep || echo "no pmxcfs running"
no pmxcfs running
cr0x@server:~$ systemctl start pve-cluster
cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Point de décision : Si cela corrige le problème, vous avez terminé. Si cela échoue de nouveau, vous recherchez un problème plus profond : disque en lecture seule, support FUSE absent ou corruption de la DB.

Quand le système de fichiers racine est passé en lecture seule

C’est un classique : « tout échoue, mais la cause racine est une ligne dans dmesg ». Si ext4 a remonté en lecture seule, vous ne pouvez pas faire confiance à pmxcfs ni à corosync.

Corrigez le problème disque sous-jacent. Cela peut signifier vérifier le SMART, planifier un fsck et redémarrer. Si c’est un nœud Proxmox virtualisé (oui, ça arrive), corrigez aussi le stockage sous-jacent de l’hyperviseur.

Quand la DB pmxcfs est endommagée et que vous devez restaurer la configuration

Si vous avez des sauvegardes locales sous /var/lib/pve-cluster/backup, les restaurer est généralement plus sûr que de reconstruire storage.cfg, les utilisateurs, permissions et configs VM à la main.

Soyez strict : ne le faites que quand vous êtes certain que la configuration locale du nœud est la source de vérité, et non une copie obsolète par rapport aux autres nœuds.

Une méthode pratique consiste à extraire l’archive tar quelque part de façon sûre et comparer ce que vous allez restaurer. Puis procédez avec la méthode de restauration la moins invasive disponible pour votre situation.

cr0x@server:~$ mkdir -p /root/pve-restore
cr0x@server:~$ tar -tf /var/lib/pve-cluster/backup/config-2025-12-24_02_05_01.tar | head
etc/pve/corosync.conf
etc/pve/storage.cfg
etc/pve/user.cfg
etc/pve/qemu-server/101.conf
etc/pve/lxc/103.conf

Point de décision : Si la tar contient la config attendue, vous pouvez restaurer des fichiers sélectionnés une fois pmxcfs monté. Si pmxcfs ne veut pas se monter du tout, il faut réparer pmxcfs d’abord ; déposer des fichiers dans un /etc/pve non monté écrit simplement sur le répertoire vide du FS racine et ne résout rien.

Voie B : Nœud en cluster (c’est là que les gens perdent des weekends)

Dans un cluster, pmxcfs est imbriqué avec l’appartenance corosync et les règles de quorum. La bonne récupération dépend de si :

Ce nœud est isolé mais les autres vont bien.
Le cluster entier est partiellement tombé (nœuds perdus, réseau perdu, qdevice perdu).
Vous avez réellement un risque de split-brain (deux moitiés pensent être primaires).

Règle que j’applique : si vous pouvez restaurer le quorum en remontant les nœuds/le réseau, faites-le. Ne « forcez » pas le quorum en priorité. Forcer le quorum, c’est comme shunter un fusible avec un clou. Ça marche. Ça vous apprend aussi de nouvelles façons d’échouer.

Restaurez la connectivité corosync avant de toucher à /etc/pve

Corosync est sensible à :

Partitions réseau et changements de pare-feu
Incompatibilités MTU (surtout si vous avez activé jumbo frames « pour la performance »)
Mauvais binding d’interface après renommage de NIC ou remplacement matériel
Noms d’hôtes ou IP cassés (surtout si vous avez reconstruit un nœud depuis un template)

Faites communiquer les nœuds. Vérifiez ensuite le quorum. Puis confirmez la santé du montage pmxcfs.

Clusters à deux nœuds et qdevice : la mathématique ne connaît pas votre optimisme

Les clusters à deux nœuds sont possibles, mais ce sont des pièges si vous les traitez comme des clusters à trois nœuds. Si un nœud tombe, vous perdez le quorum à moins d’avoir un qdevice ou d’ajuster temporairement les votes attendus.

Modifier temporairement expected-votes peut vous sortir du pétrin, mais ce sont des manœuvres d’urgence. Elles doivent être inversées quand le cluster revient à la normale. Sinon vous aurez « résolu » le quorum en redéfinissant la réalité, ce qui est une stratégie audacieuse en ingénierie système.

Blague n°2 : Le quorum, c’est comme une réunion : rien n’est décidé tant qu’assez de monde n’est pas présent, et la seule personne là est toujours en colère.

Quand il est (relativement) sûr d’utiliser un contournement d’urgence de quorum

N’utilisez un contournement que si :

Vous êtes certain que les nœuds manquants sont éteints, pas vivants et partitionnés.
Vous acceptez le risque que les modifications de configuration effectuées maintenant puissent entrer en conflit au retour des nœuds.
Vous essayez de restaurer des services pour des VM qui vivent sur ce nœud et vous avez besoin que pmxcfs soit en écriture.

Si vous doutez, n’agissez pas. Réparez le réseau. Remettez les nœuds en service. Rétablissez le quorum normalement.

Trois mini-histoires du monde de l’entreprise

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un cluster Proxmox à trois nœuds et une fenêtre de changement bien ordonnée. Un nœud devait recevoir une mise à jour firmware. Le plan : le sortir, le patcher, le remettre. Standard.

Quelqu’un a constaté que le cluster semblait toujours « sain » dans l’UI après le redémarrage du nœud, donc ils ont poursuivi en rebootant un deuxième nœud pour le mettre à jour aussi. L’hypothèse était simple : « si l’UI est up, le cluster va bien ».

Le second reboot a fait chuter le quorum. pmxcfs sur le nœud restant ne s’est pas monté correctement, et /etc/pve a paru vide. L’UI est passée de « à peu près sain » à « on dirait une installation neuve » en moins d’une minute. La panique a suivi, naturellement.

La mauvaise action suivante : un ingénieur a commencé à recréer des définitions de stockage dans l’UI. Sans quorum, certaines écritures étaient bloquées, d’autres incohérentes, et quelques-unes ont été faites sur un nœud qui s’est avéré ne pas être la meilleure source de vérité.

Quand le second nœud est revenu et que le quorum est revenu, l’état du cluster a convergé — mais pas comme souhaité. Ils ont passé le reste de la nuit à démêler des stocks en double, des configs VM obsolètes et des définitions conflictuelles. Rien n’était « perdu », mais ce n’était certainement pas « correct ».

Ce qui a résolu le problème : ils ont annulé les modifications improvisées, restauré la configuration originale depuis une archive de sauvegarde connue bonne, puis réintroduit les nœuds un par un en vérifiant le quorum et la santé du montage pmxcfs. La leçon n’était pas « ne jamais redémarrer des nœuds ». C’était « ne jamais prendre l’UI pour un oracle de quorum ».

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une équipe voulait moins de latence entre les nœuds pour corosync, le trafic Ceph et la migration à chaud. Ils ont concentré le trafic de cluster sur un VLAN « plus rapide » et activé les jumbo frames. Ça fonctionnait en labo. Bien sûr que ça fonctionnait.

En production, un chemin de commutateur ne supportait pas silencieusement le MTU bout en bout. Le ping fonctionnait parce que les petits paquets s’en fichent. Corosync fonctionnait parfois, puis oscillait, puis déclarait des pairs morts. Les nœuds apparaissaient et disparaissaient comme des collègues peu fiables.

Sur un des nœuds, pmxcfs se démontait de façon intermittente ou refusait des opérations à cause de l’appartenance/quorum instable. Les opérations voyaient le symptôme : /etc/pve vide, VMs manquantes dans l’UI, « pmxcfs is not mounted ». Les ingénieurs stockage voyaient le symptôme plus profond : une couche d’appartenance au cluster qui oscillait sous charge.

L’« optimisation » a créé un modèle de panne pire qu’une panne nette. C’était une panne en accéléré : assez stable pour que les gens modifient des choses, assez instable pour corrompre leur modèle mental.

La correction était ennuyeuse : revenir à MTU 1500 sur l’anneau corosync, séparer le trafic corosync du trafic de stockage massif, et valider avec des tailles de paquets réelles. L’équipe a réintroduit les jumbo frames plus tard seulement lorsque le support bout en bout était prouvé, avec de la surveillance pour les stats de liens corosync. La performance est revenue plus tard. La stabilité est revenue immédiatement.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la journée

Une autre organisation avait une habitude : chaque nœud exécutait un job nocturne qui copiait /var/lib/pve-cluster/backup hors du cluster vers une cible de stockage indépendante. Pas sophistiqué. Juste constant.

Ils tenaient aussi un petit « carnet de sinistre » : inventaire des nœuds, nom du cluster, adresses de l’anneau corosync, et une page « comment confirmer le quorum ». C’était écrit par quelqu’un qui ne faisait pas confiance à la mémoire, y compris la sienne.

Pendant un incident électrique, un nœud est revenu avec des erreurs de système de fichiers racine et pmxcfs a refusé de se monter. L’UI n’affichait rien. Mais ils n’ont pas cherché à tout reconstruire. Ils ont vérifié les montages, vérifié corosync, et confirmé que les autres nœuds détenaient encore le quorum.

Ils ont reconstruit le nœud défaillant avec une nouvelle installation OS, puis l’ont rejoint au cluster en utilisant les informations stockées. Après cela, ils ont restauré les éléments spécifiques à l’hôte et validé que pmxcfs affichait la configuration correcte du cluster. Les VM n’ont pas été affectées car leur stockage était sur des backends partagés.

Ce qui a « sauvé la journée » n’était pas un truc astucieux. C’était d’avoir des sauvegardes de configuration constantes et un runbook ennuyeux. Ils n’ont pas fait les héros. Ils ont suivi le processus et sont rentrés chez eux à une heure raisonnable, ce qui est le vrai luxe.

Erreurs fréquentes : symptôme → cause → correction

Cette section est opinionnée parce que les mêmes erreurs se répètent chez les équipes. Certaines sont compréhensibles. La plupart sont évitables.

Erreur 1 : « /etc/pve est vide, donc les configs ont été supprimées »

Symptôme : ls /etc/pve n’affiche rien ; l’UI n’affiche aucune VM.

Cause : pmxcfs n’est pas monté. Vous regardez un point de montage vide sur le système de fichiers sous-jacent.

Correction : Vérifiez mount | grep /etc/pve, puis corrigez pve-cluster et corosync/quorum.

Erreur 2 : Recréer des configs alors que le quorum est perdu

Symptôme : Les choses « reviennent » mais maintenant les storages/VMs sont dupliqués, ou les permissions sont bizarres.

Cause : Vous avez modifié la configuration du cluster dans un état dégradé/sans quorum. Plus tard, le cluster s’est réconcilié avec d’autres nœuds et vous avez obtenu une config Frankenstein.

Correction : Restaurez le quorum d’abord. Si vous devez modifier la config en mode d’urgence, documentez chaque changement et prévoyez de réconcilier après le retour du quorum.

Erreur 3 : Redémarrer des services au hasard en espérant

Symptôme : Parfois ça marche, parfois non ; les redémarrages de pveproxy n’aident pas.

Cause : pveproxy/pvedaemon dépendent de pmxcfs pour la configuration. Redémarrer l’UI ne montera pas le système de fichiers.

Correction : Commencez par corosync et pve-cluster. Ensuite redémarrez les démons UI.

Erreur 4 : Éditer des fichiers sous /etc/pve quand il n’est pas monté

Symptôme : Vous avez « corrigé » /etc/pve/storage.cfg mais rien ne change dans l’UI.

Cause : Vous avez écrit dans le répertoire brut du FS racine, pas dans pmxcfs.

Correction : Vérifiez le montage d’abord. Si pmxcfs n’est pas monté, vos modifications sont allées au mauvais endroit. Supprimez les fichiers factices après la restauration pour éviter la confusion.

Erreur 5 : Traiter un cluster à deux nœuds comme s’il avait redondance de quorum

Symptôme : Vous perdez un nœud, le nœud restant devient non-quorate, le comportement de pmxcfs se dégrade.

Cause : Les clusters à deux nœuds ont besoin d’un qdevice ou d’une gestion fine des votes.

Correction : Ajoutez un qdevice, ou acceptez que la perte d’un nœud entraîne une perte de quorum et planifiez les opérations en conséquence.

Erreur 6 : « Corriger » en supprimant la DB pmxcfs sans plan

Symptôme : pmxcfs démarre, mais la config est réinitialisée ou incohérente ; l’identité du cluster change ; les nœuds ne s’accordent plus.

Cause : Vous avez effacé l’état local du cluster sans comprendre si ce nœud était autoritatif ou comment il va resynchroniser.

Correction : N’effectuez des actions destructrices sur la DB que lorsque vous avez identifié le(s) nœud(s) autoritatif(s) et que vous disposez de sauvegardes. Préférez la restauration depuis /var/lib/pve-cluster/backup quand c’est approprié.

Erreur 7 : Ignorer les erreurs de disque sous-jacentes

Symptôme : pmxcfs/corosync oscillent, le système de fichiers racine passe en lecture seule, les services échouent de manière étrange.

Cause : Problème réel de stockage ou de corruption du système de fichiers.

Correction : Arrêtez et réparez le disque. Aucun redémarrage de service ne soignera un système de fichiers remonté en lecture seule.

Listes de contrôle / plan étape par étape

Checklist 1 : Triage immédiat (10 minutes, sans héros)

Vérifiez le montage : mount | grep /etc/pve.
Vérifiez pve-cluster et corosync status.
Vérifiez le quorum : pvecm status.
Consultez les logs : journalctl -u pve-cluster -b -n 80 et journalctl -u corosync -b -n 80.
Confirmez que les disques existent (ZFS/LVM). Cela évite la panique destructive.

Checklist 2 : Si pmxcfs n’est pas monté

Vérifiez que le FS racine est inscriptible : regardez dmesg -T | tail pour des événements de remontage en lecture seule.
Arrêtez pve-cluster proprement ; cherchez des processus pmxcfs obsolètes.
Démarrez corosync (si cluster) puis démarrez pve-cluster.
Confirmez que /etc/pve est monté et non vide.
Seulement après le montage de pmxcfs : redémarrez pveproxy/pvedaemon.

Checklist 3 : Si corosync/quorum est le problème

Confirmez la reachabilité réseau et les bonnes adresses IP de l’interface corosync.
Vérifiez l’appartenance : corosync-cfgtool -s.
Remettez les nœuds manquants si possible ; restaurez l’appartenance normale.
Si cluster à deux nœuds : assurez-vous que le qdevice est joignable, ou reconnaissez que vous devez faire un changement d’expected-votes en urgence (et notez précisément vos modifications).
Après restauration du quorum : validez que /etc/pve affiche les fichiers attendus et que les nœuds s’accordent sur l’état du cluster.

Checklist 4 : Si la DB pmxcfs semble corrompue

Arrêtez et capturez des preuves : logs, états des services et copies des tars de sauvegarde.
Identifiez le nœud autoritatif (dans un cluster : celui ayant un quorum sain et la config attendue).
Utilisez les sauvegardes depuis /var/lib/pve-cluster/backup lorsque c’est approprié ; évitez la reconstruction manuelle à moins d’aimer les erreurs subtiles.
Validez les fichiers critiques : corosync.conf, storage.cfg, qemu-server/*.conf, ACL/configs utilisateur.
Remontez les services, validez l’UI, puis validez le mapping réel des disques VM avant de relancer les charges.

FAQ

1) Pourquoi /etc/pve devient vide au lieu d’afficher les anciens fichiers ?

Parce que /etc/pve est un point de montage. Quand pmxcfs n’est pas monté, vous regardez le répertoire sous-jacent sur le système de fichiers racine, qui est typiquement vide.

2) Mes disques de VM sont-ils supprimés quand /etc/pve est vide ?

Habituellement non. Les disques VM résident sur des datasets ZFS, des volumes LVM, Ceph RBD ou des répertoires ailleurs. Vérifiez avec zfs list, lvs ou vos outils backend avant de conclure à une perte de données.

3) Puis-je simplement redémarrer pour corriger « pmxcfs is not mounted » ?

Parfois. Mais si la cause est une erreur disque, une partition réseau ou une config corosync cassée, redémarrer revient souvent à répéter la même panne avec plus de temps d’indisponibilité.

4) Si corosync est arrêté, pmxcfs peut-il quand même se monter ?

Sur un nœud de cluster, le comportement de pmxcfs est fortement couplé à l’état du cluster. Il peut se monter mais être dégradé, refuser les écritures ou se comporter de façon incohérente. Traitez les pannes corosync comme prioritaires tant que l’inverse n’est pas prouvé.

5) Quelle est la première commande la plus sûre quand je vois cette erreur ?

mount | grep /etc/pve et systemctl status pve-cluster corosync. Vous voulez savoir si c’est un problème de montage, de service ou de quorum/appartenance.

6) Puis-je éditer directement les fichiers /etc/pve pour récupérer ?

Oui — quand pmxcfs est monté et que le cluster est sain/quorate. Non — quand il n’est pas monté, car vous éditerez le mauvais emplacement et créerez de la confusion.

7) Et si un seul nœud montre /etc/pve vide mais les autres sont corrects ?

Ce nœud est probablement isolé, mal configuré réseau ou a un problème local de service/disque. Comparez l’appartenance corosync et les logs. Ne « réparez le cluster » pas depuis le nœud cassé.

8) Comment éviter que cela devienne un incident plus grave la prochaine fois ?

Gardez des sauvegardes de configuration hors du cluster, surveillez le quorum et l’état des liens corosync, évitez les optimisations réseau risquées sans validation bout en bout, et entraînez-vous aux procédures de perte de nœud.

9) « pas de quorum » signifie-t-il toujours que /etc/pve sera vide ?

Non. « pas de quorum » affecte généralement la capacité à valider les modifications et peut déclencher un comportement dégradé, mais un /etc/pve vide suggère fortement que pmxcfs n’est pas monté ou ne fonctionne pas.

10) Dois-je supprimer et réajouter le nœud au cluster ?

Seulement après avoir confirmé si l’état local du nœud est corrompu et si le cluster est stable. Le ré-ajout est parfois la bonne réponse, mais c’est une étape de dernier recours, pas une hypothèse de départ.

Prochaines étapes à effectuer réellement

Si vous avez remonté pmxcfs et que /etc/pve est peuplé à nouveau, ne vous arrêtez pas là. La phase « tout a l’air ok » est où se cachent les problèmes latents.

Confirmez la stabilité du quorum et de l’appartenance pendant quelques minutes. Si corosync oscille, vous n’avez pas fini.
Validez la cohérence de la configuration entre les nœuds : définitions de stockage, configs VM et permissions.
Confirmez que les disques VM sont mappés correctement avant de relancer des charges critiques. Un décalage de config peut pointer une VM vers le mauvais disque.
Exportez hors du cluster des sauvegardes de /var/lib/pve-cluster/backup si ce n’est pas déjà fait.
Notez la cause racine et la correction exacte appliquée. Le vous du futur est un inconnu fatigué.

L’objectif n’est pas seulement de « récupérer l’UI ». L’objectif est de restaurer un plan de contrôle cohérent, quoré et durable pour éviter que calcul et stockage ne dérivent en légendes d’exploitation.