Proxmox « disque VM disparu » : stockage vs configuration et comment le diagnostiquer

Le seul modèle mental dont vous avez besoin : pointeurs de config vs objets de stockage

Quand Proxmox indique qu’un disque VM manque, vous traitez avec deux couches qui peuvent diverger :

• Couche de configuration : la config VM Proxmox dans /etc/pve/qemu-server/<vmid>.conf (et les définitions de stockage dans /etc/pve/storage.cfg). C’est le « système de pointeurs » : quel nom de disque, quel ID de stockage, quel ID de volume.
• Couche de stockage : objets réels sur le backend de stockage (zvol ZFS, LV LVM, fichier QCOW2, image Ceph RBD, LUN iSCSI, fichier NFS). C’est la « physique ».

La plupart des incidents « disque disparu » correspondent à l’un de ces cas :

1. L’objet existe, le pointeur est incorrect (mismatch de configuration). C’est le cas heureux : corriger la config, importer le volume, rafraîchir le stockage, redémarrer la VM.
2. Le pointeur est correct, l’objet est inaccessible (stockage en panne, pool non importé, chemin réseau mort, permissions). Encore généralement récupérable sans perte de données, mais il faut arrêter les hypothèses et commencer la preuve.
3. L’objet a disparu (volume supprimé, snapshot restauré en arrière, stockage remplacé, mauvais pool). Là c’est une restauration depuis sauvegarde ou une récupération profonde du stockage.

Donc votre travail n’est pas « faire taire Proxmox ». Votre travail est de répondre, avec des preuves :

• Quel ID de volume Proxmox pense que la VM utilise ?
• Est-ce que ce volume existe sur le backend ?
• Sinon, existe-t-il un volume similaire ailleurs ?
• storage.cfg a-t-il changé, l’ID de stockage a-t-il changé, ou le backend a-t-il été déplacé ?

Une citation qui a bien vieilli en opérations : « idée paraphrasée » — Gene Kim : la fiabilité vient de la conception de boucles de rétroaction qui détectent les erreurs tôt, pas des actions héroïques après coup. Le point ici : instaurez l’habitude de vérifier séparément la configuration et le stockage.

Petite blague courte : Votre disque VM n’a pas « disparu » ; il est allé vivre à la campagne avec tous les autres LUNs perdus.

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

Ceci est le playbook à utiliser quand les gens attendent. Il est biaisé vers la rapidité et les preuves.

Premier : prouver ce que Proxmox pense devoir exister

1. Localisez la config de la VM, lisez les lignes de disque (virtio/scsi/sata/ide). Extrayez les IDs de volume.
2. Vérifiez si l’ID de stockage référencé est défini et actuellement « actif ».
3. Essayez une recherche de volume au niveau Proxmox (pvesm list / pvesm status).

Deuxième : prouver si l’objet backend existe

1. ZFS : lister les zvols/datasets, confirmer que le pool est importé et sain.
2. LVM-thin : lister les LVs, assurer que le VG est présent et que le thinpool est actif.
3. Stockage par répertoire : vérifier les chemins de fichiers et permissions, confirmer que le montage est réel (et non un point de montage vide).
4. Ceph : lister les images RBD, vérifier la santé du cluster et l’authentification du keyring.

Troisième : décider de la voie de récupération la plus sûre

• Si le disque existe mais le pointeur est faux : modifier la config VM ou réimporter le volume dans le stockage avec le bon ID.
• Si le stockage est indisponible : réparer le stockage en premier ; n’éditez pas la config VM pour « contourner » le stockage manquant, sinon vous provoquerez des erreurs de type split-brain.
• Si le disque est supprimé : arrêtez de bricoler ; orientez-vous vers les sauvegardes, cibles de réplication, snapshots ou récupération au niveau système de fichiers. Chaque tentative supplémentaire peut écraser des preuves.

Conseil de rapidité : ne redémarrez pas le nœud ni ne « redémarrez juste la VM » tant que vous ne savez pas si vous avez affaire à un montage obsolète, un pool manquant ou un volume réellement supprimé. Les redémarrages peuvent effacer des preuves transitoires dans les logs et déclencher des réparations automatiques qui changent la situation.

Faits et contexte intéressants (pourquoi cela se répète)

• /etc/pve est un système de fichiers de cluster : Proxmox stocke la config dans pmxcfs, un système distribué de type base de données. Si les communications du cluster sont dégradées, les lectures de config peuvent être étrangement cohérentes mais incorrectes entre nœuds.
• Les IDs de stockage sont des noms, pas magiques : « local-lvm » n’est qu’une étiquette dans storage.cfg. Renommer ou recréer un stockage avec un backend différent peut invalider silencieusement les références de disque VM.
• Les zvols ZFS sont des périphériques bloc : dans Proxmox, un disque sur zvol n’est pas un fichier. « Regarder dans le répertoire » ne le trouvera pas ; il faut interroger ZFS.
• LVM-thin peut vous tromper sous pression : les thinpools peuvent devenir en lecture seule ou refuser les activations quand les métadonnées sont pleines. Cela peut ressembler à un « LV manquant », mais c’est en réalité « LV n’arrive pas à s’activer ».
• Les points de montage peuvent échouer ouverts : si un montage NFS tombe et qu’un service recrée le répertoire de montage localement, vous pouvez finir par écrire des images VM sur le disque local du nœud. Plus tard, le « disque a disparu » quand NFS se remonte et masque les fichiers locaux.
• Un Ceph « healthy » est limité : un cluster peut être globalement sain mais votre client peut manquer d’un keyring ou avoir des caps empêchant la liste/la lecture d’une image RBD.
• Les IDs de volume Proxmox sont structurés : ils ressemblent typiquement à local-lvm:vm-101-disk-0 ou tank:vm-101-disk-0. Si vous voyez un chemin brut dans la config, quelqu’un a probablement contourné l’abstraction de stockage.
• Dérive de config VM courante lors des migrations : surtout lors du passage de disques basés fichier (qcow2) vers des volumes bloc (ZFS/LVM/Ceph), ou lors d’import depuis d’autres plateformes.
• Les snapshots ne vous protègent pas des erreurs de pointeur : les snapshots protègent les données ; ils ne protègent pas un humain d’affecter le mauvais disque au mauvais VMID.

Ce que « disque disparu » signifie réellement dans Proxmox

Il n’existe pas une seule chaîne d’erreur canonique. Vous verrez des variantes selon le backend :

• GUI Proxmox : « unable to find volume » ou « volume does not exist ».
• qm start : erreurs référencant un ID de volume (par ex. storage 'local-lvm' does not exist ou no such logical volume).
• qemu-system : impossible d’ouvrir un périphérique bloc, permission denied, fichier manquant.

Traduisez le symptôme en question :

• Si l’erreur mentionne un ID de stockage (ex. local-lvm, tank, ceph-ssd) : probablement storage.cfg ou un problème d’activation du stockage.
• Si elle mentionne un nom de volume (vm-101-disk-0) : probablement objet backend manquant, mauvais pool, mauvais VG, ou disque déplacé/renommé.
• Si elle mentionne un chemin (ex. /mnt/pve/nfs/images/101/vm-101-disk-0.qcow2) : probablement montage/permissions/mauvais chemin.

La façon la plus rapide d’arrêter le tâtonnement est de traiter la config VM comme un contrat. Soit elle est valide et le stockage est cassé, soit le stockage est OK et le contrat est faux.

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

Tout ce qui suit est écrit pour un shell d’hôte Proxmox. Exécutez en root (ou avec les privilèges appropriés). Chaque tâche inclut : la commande, ce que la sortie signifie typiquement, et la décision que vous prenez.

Task 1: Identify the exact disk references in the VM config

cr0x@server:~$ vmid=101; sed -n '1,200p' /etc/pve/qemu-server/${vmid}.conf
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G
net0: virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0
onboot: 1
ostype: l26
scsihw: virtio-scsi-pci

Sens : vous avez maintenant deux backends distincts : local-lvm et tank. Ne supposez pas que les deux sont cassés ; diagnostiquez par disque.

Décision : copiez les IDs de volume quelque part. Vos prochaines étapes sont de valider chaque ID de stockage et chaque objet volume.

Task 2: Check Proxmox storage status (active, enabled, content types)

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active      98420640        21053440        72278144   21.39%
local-lvm        lvmthin  active      402653184       187904000       214749184   46.67%
tank             zfspool  active      1099511627776   603979776000   495531851776   54.93%

Sens : les stockages sont « actifs ». Si votre VM ne démarre toujours pas, il s’agit probablement de volumes manquants, de permissions ou de cas d’activation, pas d’une définition de stockage désactivée.

Décision : si un stockage apparaît inactive ou absent, réparez cela avant de toucher à la config VM.

Task 3: Validate storage configuration exists and hasn’t drifted

cr0x@server:~$ grep -nE '^(dir|lvmthin|zfspool|rbd|lvm|nfs|iscsi):|^content|^path|^pool|^vgname|^monhost|^nodes' /etc/pve/storage.cfg
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup
lvmthin: local-lvm
        thinpool data
        vgname pve
        content images,rootdir
zfspool: tank
        pool tank
        content images,rootdir

Sens : les IDs de stockage correspondent à ce que les configs VM référencent. Si la VM référence un ID de stockage non listé ici, Proxmox traitera les volumes comme inexistants.

Décision : si l’ID de stockage est erroné dans la config VM, corrigez la config VM (avec prudence) plutôt que d’essayer de « créer un stockage avec ce nom » pointant ailleurs.

Task 4: Ask Proxmox to list the referenced volume (backend-agnostic)

cr0x@server:~$ pvesm list local-lvm --vmid 101
Volid                          Format  Type              Size VMID
local-lvm:vm-101-disk-0         raw     images     85899345920 101

Sens : Proxmox peut voir l’objet disque via son plugin de stockage. Cela suggère fortement que le disque existe et est découvrable.

Décision : si le disque apparaît ici mais que la VM refuse de démarrer, cherchez des problèmes de permissions/verrouillage, des mappages de périphériques obsolètes ou des erreurs QEMU, pas un « disque manquant ».

Task 5: Try listing a volume that Proxmox claims is missing

cr0x@server:~$ pvesm path tank:vm-101-disk-1
pvesm: volume 'tank:vm-101-disk-1' does not exist

Sens : au niveau de l’abstraction Proxmox, cet ID de volume n’est pas présent dans la vue du plugin de stockage.

Décision : pivot vers les vérifications backend (liste ZFS). Ne modifiez pas encore la config VM ; le disque peut exister sous un nom légèrement différent ou dans un pool différent.

Task 6: ZFS backend: confirm pool is imported and healthy

cr0x@server:~$ zpool status -x
all pools are healthy

Sens : la santé du pool n’est pas votre blocage immédiat.

Décision : continuez : listez datasets/zvols ; cherchez un mismatch de nommage ou un volume déplacé.

Task 7: ZFS backend: search for the missing zvol

cr0x@server:~$ zfs list -t volume -o name,volsize,used,refer,origin | grep -E 'vm-101|101-disk|disk-1' || true
tank/vm-101-disk-0   80G   12G  12G  -
tank/vm-102-disk-1  200G   68G  68G  -

Sens : le tank/vm-101-disk-1 attendu n’est pas présent. Mais vous voyez quelque chose de suspect : tank/vm-102-disk-1 existe et fait exactement la taille attendue pour le second disque de la VM 101.

Décision : investiguez si des disques ont été attachés au mauvais VMID ou renommés. C’est ici que « config vs stockage » devient un exercice de forensique.

Task 8: Cross-check which VM config references the suspicious volume

cr0x@server:~$ grep -R --line-number "tank:vm-102-disk-1" /etc/pve/qemu-server/*.conf
/etc/pve/qemu-server/102.conf:6:scsi1: tank:vm-102-disk-1,size=200G

Sens : la VM 102 le référence, donc il est probablement attaché légitimement là-bas. Mais « probablement » n’est pas un plan.

Décision : si le disque de la VM 101 manque et que la VM 102 a un disque en plus qui « ressemble » au vôtre, vérifiez via des identifiants côté invité (UUID du système de fichiers, données applicatives) avant de rattacher quoi que ce soit.

Task 9: LVM-thin backend: confirm VG and thinpool exist

cr0x@server:~$ vgs; lvs -a -o vg_name,lv_name,lv_attr,lv_size,pool_lv,data_percent,metadata_percent
  VG  #PV #LV #SN Attr   VSize   VFree
  pve   1  12   0 wz--n- 372.51g  1.00g
  VG   LV                Attr       LSize   Pool      Data%  Meta%
  pve  data              twi-aotz-- 350.00g           62.15  11.02
  pve  vm-101-disk-0      Vwi-aotz--  80.00g data     15.63

Sens : vm-101-disk-0 existe sur LVM-thin et est actif. L’utilisation des données/métadonnées n’est pas alarmante ici. Si la métadonnée est à 99% et que l’activation des LV échoue, vous verrez souvent des périphériques manquants comme symptôme.

Décision : si le thinpool data n’est pas actif ou si la métadonnée est pleine, réparez la santé du thinpool avant d’essayer de « recréer » des volumes.

Task 10: Directory storage: detect the “empty mountpoint” trap

cr0x@server:~$ mount | grep -E '/mnt/pve|nfs|cifs' || true
server-nfs:/export/pve-images on /mnt/pve/nfs-images type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)

cr0x@server:~$ ls -lah /mnt/pve/nfs-images/images/101/ | head
total 80G
drwxr-xr-x 2 root root 4.0K Dec 26 01:50 .
drwxr-xr-x 3 root root 4.0K Dec 26 01:50 ..
-rw-r----- 1 root root 80G Dec 26 01:49 vm-101-disk-0.qcow2

Sens : le montage existe et le répertoire attendu contient le disque. Si la sortie de mount est vide mais que le répertoire existe toujours, vous pourriez regarder le contenu du disque local, pas votre export NFS.

Décision : si le montage manque, arrêtez immédiatement la VM si elle écrit au mauvais endroit. Remontez, puis conciliez quelle copie est auteuritative.

Task 11: Check for locks that make a disk look “unusable”

cr0x@server:~$ qm status 101
status: stopped

cr0x@server:~$ qm config 101 | grep -E '^lock:|^scsi|^virtio|^sata|^ide'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: tank:vm-101-disk-1,size=200G

Sens : aucune ligne lock affichée. Si vous voyez lock: backup ou lock: migrate, Proxmox peut bloquer des opérations et les utilisateurs interprètent cela comme un « disque manquant ». Ce n’est pas manquant ; c’est protégé.

Décision : supprimez les locks seulement après avoir confirmé qu’aucune sauvegarde/migration n’est réellement en cours. Retirer une vraie lock en cours d’opération provoque souvent votre prochaine panne.

Task 12: Start the VM to capture the real error message (don’t rely on GUI summaries)

cr0x@server:~$ qm start 101
kvm: -drive file=/dev/zvol/tank/vm-101-disk-1,if=none,id=drive-scsi1,format=raw,cache=none,aio=io_uring: Could not open '/dev/zvol/tank/vm-101-disk-1': No such file or directory
start failed: QEMU exited with code 1

Sens : QEMU tente d’ouvrir un chemin zvol et il n’existe pas. Cela confirme que ce n’est pas un « problème d’interface Proxmox ». L’objet backend est manquant ou renommé.

Décision : trouvez le vrai nom du zvol (Task 7) ou restaurez-le ; ne créez pas un nouveau disque vierge avec le même nom sauf si vous aimez la perte de données irréversible.

Task 13: Search logs for deletion/rename events and storage errors

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pvesm -u pveproxy --since "24 hours ago" | tail -n 40
Dec 26 01:41:12 server pvedaemon[2210]: update VM 101: moved disk scsi1 to tank
Dec 26 01:41:15 server pvedaemon[2210]:  end task UPID:server:000008A2:0000F1A3:676C3B6B:qmmove:101:root@pam: OK
Dec 26 02:10:33 server pvedaemon[2210]:  start task UPID:server:00000B11:00012A3D:676C4BE9:qmstart:101:root@pam:
Dec 26 02:10:34 server pvedaemon[2210]: command 'qmstart 101' failed: exit code 1

Sens : vous avez un indice : quelqu’un a déplacé le disque récemment. « Move disk to tank » a réussi, mais le zvol manque maintenant. Cela suggère une suppression ultérieure, un rollback ou un changement de pool.

Décision : corrélez avec l’historique ZFS, les événements de rollback de stockage ou les actions opérateur autour de 01:41–02:10.

Task 14: ZFS history (if enabled) to catch destroy/rename

cr0x@server:~$ zpool history tank | tail -n 20
2025-12-26.01:41:13 zfs create -V 214748364800 tank/vm-101-disk-1
2025-12-26.01:41:14 zfs set volblocksize=16K tank/vm-101-disk-1
2025-12-26.01:58:02 zfs destroy tank/vm-101-disk-1

Sens : il a été créé, puis détruit. Ce n’est plus un « disparu mystérieux ». C’est « supprimé », ce qui est très différent.

Décision : arrêtez d’essayer de démarrer la VM ; passez à la restauration depuis snapshot/sauvegarde ou aux options de récupération ZFS (selon votre politique).

Task 15: Ceph RBD backend: verify image presence and permissions

cr0x@server:~$ ceph -s
  cluster:
    id:     7d2a2f1c-1a11-4f2b-bc1a-0c3f0c0d0d0d
    health: HEALTH_OK
  services:
    mon: 3 daemons, quorum mon1,mon2,mon3
    osd: 6 osds: 6 up, 6 in
  data:
    pools:   2 pools, 128 pgs
    objects: 1.2M objects, 4.6 TiB
    usage:   13 TiB used, 20 TiB / 33 TiB avail

cr0x@server:~$ rbd -p rbd ls | grep -E 'vm-101-disk-0|vm-101-disk-1' || true
vm-101-disk-0

Sens : le cluster est sain, mais une seule image existe. Si Proxmox attend une seconde image, il ne démarrera pas. Cela peut aussi arriver si vous utilisez le mauvais nom de pool ou si vous ne tenez pas compte d’un namespace RBD.

Décision : vérifiez storage.cfg pour le bon pool/namespace ; vérifiez quel nœud possède le bon keyring et les caps adéquats.

Task 16: Confirm Proxmox resolves the disk path (storage plugin sanity)

cr0x@server:~$ pvesm path local-lvm:vm-101-disk-0
/dev/pve/vm-101-disk-0

Sens : Proxmox peut résoudre l’ID de volume en un chemin de périphérique bloc réel. Si QEMU échoue encore, l’erreur provient probablement des permissions, de nœuds de périphérique obsolètes ou du mapping kernel.

Décision : vérifiez que le nœud de périphérique existe et est accessible, et que l’activation LVM est cohérente.

Task 17: Verify the block device node exists and has sane permissions

cr0x@server:~$ ls -lah /dev/pve/vm-101-disk-0
lrwxrwxrwx 1 root root 7 Dec 26 00:02 /dev/pve/vm-101-disk-0 -> ../dm-12

cr0x@server:~$ ls -lah /dev/dm-12
brw-rw---- 1 root disk 253, 12 Dec 26 00:02 /dev/dm-12

Sens : le périphérique existe. S’il manquait, vous verriez « No such file » et vous vous concentreriez sur l’activation LVM et les règles udev.

Décision : si les nœuds de périphériques sont absents, lancez les étapes d’activation LVM et investiguez pourquoi ils n’apparaissent pas (VG introuvable, multipath, session iSCSI down).

Task 18: Find stale mappings for ZFS zvol device paths

cr0x@server:~$ ls -lah /dev/zvol/tank/ | head
total 0
drwxr-xr-x 2 root root  80 Dec 26 01:41 .
drwxr-xr-x 4 root root  80 Dec 26 01:41 ..
lrwxrwxrwx 1 root root  13 Dec 26 01:41 vm-101-disk-0 -> ../../../zd0

Sens : le zvol manquant n’est vraiment pas présent ; autrement vous verriez un symlink pour lui. Cela concorde avec l’erreur QEMU du Task 12.

Décision : ne touchez pas à la config VM. Votre correctif : restaurer le zvol (depuis snapshot/sauvegarde) ou rattacher le zvol existant correct s’il a été renommé.

Trois mini-récits d’entreprise depuis le terrain

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

Une société SaaS de taille moyenne exploitait un cluster Proxmox où « local-lvm » existait sur chaque nœud, mais pas de façon identique. Sur le papier, c’était « le même nom de VG partout », une affirmation qui semble vraie jusqu’à ce qu’on demande ce que cela signifie.

Une VM a été migrée du Nœud A au Nœud B après une alerte matérielle. Proxmox a mis à jour la config VM, et la VM a démarré. Une semaine plus tard, le disque « a disparu » après un redémarrage. Panique. L’équipe stockage a blâmé Proxmox. L’admin Proxmox a blâmé le stockage. Duo classique.

L’hypothèse erronée : « Si l’ID de stockage est le même, le contenu du stockage est identique ». Sur le Nœud B, « local-lvm » pointait vers un VG différent que sur le Nœud A à cause d’un rebuild antérieur. Ça a fonctionné brièvement parce que la VM tournait et les périphériques bloc sont restés mappés jusqu’au redémarrage. Au redémarrage, l’activation LV n’a pas trouvé le volume attendu.

La correction n’était pas héroïque : ils ont standardisé les noms de VG et les IDs de stockage, et ont arrêté d’utiliser une étiquette partagée pour un stockage non partagé. La cause racine était une collision de nommage. La leçon : un ID de stockage Proxmox n’est pas une promesse de sémantique partagée. C’est une chaîne dans un fichier de config.

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

Une équipe plateforme interne voulait des clones plus rapides et moins de snapshots stockés sur du flash coûteux. Ils ont introduit un job planifié qui élaguait agressivement les anciens volumes ZFS correspondant à un motif utilisé pour des VMs de test temporaires. C’était propre. C’était soigné. C’était aussi une erreur.

Une VM de production avait récemment été déplacée de LVM-thin vers ZFS. Pendant le déplacement, un humain a renommé un disque pour correspondre à des conventions internes—malheureusement ces conventions chevauchaient le motif « temporaire ». La VM a tourné deux jours, jusqu’à ce que le job de prune fasse son travail et détruise le zvol.

L’incident s’est présenté comme « disque VM disparu ». Proxmox ne mentait pas ; le disque avait été supprimé. La première réaction de l’équipe fut de recréer un zvol vierge avec le même nom pour que la VM démarre. Cela aurait été la manière la plus rapide de s’assurer que la forensique ou la récupération ne fonctionneraient jamais. Quelqu’un les en a empêchés.

Ils ont restauré depuis les sauvegardes, puis corrigé la politique : les jobs de suppression vérifient désormais les références dans /etc/pve/qemu-server avant de détruire quoi que ce soit. De plus, les noms de disque ne sont plus du texte libre. « Optimisation » est juste un autre mot pour « introduire un nouveau mode de panne », à moins d’ajouter des garde-fous.

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

Une organisation financière exploitait Proxmox avec Ceph RBD pour les disques VM et avait une règle stricte : chaque ticket de changement de stockage incluait une « étape de preuve » équivalente à une capture d’écran—les sorties de pvesm status, qm config, et une liste backend (rbd ls ou zfs list) avant et après.

C’était bureaucratique. Les gens levaient les yeux au ciel. Mais cela signifiait aussi qu’il y avait toujours une petite piste de vérité objective. Un jour, un nœud a redémarré après des mises à jour du noyau et plusieurs VMs ont refusé de démarrer avec « unable to find volume ». L’astreignant a sorti le dernier ticket de changement et a comparé les sorties avant/après. Les configs VM référençaient ceph-ssd, mais storage.cfg listait maintenant ceph_ssd suite à un renommage bien intentionné pour correspondre à une norme de nommage.

Les disques n’avaient jamais bougé. Ceph allait bien. Seule l’étiquette ID de stockage avait changé, rompant toutes les références. Ils ont rétabli le nom d’ID de stockage, rechargé, et tout est revenu.

Rien de fancy. Pas de récupération de données. Pas de guessing. Juste des preuves de changement disciplinées qui ont rendu la panne évidente. Les pratiques ennuyeuses ne gagnent pas de prix. Elles garantissent la disponibilité.

Erreurs courantes : symptôme → cause racine → correction

1) « Volume does not exist » juste après un renommage de stockage

Symptôme : les configs VM référencent old-storage:vm-XXX-disk-Y ; pvesm status ne montre pas old-storage.

Cause racine : l’ID de stockage a changé dans /etc/pve/storage.cfg mais les configs VM n’ont pas été mises à jour.

Correction : restaurez le nom d’ID de stockage ou mettez à jour les configs VM vers le nouvel ID (seulement si le backend est vraiment le même). Puis vérifiez avec pvesm list et qm start.

2) Fichiers QCOW2 manquants après un incident NFS

Symptôme : fichiers « disparus » de /mnt/pve/nfs-* ; le répertoire existe mais est vide ; puis réapparition plus tard.

Cause racine : le montage est tombé ; l’hôte a écrit dans le répertoire local ; le remontage a caché les fichiers locaux.

Correction : remontez correctement, puis réconciliez les duplicatas. Confirmez avec mount et comparez les inode/device IDs. Prévenir en utilisant des unités systemd avec dépendances et en surveillant les stale file handle.

3) Pool ZFS importé sur un nœud mais pas sur un autre (confusion de cluster)

Symptôme : la VM démarre sur le Nœud A mais pas sur le Nœud B ; le Nœud B indique chemin zvol manquant.

Cause racine : pool ZFS local non importé sur le Nœud B ; la config Proxmox suppose du partagé mais il ne l’est pas.

Correction : importez le pool sur le nœud correct ou cessez de le traiter comme un stockage partagé. Utilisez le bon type de stockage et des restrictions de nœud dans storage.cfg.

4) LVM-thin « LV manquant » lors d’une exhaustion de métadonnées thinpool

Symptôme : le LV semble manquant, la VM ne démarre pas ; métadonnées thinpool proches de 100%.

Cause racine : le thinpool ne peut pas allouer de métadonnées ; l’activation des LV échoue ; les nœuds de périphérique peuvent ne pas apparaître.

Correction : étendez la LV de métadonnées, réduisez les snapshots, lancez la réparation du thinpool si approprié. Puis réactivez les VGs et réessayez.

5) « Permission denied » qui ressemble à un disque manquant

Symptôme : QEMU ne peut pas ouvrir un fichier/périphérique bloc ; la GUI signale disque inaccessible.

Cause racine : mauvaise propriété/mode sur le stockage en répertoire, politique AppArmor/SELinux, ou ACLs NFS cassées.

Correction : corrigez les permissions, assurez-vous que Proxmox est configuré pour ce type de stockage, et retestez avec pvesm path et un ls -l direct.

6) Le disque existe mais sous un autre nom (renommage humain)

Symptôme : la config VM référence vm-101-disk-1 mais le backend a vm-101-data ou un autre nom de disque VMID.

Cause racine : renommage manuel sur le backend ou pendant une migration/restauration.

Correction : vérifiez le volume correct via la taille, l’heure de création, la lignée des snapshots et les identifiants système de fichiers invités ; puis mettez à jour la config VM avec le vrai ID de volume.

7) Sauvegardes restaurées vers le mauvais ID de stockage

Symptôme : la tâche de restauration « réussit », mais la VM ne démarre car elle référence un disque sur un stockage qui ne le contient pas.

Cause racine : la cible de restauration diffère de l’original ; la config n’a pas été réécrite comme attendu.

Correction : restaurez avec un mapping explicite de stockage, puis confirmez avec qm config et pvesm list.

8) Ceph semble OK, mais l’image RBD est « manquante » pour Proxmox

Symptôme : ceph -s est OK ; Proxmox ne peut pas lister les images ou n’arrive pas à en ouvrir une.

Cause racine : mauvais pool/namespace dans storage.cfg, keyring manquant sur ce nœud, ou caps insuffisantes.

Correction : validez storage.cfg, confirmez que le keyring existe sur le nœud, testez rbd -p POOL ls en root et dans le même environnement que Proxmox utilise.

Deuxième blague courte : Le stockage, c’est comme les ragots — une fois qu’un mauvais nom circule (ID de stockage erroné), tout le monde le répète jusqu’à ce que vous corrigiez la source.

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

Étape par étape : quand une VM ne démarre pas à cause d’un disque manquant

1. Geler la scène. Si la VM est arrêtée, gardez-la arrêtée jusqu’à ce que vous sachiez si vous avez affaire à une suppression ou à un mapping. Si elle tourne mais signale un disque manquant au redémarrage, ne redémarrez pas à nouveau.
2. Extraire les références de disque. Lisez /etc/pve/qemu-server/<vmid>.conf. Notez chaque ligne de disque et ID de volume.
3. Vérifier que les IDs de stockage existent et sont actifs. pvesm status. Si inactif, réparez le stockage d’abord (montage, import de pool, réseau).
4. Liste au niveau Proxmox. pvesm list <storage> --vmid <vmid>. Si le volume apparaît, votre « disque manquant » n’est probablement pas manquant.
5. Liste au niveau backend. ZFS : zfs list -t volume. LVM : lvs. Répertoire : find le fichier. Ceph : rbd ls.
6. En cas de mismatch : chercher des correspondances proches. Grep des configs VM pour des noms similaires ; vérifier des attachments au mauvais VMID.
7. Vérifier les logs. journalctl pour tâches move/delete ; historique ZFS ou logs Ceph si possible.
8. Choisir le mode de récupération.
   • Pointeur erroné : mettre à jour la config VM ou réimporter le volume.
   • Stockage inaccessible : restaurer l’accès au stockage.
   • Volume supprimé : restaurer depuis sauvegarde/snapshot ; envisager la récupération ZFS si la politique le permet.
9. Valider avant de démarrer. Assurez-vous que pvesm path <volid> fonctionne pour chaque disque dans la config.
10. Démarrer une fois, surveiller la sortie. Lancez qm start depuis le CLI ; capturez l’erreur complète si ça échoue.
11. Nettoyage post-incident. Documentez quelle couche a échoué (config ou stockage), et ajoutez un monitor/garde-fou.

Checklist : ce que vous ne devez pas faire sous pression

• Ne créez pas un nouveau disque vide avec le même nom « pour faire démarrer » la VM. C’est ainsi que vous effacez les preuves et garantissez la perte de données.
• Ne renommez pas les IDs de stockage à la légère. Si nécessaire, planifiez une mise à jour en masse des configs VM et validez avec un dry run.
• Ne supposez pas qu’un stockage « actif » est le bon stockage. Un montage NFS peut être actif mais pointé vers le mauvais export.
• Ne traitez pas un stockage local comme partagé. Si le pool/VG n’existe que sur un nœud, restreignez-le à ce nœud.
• Ne supprimez pas les locks aveuglément. Les locks empêchent souvent de faire empirer une mauvaise situation.

Checklist : prévention qui fonctionne réellement

• Standardisez les IDs de stockage et faites-les valider en revue. Les noms sont une dépendance.
• Surveillez la présence des montages et la « correction du montage » (ID de périphérique, pas seulement existence du répertoire).
• Alertez sur les échecs d’import de pool ZFS et l’usage des métadonnées LVM thinpool.
• Exécutez un audit nocturne : pour chaque volid de disque VM, vérifiez qu’il existe sur le backend et qu’il est résoluble via pvesm path.
• Exigez des preuves de changement (sorties avant/après) pour les opérations de stockage : move, rename, delete, changements de pool.

FAQ

1) Comment savoir si c’est un problème de config ou de stockage ?

Si pvesm list ne voit pas le volume et que la liste backend ne le voit pas non plus, c’est la réalité du stockage/objet. Si le backend le montre mais que Proxmox ne peut pas le résoudre, c’est un mismatch config/definition de stockage.

2) La config VM référence local-lvm, mais pvesm status l’affiche inactif. Quelle est la solution la plus rapide ?

Réparez d’abord l’activation du stockage : confirmez que le VG existe et est visible. Éditer la config VM pour pointer ailleurs est généralement un rustine à court terme qui devient une corruption à long terme.

3) Puis-je éditer directement /etc/pve/qemu-server/<vmid>.conf ?

Oui, mais faites-le comme un adulte : faites une copie, changez une seule chose, et validez avec qm config et pvesm path. Rappelez-vous aussi que /etc/pve est géré par le cluster.

4) Je vois un zvol comme tank/vm-101-disk-1, mais Proxmox dit qu’il n’existe pas.

Généralement un mismatch storage.cfg (mauvais nom de pool), une restriction de nœud, ou le volume est dans un pool/dataset différent de celui attendu par Proxmox. Confirmez que la définition de stockage pointe vers le même pool et que le nœud y a accès.

5) Le fichier disque existe sur NFS, mais Proxmox ne peut pas l’ouvrir.

Vérifiez les options de montage et les permissions/ownership. Vérifiez aussi que vous ne regardez pas un répertoire local parce que le montage a échoué. La sortie de mount est l’arbitre.

6) Que signifie si une VM démarre sur un nœud mais pas après migration ?

En général cela signifie que le stockage n’est pas véritablement partagé ou n’est pas défini de façon identique sur tous les nœuds. La migration Proxmox peut déplacer la config, mais elle ne peut pas faire apparaître un VG local ailleurs.

7) Quelle est la manière la plus sûre de récupérer si le volume a été supprimé ?

Arrêtez-vous, confirmez la suppression (historique backend/logs), puis restaurez depuis sauvegarde ou snapshot. Si vous avez des snapshots/replications ZFS, restaurez le dataset/zvol puis rattachez par ID de volume.

8) Pourquoi Proxmox montre parfois le disque dans la GUI mais le démarrage échoue ?

Parce que lister les métadonnées est plus facile qu’ouvrir le périphérique. Vous pouvez « voir » un ID de volume, mais QEMU peut échouer à l’ouvrir à cause de permissions, de nœuds de périphériques obsolètes, d’activation ou d’un état en lecture seule du backend.

9) Comment éviter qu’un renommage de stockage casse les VMs ?

Ne renommez pas les IDs de stockage en place à moins d’avoir planifié une mise à jour coordonnée. Si vous devez le faire, mettez à jour les configs VM dans une fenêtre de changement contrôlée et vérifiez avec pvesm path pour chaque disque.

10) Existe-t-il une commande unique qui trouve les références de disque cassées ?

Pas une commande parfaite, mais vous pouvez la script : itérez les VMIDs, parsez les lignes de disque, lancez pvesm path et signalez les échecs. L’absence d’un tel audit est la raison pour laquelle cet incident se répète.

Conclusion : prochaines étapes pour prévenir une récurrence

Diagnostiquer « disque VM disparu » est surtout une discipline de séparation des couches. La config Proxmox est un ensemble de pointeurs. Le stockage est l’ensemble des objets. Votre travail est de trouver le mismatch avec des preuves, pas des intuitions.

Prochaines étapes concrètes :

• Mettre en place un audit quotidien : pour chaque volid de disque VM, vérifiez que pvesm path résout et que l’objet backend existe.
• Renforcer les montages et import de pools : traitez la « correction du montage » et « pool importé » comme des SLOs surveillés, pas des hypothèses.
• Contrôle de changement pour les IDs de stockage : les éditions de storage.cfg doivent être revues comme du code. Les noms sont des dépendances.
• Rédiger vos règles de récupération : « ne jamais recréer un nom de disque manquant », « vérifier l’existence backend avant d’éditer la config », et « logs d’abord, reboot en dernier ».

Le meilleur résultat n’est pas une récupération astucieuse. C’est un incident ennuyeux qui n’arrive plus parce que vous avez rendu mécaniquement difficile la perte de trace des emplacements de disques.