Stockage Proxmox « non disponible sur le nœud » : pourquoi il existe mais vous ne pouvez pas l’utiliser

novembre 21, 2025 • février 3, 2026 • Lecture : 28 min • Views: 6

Cet article vous a aidé ?

Vous ouvrez l’interface Proxmox, voyez votre stockage bien listé, puis—bam—« non disponible sur le nœud ». Le stockage est présent, comme une place de parking réservée avec un cône dessus. Vous ne pouvez pas l’utiliser, les migrations échouent, les sauvegardes se bloquent, et votre prochaine fenêtre de maintenance ressemble à une négociation d’otages.

Ce message est la franchise de Proxmox : la config du cluster connaît un ID de stockage, mais ce nœud ne peut pas y accéder pour l’instant (ou n’est pas censé). L’astuce consiste à séparer « la définition existe » de « le stockage est joignable, monté, authentifié et supporte l’opération demandée ». C’est dans cette séparation que surviennent la plupart des pannes.

Ce que signifie réellement « non disponible sur le nœud »

Dans Proxmox VE, les définitions de stockage sont des objets de configuration à l’échelle du cluster, stockés dans /etc/pve/storage.cfg (un fichier servi via le système de fichiers du cluster de Proxmox). Quand vous définissez un stockage appelé fast-nfs, Proxmox s’en souvient partout. Cela ne signifie pas que chaque nœud peut réellement l’utiliser. Proxmox distingue :

La définition de stockage existe : l’ID est présent dans la config et apparaît dans l’interface.
Le stockage est actif sur un nœud : le nœud peut atteindre le backend (le montage existe, le pool importé, Ceph sain, l’auth fonctionne, le chemin existe, les permissions correctes).
Le stockage prend en charge le contenu demandé : vous essayez de mettre des disques VM sur un stockage qui n’accepte que des ISO/templates, ou inversement.
Le stockage est autorisé sur le nœud : le stockage est restreint par l’option « nodes », ou le nom du nœud ne correspond pas à ce que la config attend.

Le message « non disponible sur le nœud » est la façon dont Proxmox dit : pour ce nœud, la vérification d’activation a échoué ou le stockage est délibérément exclu. Proxmox a souvent assez d’informations pour afficher le stockage dans la liste, mais pas assez de plomberie fonctionnelle pour exécuter des opérations en toute sécurité.

Les catégories racines courantes

La plupart des cas entrent dans un de ces seaux :

Problèmes de portée / ciblage : le stockage est configuré pour un sous-ensemble de nœuds, ou nom de nœud incohérent après réinstallation/renommage.
Problèmes de montage/chemin : NFS/CIFS non monté, point de montage manquant, mauvais chemin, fstab non persistant, problèmes d’ordonnancement systemd.
Auth/permissions : keyrings Ceph, identifiants SMB, permissions d’export NFS, problèmes de propriété/mode Unix.
Backend pas sain : Ceph dégradé/indisponible, pool ZFS non importé, VG LVM manquant, session iSCSI morte, multipath cassé.
Mismatch de contenu et de format : essayer de stocker images sur un dir sans le format requis, ou utiliser du stockage local en supposant HA pour les migrations.

Le stockage Proxmox n’est pas magique. Ce sont des adaptateurs autour des primitives de stockage Linux, et Linux est très littéral. Si votre nœud ne peut pas le monter, l’importer, s’y authentifier ou le voir, Proxmox ne fera pas semblant.

Blague #1 : Le stockage, c’est comme une machine à café : tout le monde remarque quand elle est en panne, et personne ne se souvient qui l’a installée.

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

Si vous êtes d’astreinte, vous ne voulez pas un cours de philosophie. Vous voulez le chemin le plus court vers « est-ce une restriction de config, un problème de montage ou une panne du backend ? » Voici l’ordre qui minimise le temps perdu.

Premier : confirmer si c’est volontairement exclu

Le stockage est-il restreint à certains nœuds dans storage.cfg ?
Le nom du nœud correspond-il à la config (surtout après réinstallation) ?
Êtes-vous dans un split-brain / problème de communication du cluster où /etc/pve diffère ?

Si c’est exclu, la correction est de la configuration, pas de l’infrastructure.

Deuxième : confirmer que l’OS voit/monte/import le backend

NFS/CIFS : est-ce monté ? DNS résout-il ? Le noyau peut-il joindre le serveur ?
ZFS : le pool est-il importé ? Erreurs I/O ?
LVM : le VG existe-t-il ? Les PV sont-ils présents ?
Ceph : ceph -s a-t-il l’air sain ? Avons-nous des moniteurs/quorum ?
iSCSI : les sessions sont-elles loggées ? Multipath sain ?

Si l’OS ne peut pas l’utiliser, Proxmox non plus. Ne déboguez pas Proxmox tant que Linux ne fonctionne pas.

Troisième : confirmer les types de contenu et attentes de chemin

Le stockage autorise-t-il images, rootdir, backup, etc. ?
Pour un stockage dir : le répertoire existe-t-il et est-il inscriptible par root ?
Pour un stockage basé fichier : y a-t-il de l’espace ? Les inodes sont-ils épuisés ?

C’est l’endroit où « ça monte bien » peut encore échouer parce que Proxmox refuse de placer des disques VM sur un stockage réservé aux ISO, ou parce que le chemin est en lecture seule.

Types de stockage et leurs modes de panne spécifiques

Stockage Dir (répertoire local, NFS monté sur un répertoire, etc.)

Pourquoi ça échoue : point de montage manquant, mauvaises options de montage, montage en lecture seule, problèmes de permissions, chemin incorrect, handles NFS obsolètes, ou le répertoire existe mais est sur le mauvais système de fichiers (vous pensiez que c’était NFS ; c’est en fait le root local).

Ce que Proxmox vérifie : que le chemin existe, est accessible, et que le nœud est autorisé. Il ne vérifie pas que vous avez monté la « bonne » chose—donc c’est à vous de le faire.

Stockage NFS

Pourquoi ça échoue : permissions d’export, pare-feu, DNS, serveur down, client coincé avec un montage « soft », ou montages systemd non prêts au démarrage. Les échecs NFS sont souvent « disponibles » jusqu’au moment où ils ne le sont pas, parce que les métadonnées en cache masquent les problèmes.

Opinion opérationnelle : utilisez des montages hard pour les disques VM, mais comprenez que des I/O bloqués gèleront des processus. C’est le compromis : intégrité des données vs disponibilité. Pour les sauvegardes, vous pouvez être plus souple.

Stockage CIFS/SMB

Pourquoi ça échoue : identifiants expirés/rotatifs, mismatch de dialecte SMB, problèmes AD, ou helper de montage non installé. Aussi : les serveurs Windows aiment les changements « utiles ».

Ce qui rompt silencieusement : le montage peut exister mais être en fait déconnecté ; vous ne le découvrez que lorsque les écritures commencent à échouer.

ZFS (local)

Pourquoi ça échoue : pool non importé après reboot, renommage de périphérique, chemins by-id manquants, pool dégradé avec erreurs I/O, ou vous avez créé le pool sur un nœud et en attendez l’accès sur un autre (ce n’est pas un stockage partagé ; c’est de l’optimisme).

Réalité HA : ZFS local est excellent. Ce n’est pas du stockage partagé. Si vous voulez la migration live sans stockage partagé, vous avez besoin de réplication ou de Ceph—et d’accepter le coût opérationnel.

LVM / LVM-thin (bloc local)

Pourquoi ça échoue : VG manquant parce que le disque n’est pas présent, UUID PV changé, règles de filtre dans lvm.conf, ou problèmes d’activation. Les thin pools échouent aussi de façon spectaculaire si les métadonnées se remplissent.

Ceph (RBD/CephFS)

Pourquoi ça échoue : moniteurs hors quorum, OSDs down, problèmes réseau, keyrings non appariés, mauvais chemin ceph.conf, ou vous pointez un nœud vers le mauvais nom/fSID de cluster. Ceph échoue aussi lorsqu’il est « presque sain » mais lent : vous pouvez voir la disponibilité mais pas l’utilisabilité.

Opinion : Ceph est merveilleux quand vous l’exploitez comme un produit, pas comme une mission annexe.

iSCSI (souvent avec LVM dessus)

Pourquoi ça échoue : sessions qui tombent, mismatch CHAP, multipath mal configuré, ID de LUN changeant, ou oubli de persistance au reboot. iSCSI a tendance à échouer à 02:00, parce que bien sûr.

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

Voici les vérifications de niveau production que j’exécute quand « stockage non disponible sur le nœud » apparaît. Chaque tâche inclut (a) une commande, (b) ce que signifie une sortie typique, et (c) la décision suivante. Exécutez-les d’abord sur le nœud affecté.

Tâche 1 : Demandez à Proxmox ce qu’il considère actif

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active        102334976       22110208        75053056    21.61%
fast-nfs         nfs      inactive               0              0               0     0.00%
ceph-rbd         rbd      active                0              0               0     0.00%

Signification : Le gestionnaire de stockage Proxmox (pvesm) déclare fast-nfs inactif sur ce nœud. C’est le signal canonique : Proxmox ne peut pas l’activer.

Décision : passer aux vérifications de montage/backend. Si le statut est actif mais que l’UI dit indisponible, suspectez des restrictions de nœud ou une incohérence de config du cluster.

Tâche 2 : Confirmer la définition de stockage et les restrictions de nœud

cr0x@server:~$ grep -A5 -n "nfs: fast-nfs" /etc/pve/storage.cfg
27:nfs: fast-nfs
28:        export /exports/proxmox
29:        path /mnt/pve/fast-nfs
30:        server 10.20.30.40
31:        content images,backup,iso
32:        nodes pve01,pve02

Signification : Ce stockage est explicitement limité à pve01,pve02. Si vous êtes sur pve03, il sera « non disponible » par conception.

Décision : soit ajouter le nœud à la liste (s’il doit y accéder), soit ne plus tenter de l’utiliser depuis ce nœud.

Tâche 3 : Vérifier le nom de nœud utilisé par Proxmox

cr0x@server:~$ hostname
pve03

Signification : Le nom du nœud est pve03. Si storage.cfg indique pve3 ou l’ancien hostname, les restrictions ne correspondront pas.

Décision : corriger la liste de nœuds du stockage ou aligner le hostname de façon cohérente (renommer un hôte dans Proxmox n’est pas trivial ; préférez corriger la config).

Tâche 4 : Vérifier si le point de montage existe et quel système de fichiers c’est

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

Signification : C’est monté et c’est bien du NFS4 depuis le serveur/export attendu. Bon signe.

Décision : si findmnt n’affiche rien, le montage est absent ; s’il affiche ext4 ou zfs, vous avez monté la mauvaise chose ou pas du tout.

Tâche 5 : S’il manque, vérifier le mount systemd et l’ordonnancement fstab

cr0x@server:~$ systemctl status mnt-pve-fast\\x2dnfs.mount
● mnt-pve-fast\x2dnfs.mount - /mnt/pve/fast-nfs
     Loaded: loaded (/etc/fstab; generated)
     Active: failed (Result: exit-code) since Fri 2025-12-26 07:12:20 UTC; 3min ago
      Where: /mnt/pve/fast-nfs
      What:  10.20.30.40:/exports/proxmox
      Docs:  man:fstab(5)
             man:systemd-fstab-generator(8)
    Process: 1442 ExecMount=/usr/bin/mount 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs (code=exited, status=32)

Signification : L’unité de montage a échoué ; le statut 32 signifie en général une défaillance de montage (réseau, permission, serveur).

Décision : vérifier la connectivité réseau et les permissions NFS ensuite.

Tâche 6 : Vérifier la connectivité réseau et la résolution de noms

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.462 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.417 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1012ms
rtt min/avg/max/mdev = 0.417/0.439/0.462/0.022 ms

Signification : La connectivité de base est OK. Cela ne prouve pas que NFS fonctionne, mais élimine rapidement « le serveur est parti ».

Décision : vérifier les ports TCP/UDP et l’accès à l’export.

Tâche 7 : Interroger les exports NFS côté client

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

Signification : L’export existe et est offert à votre sous-réseau. Si votre nœud est dans un autre sous-réseau/VLAN, vous venez de trouver le problème.

Décision : si la liste d’export est vide ou accès refusé, corriger les exports/pare-feu côté serveur NFS.

Tâche 8 : Essayer un montage manuel avec erreurs détaillées

cr0x@server:~$ mount -v -t nfs4 -o vers=4.2 10.20.30.40:/exports/proxmox /mnt/pve/fast-nfs
mount.nfs4: timeout set for Fri Dec 26 07:17:40 2025
mount.nfs4: trying text-based options 'vers=4.2,addr=10.20.30.40,clientaddr=10.20.30.53'
mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting 10.20.30.40:/exports/proxmox

Signification : Classique : le réseau est OK, l’export existe, mais le serveur refuse ce client (règles d’export erronées, root_squash combiné avec des attentes, ou liste d’hôtes manquante).

Décision : ajuster les exports sur le serveur NFS ; les modifications de config Proxmox n’aideront pas.

Tâche 9 : Confirmer que le répertoire est inscriptible et ne vous ment pas

cr0x@server:~$ touch /mnt/pve/fast-nfs/.pve-write-test && echo "ok" || echo "fail"
ok

Signification : Le montage est inscriptible en tant que root (ou au moins cet essai a réussi). S’il échoue avec « Read-only file system » ou « Permission denied », Proxmox va mal le vivre.

Décision : corriger les options de montage, les permissions d’export serveur ou la santé du système de fichiers sous-jacent.

Tâche 10 : Vérifier permissions/propriété pour les chemins de stockage dir

cr0x@server:~$ ls -ld /mnt/pve/fast-nfs
drwxr-xr-x 9 root root 4096 Dec 26 07:11 /mnt/pve/fast-nfs

Signification : Root a l’accès. C’est généralement suffisant car les opérations de stockage Proxmox s’exécutent en root. Si vous voyez une propriété étrange due au squashing ou des ACLs, attendez-vous à des échecs lors de la création de sous-dirs comme dump ou template.

Décision : assurez-vous que l’export NFS et les permissions du système de fichiers permettent les écritures root (ou alignez les UID/GID pour correspondre aux attentes de Proxmox).

Tâche 11 : Vérifier que les types de contenu correspondent à ce que vous faites

cr0x@server:~$ pvesm config fast-nfs
content images,backup,iso
export /exports/proxmox
path /mnt/pve/fast-nfs
server 10.20.30.40
type nfs

Signification : Ce stockage permet des images VM, des sauvegardes et des ISO. Si votre échec était « impossible de créer un volume CT », il se peut que rootdir manque.

Décision : ajuster content de manière appropriée. Ne sur-permettez pas les types de contenu sauf si vous le souhaitez réellement (cela réduit les garde-fous).

Tâche 12 : Chercher les logs Proxmox qui expliquent les échecs d’activation

cr0x@server:~$ journalctl -u pvedaemon -u pve-storage -n 80 --no-pager
Dec 26 07:12:21 pve03 pvedaemon[1321]: storage 'fast-nfs' is not online
Dec 26 07:12:21 pve03 pvedaemon[1321]: mount error: permission denied for 10.20.30.40:/exports/proxmox
Dec 26 07:12:22 pve03 pvedaemon[1321]: TASK ERROR: storage 'fast-nfs' is not available on node 'pve03'

Signification : Vous obtenez la vraie raison : permission de montage refusée. L’interface GUI ne vous dit que rarement cela aussi clairement.

Décision : corriger le backend. Arrêtez de tripoter l’UI.

Tâche 13 : Si c’est ZFS, confirmer l’import et la santé du pool

cr0x@server:~$ zpool status
  pool: rpool
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          nvme0n1p3 ONLINE       0     0     0

errors: No known data errors

Signification : Le pool est sain. Si votre stockage est un pool ZFS nommé tank et qu’il n’est pas listé, il n’est pas importé.

Décision : si manquant, tenter zpool import et investiguer les chemins de périphériques et la stabilité by-id.

Tâche 14 : Si ZFS manquant, lister les pools importables

cr0x@server:~$ zpool import
  pool: tank
    id: 1234567890123456789
 state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

        tank        ONLINE
          sdb       ONLINE

Signification : Le pool existe mais n’est pas importé. Après un reboot, cela signifie généralement que l’auto-import n’a pas eu lieu ou que les périphériques sont arrivés tard.

Décision : l’importer (zpool import tank) puis corriger l’ordonnancement au boot ou le nommage des périphériques pour éviter la récurrence.

Tâche 15 : Si LVM-thin, confirmer la présence du VG et du thinpool

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve          1   2   0 wz--n-  930.00g  10.00g

Signification : Le VG existe. Si Proxmox signale LVM indisponible et que vgs ne montre rien, le disque/VG n’est pas présent ou filtré.

Décision : vérifier pvs, la visibilité des disques, et les filtres dans /etc/lvm/lvm.conf.

Tâche 16 : Si Ceph, vérifier rapidement la santé du cluster

cr0x@server:~$ ceph -s
  cluster:
    id:     2f1d3b0a-6f6d-4a7b-a6b3-9a7b4a0d1c2e
    health: HEALTH_WARN
            1 mons down, quorum mon1,mon2
  services:
    mon: 3 daemons, quorum mon1,mon2
    osd: 9 osds: 9 up, 9 in
  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Signification : Ceph est majoritairement OK ; un mon est down mais le quorum existe et les PGs sont clean. Proxmox devrait généralement encore utiliser RBD.

Décision : si la santé est HEALTH_ERR, ou vous voyez beaucoup de PGs non active+clean, traitez cela comme un incident backend, pas un drame d’UI Proxmox.

Tâche 17 : Confirmer que Proxmox peut lister les volumes sur le stockage

cr0x@server:~$ pvesm list fast-nfs | head
Volid                             Format  Type              Size VMID
fast-nfs:iso/debian-12.iso        iso     iso           657457152    0
fast-nfs:backup/vzdump-qemu-100.vma.zst vma.zst backup  1812034560  100

Signification : Si le listing fonctionne, le stockage est au moins joignable et lisible. Si le listing échoue avec une erreur, il inclut souvent la défaillance backend spécifique.

Décision : si la liste fonctionne mais la création échoue, suspectez des permissions, de l’espace, des types de contenu, ou des problèmes de verrouillage.

Tâche 18 : Vérifier l’espace disque et les inodes (oui, les inodes)

cr0x@server:~$ df -h /mnt/pve/fast-nfs && df -i /mnt/pve/fast-nfs
Filesystem                         Size  Used Avail Use% Mounted on
10.20.30.40:/exports/proxmox       20T   19T  800G  96% /mnt/pve/fast-nfs
Filesystem                         Inodes  IUsed   IFree IUse% Mounted on
10.20.30.40:/exports/proxmox       120M    119M    1M   99% /mnt/pve/fast-nfs

Signification : L’espace est serré, mais les inodes sont quasiment épuisés. Cela peut casser les sauvegardes, l’upload d’ISO et le stockage de conteneurs de façons qui ressemblent à des erreurs de permission.

Décision : nettoyer, agrandir le système de fichiers, ou réduire le churn de petits fichiers. Si les inodes sont proches de 100%, considérez-le comme plein.

Erreurs fréquentes (symptôme → cause racine → correction)

Ce ne sont pas des « erreurs théoriques ». Ce sont celles qui reviennent parce qu’elles semblent raisonnables sur le moment.

1) Le stockage apparaît dans l’UI, mais sur un nœud il est « non disponible »

Symptôme : Stockage listé au niveau du cluster ; un seul nœud ne peut pas l’utiliser.

Cause racine : restriction de nœud dans storage.cfg ou mismatch de hostname (nœud réinstallé avec un nom différent).

Correction : mettre à jour le réglage nodes pour ce stockage ou corriger l’identité du nœud de façon cohérente. Vérifier avec pvesm status sur chaque nœud.

2) Le stockage NFS « fonctionne » jusqu’au reboot, puis devient indisponible

Symptôme : Après reboot, Proxmox indique stockage indisponible ; un montage manuel le répare.

Cause racine : montage non persistant ou qui démarre avant le réseau ; absence de _netdev ou ordonnancement systemd ; parfois DNS pas prêt.

Correction : s’assurer que fstab contient _netdev, envisager des unités systemd de montage, et vérifier avec systemctl status mnt-pve-*.mount. Rendre les montages déterministes.

3) « Permission denied » au montage même si l’export existe

Symptôme : showmount -e montre l’export, mais le montage échoue avec accès refusé.

Cause racine : règles d’export n’incluent pas l’IP du nœud, ou attentes d’idmapping NFSv4 différentes, ou pare-feu bloquant les ports NFS.

Correction : corriger la allowlist d’export serveur, confirmer la version NFS, et valider depuis le client avec un montage verbeux.

4) Le stockage est monté, mais Proxmox dit toujours indisponible

Symptôme : findmnt montre le montage, mais pvesm status indique inactif.

Cause racine : Proxmox attend le stockage sous /mnt/pve/<storageid> mais vous l’avez monté ailleurs, ou le chemin dans storage.cfg est mauvais, ou le montage est obsolète/gelé.

Correction : aligner le path avec le point de montage réel ; vérifier la présence d’un NFS figé avec un simple ls qui bloque ; remonter si nécessaire.

5) Les disques VM ne se créent pas sur le stockage, mais les ISO se téléversent

Symptôme : Le contenu ISO fonctionne, mais la création d’un disque échoue.

Cause racine : images manquant dans content, ou le type de stockage ne supporte pas le format demandé.

Correction : ajouter les types de contenu appropriés, ou déplacer les disques vers un stockage bloc (LVM/RBD) si vous avez besoin de certaines sémantiques.

6) Le stockage Ceph « non disponible » seulement sur un nœud

Symptôme : Deux nœuds peuvent utiliser RBD ; un ne peut pas.

Cause racine : paquets Ceph manquants, keyring absent, ceph.conf erroné, ou chemin réseau vers les moniteurs bloqué sur ce nœud.

Correction : valider ceph -s sur ce nœud ; comparer /etc/ceph et les keyrings ; confirmer les règles de pare-feu et la joignabilité des moniteurs.

7) Le stockage LVM-thin disparaît après un « nettoyage »

Symptôme : Stockage basé LVM inactif ; vgs vide.

Cause racine : quelqu’un a retiré/changé un disque, modifié les filtres LVM, ou changé le nommage des périphériques sans IDs stables.

Correction : restaurer la visibilité des disques, utiliser des chemins by-id stables quand possible, et garder les filtres LVM conservateurs et explicites.

Listes de contrôle / plan pas à pas

Checklist A : Triage « stockage non disponible » sur un seul nœud (10 minutes)

Exécuter pvesm status. Identifier quels ID de stockage sont inactifs sur ce nœud.
Vérifier /etc/pve/storage.cfg pour les restrictions nodes et les réglages de chemin.
Valider le nom du nœud avec hostname et comparer à la config.
Si stockage fichier : vérifier le montage avec findmnt.
Tester l’I/O de base : ls et touch dans le chemin de stockage (attention aux blocages).
Consulter les logs : journalctl -u pvedaemon -u pve-storage pour des erreurs explicites.
Si NFS/CIFS : tester un montage manuel avec sortie verbeuse.
Si Ceph : ceph -s sur ce nœud et vérifier l’existence des keyrings.
Si ZFS/LVM : vérifier la visibilité et la santé du pool/VG.
Ce n’est qu’après les vérifs OS que vous recontrôlez l’UI Proxmox et tentez l’opération à nouveau.

Checklist B : Vérification de sanity à l’échelle du cluster (30–60 minutes, prévient les répétitions)

Sur chaque nœud : exécuter pvesm status et comparer les sorties.
Valider que chaque stockage partagé a la même sémantique de montage partout (même chemin, mêmes options).
Standardiser les hypothèses réseau des nœuds : VLANs, règles de pare-feu, DNS, MTU, routage.
Pour NFS : s’assurer que les exports incluent explicitement tous les nœuds Proxmox ; éviter les surprises « ça marche depuis un sous-réseau ».
Pour Ceph : s’assurer que chaque nœud a les bons configs /etc/ceph et keyrings ; vérifier la joignabilité des moniteurs.
Revoir les types de contenu par stockage : les garder serrés. « Tout partout » devient « tout en panne partout ».
Ajouter une validation post-reboot dans votre processus de changement : montages importés, VGs actifs, Ceph OK.

Checklist C : Avant d’activer HA ou de planifier des migrations

Identifier quelles charges nécessitent du stockage partagé (vraie HA, migration live sans downtime).
Confirmer que le stockage est accessible depuis chaque nœud susceptible d’héberger ces workloads.
Tester une migration live et une migration de stockage pendant les heures ouvrables avec un plan de rollback.
Pour les workloads sur stockage local, concevoir explicitement des chemins de réplication/sauvegarde et documenter les limites.

Trois petites histoires du monde corporate

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

Ils avaient un cluster Proxmox propre à trois nœuds et un serveur NFS unique. Le stockage avait été défini une fois, visible partout, et l’équipe a supposé que cela voulait dire « partagé ». Ça a surtout bien marché—jusqu’au premier cas d’urgence.

Un hôte a commencé à émettre des erreurs ECC. L’astreinte a fait la bonne chose : évacuer les VMs vers les nœuds restants. Mais plusieurs VMs ont refusé de migrer. L’UI disait aimablement que le nœud cible ne pouvait pas utiliser le stockage. Confus, car le stockage était « là ».

La cause racine n’était pas un bug Proxmox. Le serveur NFS n’exportait la part qu’à un sous-réseau spécifique, et un des nœuds Proxmox se trouvait sur un VLAN différent à cause d’un ancien changement réseau « temporaire ». La définition de stockage existait, mais le nœud n’avait jamais réellement été autorisé.

La correction fut ennuyeuse : mettre à jour la allowlist de l’export NFS, aligner le placement réseau, et ajouter un simple test « mount + touch fichier » comme checklist lors de la mise en service d’un nœud. Après cela, les migrations ont fonctionné—et l’équipe a cessé de considérer l’UI comme une preuve de réalité.

Ils ont aussi appris une vérité rude : la configuration visible au cluster n’est pas la même chose que l’infrastructure accessible au cluster. C’est une distinction qu’on n’oublie qu’une fois.

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

Une autre société voulait des performances disque VM plus rapides, alors ils ont « optimisé » les options de montage NFS. Ils sont passés à des timeouts agressifs et ont ajouté des options destinées à réduire les blocages sous perte de paquets. Sur le papier, cela paraissait responsable : éviter des processus bloqués, garder le nœud réactif.

Les premières semaines ont été calmes. Puis une maintenance réseau de routine a causé une brève interruption—des secondes, pas des minutes. Après cela, un sous-ensemble de VMs a commencé à loguer des erreurs filesystem. Les sauvegardes ont commencé à échouer de façon inconsistante. Certaines opérations indiquaient stockage indisponible, d’autres s’exécutaient partiellement. Le pattern de défaillance était théâtral et difficile à reproduire.

Le coupable était le comportement du montage sous défaillance transitoire. Les options de montage ont transformé un incident temporaire en erreurs visibles par l’application. Pour des disques VM, ce n’est pas une « petite gêne ». C’est un événement d’intégrité des données avec de la paperasse.

Ils sont revenus à des sémantiques de montage plus sûres pour les disques, et ont séparé les usages : un chemin NFS pour les sauvegardes (où des retries sont acceptables) et un backend différent pour les disques VM. L’optimisation avait été une idée intelligente appliquée au mauvais problème.

Blague #2 : Rien ne dit « haute disponibilité » comme affiner les timeouts jusqu’à ce que votre stockage devienne le système de fichiers de Schrödinger.

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

Une autre équipe utilisait du RBD Ceph pour les disques VM et un partage NFS séparé pour les sauvegardes. Ils avaient aussi l’habitude, douloureusement ennuyeuse, de lancer après chaque mise à jour Proxmox ou reboot de nœud un petit script de validation reproductible—pvesm status, un petit test de création/suppression RBD, et un test d’écriture de sauvegarde sur NFS.

Un matin, un nœud a redémarré après une mise à jour du noyau et est revenu avec ses règles de pare-feu subtilement différentes à cause d’une dérive de la gestion de configuration. Le nœud a rejoint le cluster et semblait sain dans l’UI, mais les opérations RBD échouaient et le stockage apparaissait indisponible seulement sur ce nœud.

Parce qu’ils ont exécuté la validation immédiatement, ils l’ont détecté avant que le scheduler n’y place des workloads. Pas de migrations surprise en pleine nuit, pas de VMs à moitié mortes, pas de tickets « ça marche sur le nœud A ». Juste une correction contrôlée : restaurer les règles de pare-feu correctes pour l’accès aux moniteurs Ceph, revérifier, et avancer.

C’est la vérité peu glamour : la fiabilité, c’est surtout pratiquer les mêmes petites vérifications jusqu’à en être lassé, puis les pratiquer encore. C’est lent ; c’est plus rapide que les pannes.

Faits intéressants et un peu d’histoire (qui aide vraiment)

Fait 1 : Proxmox stocke la config à l’échelle du cluster dans un système de fichiers spécial sous /etc/pve, soutenu par un mécanisme de réplication de type base de données. C’est pourquoi les IDs de stockage apparaissent vite partout.
Fait 2 : Les points de montage sous /mnt/pve sont conventionnellement gérés par les plugins de stockage Proxmox ; décaler le chemin est une blessure auto-infligée fréquente.
Fait 3 : NFS existe depuis les années 1980, et il alimente encore les stacks de virtualisation modernes parce qu’il est simple, débogable et « assez bon » quand il est bien conçu.
Fait 4 : Le passage industriel des disques VM basés fichiers aux disques blocs (LVM, RBD, iSCSI) s’est produit surtout pour la prédictibilité de latence et la sémantique de verrouillage sous contention.
Fait 5 : Ceph est devenu populaire en virtualisation parce qu’il offre du stockage bloc partagé sans SAN traditionnel, mais il échange la simplicité matérielle contre une complexité opérationnelle.
Fait 6 : « Le stockage est défini » vs « le stockage est monté » reflète une division système classique : plan de contrôle vs plan de données. Beaucoup de pannes surviennent quand un plan ment à l’autre.
Fait 7 : L’épuisement des inodes est un vrai mode de défaillance en production sur des partages NFS chargés de sauvegardes, surtout quand les politiques de rétention produisent beaucoup de petits fichiers.
Fait 8 : La cohérence des hostnames importe dans les clusters parce que l’identité intervient dans les contrôles d’accès, le ciblage des nœuds, les certificats, et parfois dans les allowlists de stockage. Les renommages ne sont rarement « juste cosmétiques ».
Fait 9 : La génération d’unités de montage systemd depuis /etc/fstab peut changer le comportement d’ordre de boot d’une manière qui surprend ceux habitués aux anciens init systems.

Une citation de fiabilité à réellement intégrer

Idée paraphrasée, attribuée à John Allspaw : on n’obtient pas la fiabilité en accusant des personnes ; on l’obtient en améliorant le système qui a permis la défaillance.

Quand un stockage est « non disponible sur le nœud », résistez à l’envie de chercher une personne à blâmer. Cherchez l’hypothèse que le système a permis d’exister.

FAQ

1) Pourquoi le stockage apparaît-il dans l’UI s’il est inutilisable ?

Parce que l’UI affiche des objets de configuration à l’échelle du cluster. L’ID de stockage existe dans /etc/pve/storage.cfg. La disponibilité est spécifique au nœud et dépend des montages, périphériques, auth et santé.

2) « non disponible sur le nœud » est-ce toujours une vraie panne ?

Non. Cela peut être volontaire : le stockage est restreint à certains nœuds via l’option nodes. Mais si c’est censé être partagé, traitez-le comme un incident de production jusqu’à preuve du contraire.

3) Quelle est la manière la plus rapide de voir l’erreur réelle derrière le message GUI ?

Consultez les logs sur le nœud affecté : journalctl -u pvedaemon -u pve-storage. Ils contiennent souvent l’erreur de montage/auth/backend sous-jacente.

4) Puis-je résoudre cela en redémarrant les services Proxmox ?

Parfois cela masque des problèmes transitoires, mais ce n’est généralement pas le bon premier geste. Si l’OS ne peut pas monter ou voir le backend, redémarrer les services ne fait que rejouer l’échec avec plus d’assurance.

5) Pourquoi cela arrive-t-il seulement après un reboot ?

Ordonnancement au boot et persistance. Le réseau peut ne pas être prêt quand les montages démarrent, les pools ZFS peuvent ne pas auto-importer à cause du timing des périphériques, les sessions iSCSI peuvent ne pas se reconnecter automatiquement, ou les règles de pare-feu changent au reboot.

6) Je peux `ping` le serveur NFS, pourquoi le stockage reste-t-il indisponible ?

Ping ne prouve presque rien au-delà de la joignabilité ICMP. NFS nécessite des services RPC fonctionnels, des exports corrects, une authentification adéquate et des ports ouverts. Utilisez showmount -e et un mount -v verbeux.

7) Pour la HA et la migration live, ai-je besoin d’un stockage partagé ?

Pour la migration live sans migration de stockage, oui. Sinon, il vous faut une stratégie : réplication (réplication ZFS), migration de stockage avec downtime, ou un backend distribué (Ceph). Choisissez-en une volontairement.

8) Pourquoi Proxmox dit qu’un stockage est actif mais les opérations échouent quand même ?

« Actif » peut signifier qu’il est monté et que des vérifications basiques ont réussi. Les opérations peuvent quand même échouer à cause de permissions sur des sous-répertoires, inodes pleins, remount en lecture seule, handles NFS obsolètes, ou restrictions de type de contenu.

9) Est-il sûr de placer des disques VM sur un stockage NFS dir ?

Oui, si c’est conçu correctement (réseau stable, options de montage appropriées, configuration serveur correcte, attentes réalistes). Mais si vous voulez une latence cohérente et moins de cas limites, le stockage bloc (Ceph RBD, LVM sur SAN) a tendance à mieux se comporter sous contention.

10) Comment prévenir ce type de problème à l’avenir ?

Standardisez la mise en service des nœuds : vérifier montages/imports, valider l’activation du stockage avec pvesm status, et tester une opération lecture/écriture. Puis automatisez cela comme vérification post-reboot.

Conclusion : prochaines étapes qui fonctionnent en production

« Non disponible sur le nœud » est un message précis sous un manteau vague. La définition du stockage existe ; le nœud ne peut pas l’activer—ou n’y est pas autorisé. Votre travail est d’arrêter de deviner et de prouver quelle couche est cassée : portée de config, accès au niveau OS, ou santé du backend.

Faites ceci ensuite, dans l’ordre :

Exécutez pvesm status sur le nœud affecté et confirmez ce qui est inactif.
Vérifiez /etc/pve/storage.cfg pour les restrictions nodes et les chemins corrects.
Validez le backend depuis Linux : montages, pools, VGs, santé Ceph, sessions iSCSI.
Utilisez les logs pour trouver la chaîne d’erreur réelle et corriger le backend, pas l’UI.
Après correction, validez en listant le contenu du stockage et en faisant un petit test d’écriture.
Institutionnalisez la vérification ennuyeuse : validation du stockage post-reboot sur chaque nœud.

Si vous voulez moins de surprises à 02:00, traitez le stockage comme un système de production de première classe : accès nœud explicite, chemins cohérents, montages déterministes, et vérifications de santé qui tournent quand personne ne regarde.