Quand le disque a pris la tangente mais que la bécane roule encore.
TL;DR (si t’es en sueur)
- NE REBOOT PAS (ni node, ni VM).
- Confirme le
(deleted) via lsof.
qm monitor → info block → drive_backup (underscore !) pour dumper.qm importdisk → disque importé en unused0.qm stop → qm set --virtio0 ... → qm set --delete unused0 → qm start.- Check
lsblk, df -h, service OK, plus de (deleted).
⚠️ Disclaimer
Ce tuto raconte une histoire vraie.
Dans cet épisode :
- le disque s’appelait
virtio0
- il était en
.raw
- et il faisait le malin en étant
(deleted)
Chez toi, les noms et formats peuvent être différents.
Avant toute commande, regarde, comprends, adapte.
Ici on transmet une méthode, pas une incantation magique.
0) Contexte / Symptômes
Tu as une VM qui tourne, pépère, mais :
- Backup Proxmox = NOK
- Snapshots = NOK
- Le storage a sauté / le fichier disque a disparu / “je sais pas chef j’ai cliqué”
La VM “tourne” parce que QEMU garde le fichier disque ouvert (FD), même s’il est supprimé côté FS.
1) Cause technique (explication courte)
Le disque virtuel a été supprimé, mais QEMU a encore un descripteur ouvert vers l’inode :
- VM OK tant qu’elle ne redémarre pas
- Backup impossible car Proxmox ne peut plus relire le disque depuis le storage
-> Si tu rebootes maintenant : c’est le grand saut sans parachute.
2) Règles absolues (la loi de la jungle)
- NE PAS
reboot le node
- NE PAS redémarrer la VM
- NE PAS “réparer le storage” avant extraction
- On extrait le disque tant que QEMU le tient encore par la nuque
3) Identifier le disque de la VM
qm config <VMID>
Exemple :
virtio0: RAID_FAST:251/vm-251-disk-0.raw,size=20G
4) Confirmer le “deleted inode” (preuve irréfutable)
lsof | grep <VMID> | grep deleted
Exemple :
kvm <PID> root 36u REG ... /mnt/fast/images/251/vm-251-disk-0.raw (deleted)
Si tu vois le disque VM en (deleted), on est dans le bon scénario.
Les entrées /memfd:displaysurface (deleted) sont normales (tampons mémoire QEMU), rien à voir avec le stockage.
5) Ouvrir le monitor QEMU et repérer le device
qm monitor <VMID>
Dans le monitor :
info block
Exemple :
drive-virtio0: /mnt/fast/images/251/vm-251-disk-0.raw (raw)
Note le nom exact du drive (souvent drive-virtio0).
6) Extraction du disque (étape critique)
⚠️ Selon ta version, la commande est drive_backup (underscore), pas drive-backup.
Toujours dans le monitor :
drive_backup -f drive-virtio0 /mnt/fast/vm-<VMID>-rescue.raw
-f : copie complète du disque (pas de backing file)
Pas de progression obligatoirement affichée
La VM continue de tourner pendant la copie
Optionnel (dans un autre shell) :
watch -n 2 ls -lh /mnt/fast/vm-<VMID>-rescue.raw
Quand terminé, quitter le monitor :
quit
7) Importer le disque dans un storage sain (ex: local)
qm importdisk <VMID> /mnt/fast/vm-<VMID>-rescue.raw local
Résultat typique :
unused0: successfully imported disk 'local:<VMID>/vm-<VMID>-disk-0.raw'
C’est normal : import OK, attach à faire.
8) Remplacer le disque de boot (pas de hotplug)
Le hotplug du bootdisk est interdit :
hotplug problem - can't unplug bootdisk 'virtio0'
Et dans un scénario “disque fantôme”, qm shutdown peut être foireux.
On assume un stop propre côté Proxmox (brutal mais maîtrisé).
a) Stop
qm stop <VMID>
b) Attacher le disque importé comme disque principal
qm set <VMID> --virtio0 local:<VMID>/vm-<VMID>-disk-0.raw
c) Supprimer la référence unused0 (important)
qm config <VMID> | grep unused
qm set <VMID> --delete unused0
d) Vérifier la config finale
qm config <VMID>
Attendu :
- un seul virtio0 sur storage sain
- aucune référence à l’ancien storage (ex: RAID_FAST)
- aucun unusedX
9) Redémarrer et valider
qm start <VMID>
Dans la VM :
lsblk
df -h
10) Checks post-op (le “contrôle technique”)
Sur le node :
lsof | grep <VMID> | grep deleted
Attendu : plus rien pour le disque VM, possibilité de lignes affichant un "deleted" mais ne concernant pas le disque.
Audit stockage :
grep -R "RAID_FAST" /etc/pve/qemu-server/
grep -R "unused" /etc/pve/qemu-server/
11) Nettoyage final
Quand tout est validé :
rm -f /mnt/fast/vm-<VMID>-rescue.raw
Conclusion
T’as rattrapé une VM en plein vol : le disque était “effacé” mais QEMU le tenait encore par la bretelle.
Tant que tu ne rebootes pas, tu peux dumper, réimporter, rattacher, redémarrer, et repartir comme si de rien n’était.
Fin de l’épisode : le disque fait moins le malin, et la VM reprend son tour de piste.
