Proxmox « Impossible d’activer le stockage » : diagnostiquer LVM, NFS et CIFS correctement

Ce que signifie réellement « unable to activate storage » dans Proxmox

Dans Proxmox, le « stockage » est une abstraction pilotée par plugin qui couvre des réalités très différentes : un groupe de volumes LVM local, un export NFS monté, un montage CIFS, des LUN iSCSI, des pools ZFS, des chemins de répertoire, etc. Quand Proxmox indique qu’il ne peut pas « activer » un stockage, cela signifie généralement une de ces choses :

• Le backend n’est pas présent (VG introuvable, montage absent, chemin manquant).
• Le backend est présent mais inutilisable (permissions, handle obsolète, lecture seule, options incorrectes, échec d’authentification).
• Proxmox ne peut pas exécuter l’étape d’activation (outil manquant, commande qui échoue, ordre des services, contention de verrou).
• Le nœud se croit responsable alors que non (mismatch de config de cluster, définitions de stockage spécifiques au nœud, symptômes de split-brain).

L’essentiel est de le traiter comme un incident SRE : définir le périmètre d’impact (un nœud ou tous), isoler le backend en échec, collecter des preuves, puis modifier une variable à la fois.

Une citation à garder sur votre mur :

« L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan

Le dépannage du stockage est l’endroit où l’espoir vient mourir. C’est bien. Ça vous oblige à mesurer.

Blague #1 : Les incidents de stockage sont comme des tout-petits : plus ils crient fort, plus il est probable que le problème soit quelque chose de basique que vous avez ignoré.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Si vous êtes de garde et que vous avez besoin d’informations rapidement, ne commencez pas par éditer des configs Proxmox au hasard. Faites ceci :

Premier : confirmer l’étendue et l’ID de stockage spécifique

• Est-ce un nœud ou plusieurs ?
• Est-ce une entrée de stockage ou toutes ?
• Est-ce seulement le démarrage des VM, ou aussi des conteneurs et des sauvegardes ?

Objectif : nommer précisément le stockage en échec (son ID dans Proxmox) et identifier le(s) nœud(s) affecté(s).

Second : valider la vérité au niveau OS (montages/VG/chemins), pas les impressions de l’interface

• Pour NFS/CIFS : est-ce réellement monté au chemin attendu ?
• Pour LVM : le VG existe-t-il et les LV sont-ils visibles ?
• Pour tout : pouvez-vous lire/écrire le chemin en root ?

Objectif : prouver si le backend existe et est utilisable depuis le shell du nœud.

Troisième : consultez les logs des tâches Proxmox et le journal pour la chaîne d’erreur exacte

• Proxmox encapsule les erreurs du backend. Le message wrapper est rarement la solution.
• Trouvez la commande sous-jacente qui a échoué (mount, vgchange, lvcreate, etc.).

Objectif : obtenir l’erreur précise : « permission denied », « no such device », « protocol not supported », « unknown filesystem type », « wrong fs type », « stale file handle », « timed out ». Cette chaîne détermine l’action suivante.

Faits et contexte intéressants (parce que l’histoire se répète)

1. LVM2 est devenu la norme sur Linux après les leçons de LVM1 et des gestionnaires de volumes des fournisseurs ; c’est stable, mais l’activation dépend de la découverte des périphériques et du timing udev.
2. NFSv3 est essentiellement sans état, ce qui explique pourquoi il peut « fonctionner » jusqu’à ce qu’il cesse soudainement puis récupère de manière étrange ; NFSv4 a changé le modèle avec des sessions avec état.
3. « Stale file handle » est un classique NFS qui date de plusieurs décennies : c’est essentiellement un client qui détient une référence d’inode que le serveur ne reconnaît plus.
4. SMB1 (CIFS) était un désastre de sécurité et les systèmes modernes le désactivent souvent ; une négociation de dialecte SMB incompatible cause silencieusement des échecs de montage.
5. systemd a changé l’ordre des montages pour beaucoup d’administrateurs habitués à sysvinit ; ce qui « fonctionnait au démarrage » peut maintenant échouer sauf si les dépendances sont déclarées.
6. Systèmes de fichiers cluster et stockages partagés sont des problèmes différents ; Proxmox partage la configuration via corosync, mais votre stockage doit rester atteignable et cohérent.
7. Multipath et LVM ne s’aiment pas automatiquement ; si vous activez des VG sur les mauvais périphériques sous-jacents, vous pouvez créer une détection de PV dupliquée ou des bizarreries de « device mismatch ».
8. L’optimisation NFS peut casser la correction quand on s’amuse avec le cache ou les timeouts ; le bug le plus rapide reste un bug.

Triage : identifier le backend et l’étendue de la panne

Avant d’aller en profondeur : identifiez quel type de stockage Proxmox pense activer. Les entrées de stockage Proxmox vivent dans la config du cluster, mais l’activation se fait sur chaque nœud. C’est pourquoi un nœud peut échouer alors que les autres vont bien.

Règle pratique : si le stockage Proxmox est « Directory », « NFS » ou « CIFS », les échecs se traduisent généralement par des problèmes de montage ou des permissions. Si le stockage est « LVM » ou « LVM-thin », les échecs correspondent à la découverte des périphériques, à l’activation du VG ou au verrouillage.

Décidez aussi si vous êtes en mode « restauration de service » ou « conservation des preuves ». En restauration, vous privilégiez le redémarrage des VM sans aggraver la prochaine panne. En mode forensique, vous préservez les preuves et modifiez moins. Choisissez-en un ; n’oscillez pas toutes les 10 minutes.

LVM : échecs d’activation qui ressemblent à des problèmes Proxmox

Les défaillances LVM sont souvent ennuyeuses et locales : le nœud ne voit pas le bloc de périphérique, le VG n’est pas actif, ou LVM est confus sur quel périphérique est le vrai PV. Proxmox rapporte « unable to activate storage » parce que, de son point de vue, le plugin de stockage LVM ne peut pas faire son travail.

Catégories courantes d’échecs LVM

• VG introuvable : le périphérique PV n’est pas présent (disque manquant, iSCSI non connecté, multipath non prêt).
• VG existe mais inactif : l’activation n’a pas eu lieu au démarrage ou a échoué à cause d’un verrou.
• PVs dupliqués : même LUN visible via plusieurs chemins sans configuration multipath adéquate.
• Problèmes de thin pool : métadonnées thin pleines, pool en lecture seule, ou activation bloquée par des erreurs.
• Problèmes de filtre : device filters dans lvm.conf excluent les vrais périphériques, la découverte est incohérente.

Que signifie « activer » pour LVM en termes Proxmox

Pour le stockage LVM-thin, Proxmox attend que le groupe de volumes soit découvrable et que le thin pool LV soit actif. Il exécutera des commandes LVM en arrière-plan. Si ces commandes renvoient non-zéro, Proxmox vous donne l’erreur générique.

Si vous dépannez LVM, votre première question devrait être : « Le nœud voit-il le périphérique bloc, et LVM est-il d’accord ? » Pas « Que dit l’interface ? »

NFS : montages qui échouent, se bloquent ou mentent

NFS est populaire dans Proxmox car c’est simple : montez un export et traitez-le comme un répertoire. Il échoue aussi de façons qui ressemblent à des bugs Proxmox mais qui sont en réalité des problèmes réseau, DNS, pare-feu, exports serveurs ou négociation de version.

Catégories d’échecs NFS qui déclenchent « unable to activate storage »

• Le montage n’a jamais lieu : adresse serveur erronée, chemin d’export incorrect, pare-feu, services RPC bloqués.
• Le montage a lieu mais est en lecture seule : options d’export ou mappage de permissions côté serveur (root squash, mapping UID).
• Stale file handle : modifications côté serveur (remount du fs, bascule, promotion de snapshot) invalidant les handles.
• Timeouts qui ressemblent à des blocages : I/O NFS bloqué peut bloquer les tâches Proxmox et rendre le nœud « lent » plutôt que « down ».
• Mauvaise version NFS : le client tente v4 alors que le serveur ne supporte que v3 (ou vice versa), ou v4 exige un agencement d’export différent.

Avec NFS, « activer » revient essentiellement à « s’assurer que le montage est présent et réactif ». Un point de montage existant mais non réactif est pire qu’un échec propre car il fait planter des processus en sommeil I/O non interrompable.

CIFS/SMB : authentification, dialectes et la cruelle joie des permissions

CIFS dans Proxmox, c’est juste « monter un partage SMB et le traiter comme un répertoire ». Ce qui signifie que chaque nuance SMB devient votre problème : négociation de dialecte (SMB2/3), NTLM vs Kerberos, trust de domaine, rotation de mot de passe et sémantique de propriété des fichiers.

Catégories d’échecs CIFS

• Échecs d’authentification : identifiants incorrects, mot de passe expiré, problèmes de domaine, changements de politique NTLM.
• Incompatibilité de dialecte : le serveur désactive des versions SMB anciennes ; le client a des valeurs par défaut différentes ; le durcissement casse les montages.
• Bizarreries de mapping de permissions : monté mais root ne peut pas écrire à cause des ACL serveur ou des options de montage.
• Surprises DFS/referrals : vous avez monté un chemin qui redirige et maintenant il ne fonctionne plus.
• « Fonctionne manuellement, échoue dans Proxmox » : parce que Proxmox utilise des options de montage spécifiques ou lit les identifiants depuis un fichier avec des permissions incorrectes.

Blague #2 : Les permissions SMB sont comme la politique de bureau : tout le monde affirme que c’est « simple », et puis rien ne fonctionne tant que Carol n’a pas donné son accord.

Tâches pratiques : commandes, sorties attendues et décisions (12+)

Ces tâches sont ordonnées approximativement du « signal rapide » au « détail profond ». Exécutez-les sur le nœud affecté en premier. Si c’est un cluster, comparez un nœud fonctionnel avec un nœud en échec — comparer la réalité est sous-estimé.

Task 1: Confirm which storage Proxmox thinks is failing

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       1024000000        12345678       987654321        1.2%
nfs-backup        nfs     inactive              0               0               0          0%
lvm-thin          lvmthin inactive              0               0               0          0%

Ce que cela signifie : « inactive » ici est la vue de Proxmox, pas un diagnostic. Ça vous indique quels ID de stockage cibler (par ex. nfs-backup, lvm-thin).

Décision : Choisissez un ID de stockage en échec et suivez la section correspondant au backend. Ne tentez pas de tout corriger en tirant dans tous les sens.

Task 2: Inspect the storage definition as Proxmox sees it

cr0x@server:~$ pvesm config nfs-backup
nfs-backup: nfs
        export /exports/proxmox-backup
        path /mnt/pve/nfs-backup
        server 10.20.30.40
        content backup,iso
        options vers=4.1

Ce que cela signifie : Vous obtenez le point de montage et les paramètres serveur/export que Proxmox utilisera de manière autoritaire.

Décision : Valider que le point de montage existe et s’il est monté, et vérifier la connectivité réseau vers l’IP/hostname du serveur.

Task 3: Check Proxmox task logs for the real error

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:0000A1B2:0001C3D4:676D0F00:vzdump::root@pam:
UPID:pve01:0000A1B3:0001C3D5:676D0F10:mount::root@pam:storage=nfs-backup:

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pve-storage -n 200 --no-pager
Dec 26 10:11:12 pve01 pvestatd[1234]: storage 'nfs-backup' is not online
Dec 26 10:11:13 pve01 pvedaemon[2345]: storage activate failed: mount error(13): Permission denied

Ce que cela signifie : Vous chassez l_errno sous-jacent : ici c’est permission denied (error(13)) venant de sémantiques de type CIFS ou contrôle d’accès côté serveur.

Décision : Stop. « Permission denied » ne se résout pas en redémarrant. Vérifiez les identifiants/permissions d’export.

Task 4: Validate the mountpoint state (NFS/CIFS/dir)

cr0x@server:~$ findmnt /mnt/pve/nfs-backup
TARGET             SOURCE                    FSTYPE OPTIONS
/mnt/pve/nfs-backup 10.20.30.40:/exports/proxmox-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Ce que cela signifie : Si findmnt ne renvoie rien, ce n’est pas monté. Si ça renvoie NFS/CIFS mais que le système continue de produire des erreurs, le montage peut être obsolète ou avoir des permissions incorrectes.

Décision : Si non monté, tentez un montage contrôlé et capturez l’erreur exacte. Si monté, testez la réactivité I/O.

Task 5: Test read/write and detect “hung mount” fast

cr0x@server:~$ timeout 5 bash -c 'ls -la /mnt/pve/nfs-backup >/dev/null; echo OK'
OK

Ce que cela signifie : Si cette commande dépasse le délai, le montage est bloqué. C’est un problème réseau/serveur (ou une session morte), pas Proxmox.

Décision : Pour les montages bloqués, n’exécutez pas de jobs de sauvegarde « pour voir si ça se débloque ». Réparez la connectivité ou démontez/remontez en sécurité.

Task 6: Check basic network reachability (don’t overthink it)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.482 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.455 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Ce que cela signifie : Ping n’est pas une preuve de santé NFS/SMB, mais un échec est un fort indice que vous traquez la mauvaise couche.

Décision : Si ping échoue, vérifiez routage/VLAN/pare-feu avant de toucher la config de stockage.

Task 7: NFS-specific: verify exports visible from the client

cr0x@server:~$ showmount -e 10.20.30.40
Export list for 10.20.30.40:
/exports/proxmox-backup 10.20.30.0/24

Ce que cela signifie : Si l’export n’apparaît pas (ou que showmount met du temps), la config d’export côté serveur / services RPC / pare-feu est en cause.

Décision : Corrigez la config d’export NFS du serveur ou les règles du pare-feu ; ne « corrigez » pas Proxmox pour un serveur qui vous refuse l’accès.

Task 8: NFS-specific: attempt a manual mount with explicit version/options

cr0x@server:~$ umount /mnt/pve/nfs-backup 2>/dev/null || true
cr0x@server:~$ mount -t nfs -o vers=4.1,proto=tcp,timeo=600,retrans=2 10.20.30.40:/exports/proxmox-backup /mnt/pve/nfs-backup
cr0x@server:~$ dmesg | tail -n 8
[123456.789012] nfs: server 10.20.30.40 OK

Ce que cela signifie : Un montage manuel isole Proxmox de l’équation. Si le montage manuel échoue, le backend est en cause. S’il réussit, comparez les options avec la config Proxmox.

Décision : Si le montage manuel ne marche qu’avec une valeur différente de vers= ou d’autres options, mettez à jour les options de stockage Proxmox en conséquence.

Task 9: CIFS-specific: validate credentials file permissions and contents

cr0x@server:~$ ls -l /etc/pve/priv/storage/cifs-prod.pw
-rw------- 1 root root 64 Dec 26 09:55 /etc/pve/priv/storage/cifs-prod.pw
cr0x@server:~$ sed -n '1,5p' /etc/pve/priv/storage/cifs-prod.pw
username=svc_proxmox
password=REDACTED
domain=CORP

Ce que cela signifie : Proxmox attend que les fichiers d’identifiants soient lisibles uniquement par root. De mauvaises permissions peuvent faire échouer les montages ou divulguer des secrets.

Décision : Si les permissions ne sont pas 600, corrigez-les. Si les identifiants ont changé, mettez-les à jour et prévoyez une procédure de rotation des mots de passe.

Task 10: CIFS-specific: manual mount with explicit SMB dialect and security

cr0x@server:~$ umount /mnt/pve/cifs-prod 2>/dev/null || true
cr0x@server:~$ mount -t cifs //fileserver01/proxmox -o credentials=/etc/pve/priv/storage/cifs-prod.pw,vers=3.0,sec=ntlmssp,uid=0,gid=0,file_mode=0660,dir_mode=0770 /mnt/pve/cifs-prod
cr0x@server:~$ findmnt /mnt/pve/cifs-prod
TARGET           SOURCE                    FSTYPE OPTIONS
/mnt/pve/cifs-prod //fileserver01/proxmox  cifs   rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=svc_proxmox,uid=0,gid=0,file_mode=0660,dir_mode=0770

Ce que cela signifie : Si ajouter vers=3.0 règle le problème, votre serveur a probablement désactivé des dialectes plus anciens. Si sec= est important, la politique de domaine a changé.

Décision : Alignez les options de stockage Proxmox sur ce qui marche réellement, et coordonnez-vous avec l’équipe du serveur de fichiers pour qu’ils ne vous « durcissent » pas hors service.

Task 11: LVM: check whether the VG and thin pool exist

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve        1   7   0  wz--n-  930.00g  12.00g
  vg_vmdata  1   2   0  wz--n-    3.64t  120.00g

cr0x@server:~$ lvs -a -o +devices vg_vmdata
  LV          VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  thinpool    vg_vmdata twi-aotz--  3.40t             62.10  4.20                             /dev/sdb(0)
  thinpool_tmeta vg_vmdata ewi-aotz-- 8.00g                                                   /dev/sdb(870912)
  thinpool_tdata vg_vmdata ewi-aotz-- 3.40t                                                   /dev/sdb(2048)

Ce que cela signifie : Le VG existe, et le thin pool est actif (twi-a). Si vous voyez twi--- sans a, il n’est pas actif. Si le VG est manquant, le périphérique bloc sous-jacent n’est pas visible ou découvert.

Décision : Si le VG est manquant : vérifiez disques/iSCSI/multipath. Si le thin pool est inactif : tentez l’activation et inspectez les erreurs.

Task 12: LVM: attempt controlled activation and capture errors

cr0x@server:~$ vgchange -ay vg_vmdata
  1 logical volume(s) in volume group "vg_vmdata" now active

Ce que cela signifie : L’activation réussie est immédiate et explicite. Si elle échoue, LVM vous dira pourquoi (verrouillage, PV manquants, duplications).

Décision : Si l’activation réussit, revérifiez pvesm status. Si elle échoue, suivez la chaîne d’erreur — n’improvisez pas.

Task 13: LVM: detect missing PVs or duplicate device paths

cr0x@server:~$ pvs -o+pv_uuid,pv_name,vg_name,dev_size
  PV         VG        Fmt  Attr PSize  PFree  PV UUID                                DevSize
  /dev/sdb   vg_vmdata lvm2 a--  3.64t 120.00g 9Hk3vS-9Qb8-1x2c-7y5n-ABCD-ef01-2345  3.64t

Ce que cela signifie : Si vous voyez le même PV UUID sur plusieurs périphériques (commun avec un multipath mal configuré), LVM refusera d’avancer ou se comportera de façon imprévisible.

Décision : Corrigez le multipath pour n’utiliser qu’un seul chemin (généralement /dev/mapper/mpathX), puis ajustez les filtres LVM si nécessaire.

Task 14: Check kernel and systemd logs around mounts and LVM

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 60
Dec 26 09:42:01 pve01 systemd[1]: mnt-pve-nfs\x2dbackup.mount: Mount process exited, code=exited, status=32/n/a
Dec 26 09:42:01 pve01 kernel: CIFS: VFS: cifs_mount failed w/return code = -13
Dec 26 09:42:02 pve01 lvm[987]: device-mapper: thin: Data device (dm-3) discard granularity larger than a block: disabling discards

Ce que cela signifie : systemd vous donne les statuts de sortie, les logs noyau montrent les codes de retour de montage, et LVM émet des indices device-mapper qui peuvent indiquer des problèmes au niveau bloc sous-jacent.

Décision : Si l’unité de montage systemd a échoué, vérifiez les options de montage et l’ordre ; si CIFS renvoie -13, c’est des permissions ; si le noyau montre des erreurs I/O, arrêtez-vous et investiguez disque/réseau/stockage.

Task 15: Confirm Proxmox can activate now (and it sticks)

cr0x@server:~$ pvesm set nfs-backup --disable 0
cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
nfs-backup        nfs     active        2048000000       123456789      1920000000       6.0%

Ce que cela signifie : Ceci confirme que le plugin de stockage Proxmox peut de nouveau voir et utiliser le backend.

Décision : Démarrez une VM et effectuez une action de stockage légère (créer un petit disque, lister des sauvegardes). Vérifiez que ça survit à un redémarrage si c’était un problème d’ordre au boot.

Erreurs courantes : symptôme → cause racine → correction

1) « Stockage inactif » seulement sur un nœud

Symptôme : Le cluster affiche le stockage hors ligne sur pve02, OK sur pve01.

Cause racine : Problème local au nœud : chemin réseau, montage absent, session iSCSI non connectée, ou disque manquant.

Correction : Diagnostiquez sur le nœud en panne avec findmnt/vgs ; comparez avec un nœud fonctionnel ; corrigez réseau/montage/iSCSI avant de toucher la config du cluster.

2) Montage NFS présent mais opérations Proxmox bloquées

Symptôme : Démarrage VM, sauvegarde ou « parcourir le stockage » se bloque ; SSH parfois lent ; processus incassables.

Cause racine : I/O NFS bloqué ; le montage est « là » mais non réactif à cause du serveur ou du réseau.

Correction : Utilisez le test timeout ; vérifiez le réseau ; envisagez un remount après restauration de la connectivité. Évitez les montages « soft » pour le stockage VM — la corruption est pire.

3) Montage CIFS échoue après rotation du mot de passe

Symptôme : « mount error(13): Permission denied » soudainement après des mois de stabilité.

Cause racine : Mot de passe du compte de service routé ; fichier d’identifiants obsolète ; ou politique de domaine modifiant la méthode d’authentification requise.

Correction : Mettez à jour le fichier d’identifiants ; assurez-vous des permissions 600 ; fixez vers=3.0 et sec=ntlmssp si la politique l’exige.

4) Stockage LVM-thin inactif après reboot

Symptôme : Après un redémarrage, le stockage LVM est inactif ; un vgchange -ay manuel le répare.

Cause racine : Ordonnancement au démarrage : le périphérique sous-jacent apparaît tard (multipath, iSCSI), donc l’activation LVM au boot le manque.

Correction : Assurez-vous que les services iSCSI/multipath démarrent avant l’activation LVM ; corrigez la découverte des périphériques ; évitez « redémarrer pour activer » comme stratégie.

5) « Groupe de volumes introuvable » mais les disques apparaissent

Symptôme : vgs ne liste pas le VG ; mais lsblk montre le disque.

Cause racine : Le filtre de périphérique LVM l’exclut ; ou les signatures PV sont sur un chemin différent.

Correction : Revoyez /etc/lvm/lvm.conf filters ; standardisez sur des chemins stables (by-id, mapper pour multipath).

6) Export NFS accessible depuis un subnet mais pas un autre

Symptôme : Un nœud Proxmox monte, un autre reçoit « access denied by server ».

Cause racine : Restrictions d’export par IP/subnet ; nouveau nœud sur VLAN différent ; attentes de reverse DNS.

Correction : Corrigez la liste d’accès d’export serveur ; maintenez les nœuds Proxmox sur les subnets attendus ; évitez de compter sur le reverse DNS si possible.

7) Les montages CIFS fonctionnent manuellement mais Proxmox reste inactif

Symptôme : Vous pouvez monter le partage, mais le plugin Proxmox indique encore inactif.

Cause racine : Mismatch du point de montage attendu par Proxmox, options différentes, ou Proxmox s’attend à le trouver sous /mnt/pve/<storageid>.

Correction : Confirmez le chemin via pvesm config ; assurez-vous que le montage est exactement à ce chemin ; évitez les montages personnalisés en dehors des répertoires attendus sauf si vous en comprenez les implications.

8) « Stale file handle » après maintenance de stockage

Symptôme : Le chemin NFS existe ; les opérations échouent avec stale handle ; parfois résolu par un remount.

Cause racine : Le côté serveur a changé le filesystem, l’export a été remappé, ou la bascule HA a déplacé le stockage sans préserver l’identité des inodes.

Correction : Coordonnez la maintenance ; remontez les clients ; assurez-vous que la bascule HA préserve l’identité d’export quand c’est possible.

Trois mini-récits d’entreprise des tranchées du stockage

Incident causé par une mauvaise hypothèse : « C’est un bug Proxmox »

Ils avaient un petit cluster Proxmox et un partage NFS « fiable » pour les sauvegardes. Un lundi matin, les sauvegardes ont échoué avec « unable to activate storage. » La première réaction de l’équipe a été de planifier une mise à jour Proxmox, parce que l’interface disait le stockage inactif donc Proxmox devait être en faute.

Pendant ce temps, le serveur NFS avait été placé derrière un nouveau jeu de règles de pare-feu. Le ping fonctionnait. Le DNS fonctionnait. Même SSH fonctionnait. C’était suffisant pour que tout le monde suppose que le stockage fonctionnerait aussi. Ce ne fut pas le cas. Le pare-feu bloquait le trafic lié à NFS, et les tentatives de montage faisaient des timeouts.

La mise à jour a été ajournée quand quelqu’un a finalement exécuté showmount -e et que la commande s’est bloquée. C’était l’indice. Pas « stockage Proxmox inactif », mais « le nœud ne peut pas parler NFS à ce serveur ». La correction a été une règle de pare-feu ajustée et un remount. Les sauvegardes ont repris.

La leçon inconfortable n’était pas à propos des ports NFS. C’était à propos du processus : personne n’avait de playbook premier intervenant, ils ont donc par défaut « changé l’application » au lieu de « prouver la dépendance ».

Optimisation qui s’est retournée contre eux : tuner NFS comme une voiture de course

Une autre organisation utilisait NFS pour les images ISO et les templates de conteneur. Tout allait bien. Puis quelqu’un a décidé « d’optimiser » avec des options agressives trouvées sur un forum : timeouts plus courts, montages « soft », et divers réglages de cache, parce que « ce ne sont que des ISOs ».

Ça a fonctionné pendant des semaines. Puis un incident réseau a frappé pendant une extraction de template. Le comportement « soft » a renvoyé des erreurs I/O plutôt que d’attendre la récupération. Le résultat n’a pas été qu’un téléchargement de template échoue — cela a produit des fichiers partiels qui semblaient valides et ont été réutilisés plus tard.

Ils ont alors eu un heisenbug : des conteneurs parfois ne démarraient pas, parfois démarraient avec des fichiers manquants, et la couche stockage paraissait « active » tout du long. Quand ils ont testé l’intégrité des fichiers, ils ont trouvé des artefacts corrompus qui avaient été silencieusement mis en cache et réutilisés.

La correction a été de revenir aux valeurs raisonnables : montages « hard » pour tout ce qui affecte la consistance, verrouillage explicite de la version NFS, et une politique où « l’optimisation nécessite un plan de rollback ». Tunner sans tests de panne, c’est jouer et multiplier les étapes de retour en arrière.

Pratique ennuyeuse mais correcte qui a sauvé la journée : comparer les nœuds et consigner l’erreur réelle

Une entreprise moyenne utilisait LVM-thin sur stockage attaché en multipath. Un matin après un changement de firmware stockage, un nœud n’activait plus le stockage LVM. Le reste du cluster allait bien. La panique a commencé. Le fournisseur stockage a été blâmé. L’équipe hyperviseur aussi. Tout le monde pratiquait son sport favori : la certitude non aidante.

L’ingénieur de garde a fait quelque chose de profondément non sexy : il a comparé un nœud fonctionnel et le nœud en panne. Même version Proxmox. Même config de stockage. Ils ont lancé pvs et ont remarqué que le nœud en panne voyait le LUN à la fois comme /dev/sdX et comme /dev/mapper/mpathY. Signatures PV dupliquées. LVM refusait d’activer car il ne pouvait garantir qu’il n’allait pas corrompre quoi que ce soit.

L’ingénieur n’a rien forcé. Il a réparé le multipath pour n’utiliser que les devices mapper, puis ajusté les filtres LVM pour ignorer les /dev/sd* bruts pour ce SAN. L’activation a réussi. Pas de perte de données. Pas d’exploits.

La journée a été sauvée par deux pratiques : toujours capturer la chaîne d’erreur réelle, et toujours comparer nœud fonctionnel vs nœud en échec avant de toucher la prod. C’est ennuyeux. C’est aussi comme on garde ses week-ends.

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

Checklist A: First 10 minutes (stop the bleeding)

1. Exécutez pvesm status et identifiez l’ID(s) et le(s) type(s) de stockage en échec.
2. Vérifiez les logs des tâches et le journal pour la chaîne d’erreur sous-jacente : journalctl -u pvedaemon -u pvestatd -u pve-storage.
3. Pour NFS/CIFS : vérifiez la présence du montage avec findmnt et la réactivité avec une lecture timeout.
4. Pour LVM : vérifiez la visibilité VG/LV avec vgs/lvs.
5. Si c’est un seul nœud : comparez avec un nœud fonctionnel avant de changer quoi que ce soit.

Checklist B: NFS step-by-step

1. Confirmez la config Proxmox : pvesm config <storageid>.
2. Vérifiez le montage courant : findmnt <path>.
3. Vérifiez la visibilité de l’export : showmount -e <server>.
4. Montage manuel avec version explicite : mount -t nfs -o vers=4.1 ....
5. Testez I/O : créez et supprimez un petit fichier sous le point de montage.
6. Si vous voyez des stale handles : remontez et coordonnez avec le propriétaire du serveur NFS sur le comportement de maintenance/bascule.

Checklist C: CIFS step-by-step

1. Confirmez la config Proxmox et le chemin de montage.
2. Vérifiez que le fichier d’identifiants existe et est en 600.
3. Montage manuel avec vers= et sec= explicites.
4. Vérifiez les logs noyau pour les codes de retour CIFS : dmesg | tail.
5. Vérifiez les permissions d’écriture en créant un fichier en root sur le point de montage.
6. Après correction, relancez la vue de stockage Proxmox en revérifiant pvesm status ; ne vous fiez pas au cache de l’interface.

Checklist D: LVM step-by-step

1. Vérifiez l’existence du VG : vgs. Si manquant, inspectez la couche bloc (disques/iSCSI/multipath).
2. Vérifiez le statut LV/thin pool : lvs -a -o +devices.
3. Tentez l’activation : vgchange -ay <vg>.
4. Si vous suspectez des duplications : pvs -o+pv_uuid et corrigez multipath/filtres LVM.
5. Vérifiez l’utilisation du thin pool ; si les métadonnées sont pleines, corrigez cela avant de créer d’autres volumes.
6. Une fois stable, validez la persistance au redémarrage (ordre de démarrage, dépendances de services).

FAQ

1) Pourquoi Proxmox dit-il « unable to activate storage » sans détails ?

Parce que c’est une erreur d’encapsulation depuis la couche plugin de stockage. Le détail est dans la sortie de la tâche et les logs système. Consultez toujours journalctl et les logs de tâches Proxmox.

2) Puis-je simplement redémarrer le nœud pour résoudre les problèmes d’activation ?

Parfois, mais c’est une mauvaise habitude. Les redémarrages peuvent masquer des courses d’ordre au boot (iSCSI/multipath) et rendre les problèmes NFS intermittents plus difficiles à diagnostiquer. Redémarrez seulement après avoir capturé la chaîne d’erreur.

3) Le montage NFS est présent mais Proxmox indique toujours inactif — pourquoi ?

Si le montage est obsolète ou non réactif, Proxmox peut le marquer hors ligne parce que les appels de statistiques expirent ou renvoient des erreurs. Utilisez un test de lecture timeout pour détecter les blocages.

4) Quelle est la façon la plus rapide de distinguer LVM vs NFS vs CIFS comme source du problème ?

pvesm status indique le type de stockage. Puis validez l’état au niveau OS : findmnt pour NFS/CIFS, vgs/lvs pour LVM.

5) Dois-je utiliser CIFS pour les disques VM ?

En production, je l’évite pour les disques VM. Les sémantiques CIFS et la variabilité de latence peuvent produire des cas limites désagréables. Utilisez-le pour ISO/sauvegardes si nécessaire, et testez le comportement en cas d’échec.

6) Que signifie opérationnellement « stale file handle » ?

Le client référence un objet côté serveur qui n’existe plus sous la même identité. Cela survient généralement après des changements côté serveur ou une bascule. Un remount est souvent requis ; l’éviter demande une continuité de l’identification des exports.

7) Mon VG LVM est manquant après reboot, mais le disque est là. Pourquoi ?

LVM peut filtrer le périphérique, ou le voir sous un chemin différent que prévu. Le multipath peut aussi présenter des duplications. Vérifiez avec pvs et standardisez le nommage des périphériques.

8) Quelle est la manière la plus sûre de réparer un montage NFS bloqué ?

D’abord restaurez la disponibilité réseau/serveur si possible. Puis démontez et remontez. Attention : des processus peuvent rester en état D ; les démontages forcés peuvent être perturbateurs. Préférez des remounts planifiés si des I/O VM sont impliquées.

9) Pourquoi un nœud Proxmox monte CIFS alors qu’un autre ne peut pas ?

Différences de paquets installés, DNS, synchronisation horaire (Kerberos), ou comportement du noyau/module. Comparez les options de montage et vérifiez les codes de retour dans dmesg sur les deux nœuds.

10) Comment prévenir que cela se reproduise ?

Rendez les montages et l’activation LVM déterministes : figez les versions de protocoles, imposez l’ordre de démarrage (iSCSI/multipath avant LVM), surveillez la réactivité des montages, et documentez les dépendances de stockage comme si elles comptaient — parce qu’elles comptent.

Conclusion : mesures préventives pour éviter la suite

« Unable to activate storage » est Proxmox qui vous dit que le backend a échoué à un simple contrôle de réalité. Traitez-le ainsi. Identifiez l’ID de stockage, validez la vérité au niveau OS, puis utilisez les logs pour pointer la chaîne d’erreur sous-jacente. Réparez le backend, pas l’interface.

Prochaines étapes qui rapportent :

• Rédiger une runbook d’une page pour votre environnement avec les IDs de stockage exacts, les points de montage, et les options NFS/CIFS attendues.
• Standardiser les montages : version NFS explicite, dialecte SMB/sécurité explicite, chemins cohérents sous /mnt/pve.
• Rendre l’ordre de démarrage explicite quand le stockage dépend d’iSCSI/multipath, pour que l’activation LVM ne joue pas à la roulette.
• Surveiller les bons indicateurs : réactivité des montages (pas seulement « est-ce monté »), utilisation des métadonnées thin pool, et erreurs noyau récurrentes liées aux montages.

Faites cela, et la prochaine fois que Proxmox se plaindra, ce sera une réparation de cinq minutes au lieu d’un après-midi de redémarrages rituels et de blâme aléatoire.