Gut zu hören, dass es gelöst ist. Der Hinweis: `rbd rm` kann auch auf einem teilweise gelöschten Image problemlos ausgeführt werden — es toleriert einen fehlenden Header und bereinigt trotzdem das verbleibende ID-Objekt und den Verzeichniseintrag. Das ist das richtige Werkzeug für diese Situation, ohne manuelle `rados`-Eingriffe.
Warum `vm-41032-disk-0` in diesen teilweise gelöschten Zustand geraten ist: Das ist ein separates, bereits vorher bestehendes Problem vom Löschen von VM 41032 (unabhängig vom Template, an dem du gerade gearbeitet hast). Die Ursache liegt darin, dass `rbd rm` keine atomare Operation ist — es handelt sich um eine client-gesteuerte Abfolge einzelner RADOS-Operationen:
| Schritt | Was entfernt wird |
|---|
| 1 | Datenobjekte (`rbd_data.<id>.*`) — der eigentliche Image-Inhalt |
| 2 | Image-Header (`rbd_header.<id>`) — Metadaten: Größe, Features, Snapshots |
| 3 | Journal (falls Journaling aktiviert ist) |
| 4 | Object Map (`rbd_object_map.<id>`) |
| 5 | ID-Objekt (`rbd_id.<name>`) |
| 6 | Verzeichniseintrag in `rbd_directory` — das, was `rbd ls` liest |
Jeder einzelne Schritt ist atomar und dauerhaft (fällt eine OSD mitten in einem Schritt aus, wiederholt der RADOS-Client die Operation, bis sie abgeschlossen ist). Aber es gibt keine verteilte Transaktion über die gesamte Abfolge. Wird der Client-Prozess zwischen den Schritten beendet — zum Beispiel durch einen Node-Neustart oder `
systemctl restart pveproxy`, der einen `
qm destroy`-Task nach Schritt 2, aber vor den Schritten 5–6 unterbricht — bleiben diese Metadaten-Objekte einfach zurück. Das Ergebnis ist ein Image, das `
rbd ls` weiterhin auflistet (Verzeichniseintrag vorhanden), das librbd aber nicht öffnen kann (Header fehlt) — was genau dem `(2) No such file or directory` entspricht, das du bei `
rbd ls -l` gesehen hast.
Für die laufende Ceph-Cluster-Überwachung die wichtigsten Befehle:
Bash:
# Allgemeiner Cluster-Status — hier anfangen
ceph -s
# Detaillierte Aufschlüsselung von Warnungen oder Fehlern
ceph health detail
# OSD-Auslastung pro Node — auf Ungleichgewichte prüfen
ceph osd df tree
# Pool-Auslastung
ceph df detail
# Auf blockierte oder degradierte Placement Groups prüfen
ceph pg stat
ceph pg dump_stuck # zeigt blockierte inactive/unclean/undersized PGs
# RBD: tatsächliche Speichernutzung (berücksichtigt Thin Provisioning und COW)
rbd du -p IKT-Labor
# Prüfen, ob Images beim Auflisten Fehler melden
rbd ls -l IKT-Labor
Für regelmäßige Überwachung decken `
ceph -s` und `
ceph health detail` die meisten Fälle ab. Wenn `
ceph health detail` `
HEALTH_OK` ohne Warnungen meldet, ist der Cluster in gutem Zustand.
Zusätzliche Empfehlung: Die OSD-Auslastung regelmäßig mit `
ceph osd df tree` prüfen. Wenn eine OSD oder ein Node deutlich höher ausgelastet ist als andere, lohnt sich ein Blick auf die CRUSH-Map-Gewichte und `
rbd du` pro Pool, um unerwartet große Images zu identifizieren.
(I don't speak German — the translation above was done with a translation tool. Please excuse any awkward phrasing.)
Good to hear it's resolved. Worth noting: `
rbd rm` is safe to run even on a partially-deleted image — it tolerates a missing header and still cleans up the remaining id object and directory entry, so it's the right tool for this situation rather than manual `
rados` surgery.
As for why `
vm-41032-disk-0` ended up in that partially-deleted state: it's a separate, pre-existing issue from a previous deletion of VM 41032 (unrelated to the template you were working on). The cause is that `
rbd rm` is not an atomic operation — it is a client-driven sequence of individual RADOS operations:
| Step | What gets removed |
|---|
| 1 | Data objects (`rbd_data.<id>.*`) — the actual image contents |
| 2 | Image header (`rbd_header.<id>`) — metadata: size, features, snapshots |
| 3 | Journal (if journaling is enabled) |
| 4 | Object map (`rbd_object_map.<id>`) |
| 5 | Id object (`rbd_id.<name>`) |
| 6 | Directory entry in `rbd_directory` — what `rbd ls` reads |
Each individual step is atomic and durable (if an OSD goes down mid-step, the RADOS client retries until the operation completes). But there is no distributed transaction across the full sequence. If the client process is killed between steps — for example, a node reboot or `
systemctl restart pveproxy` interrupting a `
qm destroy` task after step 2 but before steps 5–6 — those remaining metadata objects are simply never touched again. The result is an image that `
rbd ls` still lists (directory entry present) but that librbd can't open (header gone), producing exactly the `(2) No such file or directory` you saw.
For ongoing Ceph health verification, the key commands:
Code:
# Overall cluster status — start here
ceph -s
# Detailed breakdown of any warnings or errors
ceph health detail
# OSD usage per node — check for imbalances
ceph osd df tree
# Pool-level usage
ceph df detail
# Check for any stuck or degraded placement groups
ceph pg stat
ceph pg dump_stuck # shows stuck inactive/unclean/undersized PGs
# RBD-specific: actual on-disk usage (accounts for thin provisioning and COW)
rbd du -p IKT-Labor
# Verify no images are reporting errors when listing
rbd ls -l IKT-Labor
For periodic health monitoring, `
ceph -s` and `
ceph health detail` cover most cases. If `
ceph health detail` shows `
HEALTH_OK` with no warnings, the cluster is in good shape.
One additional recommendation: check the OSD utilization periodically with `
ceph osd df tree`. When one OSD or node hits significantly higher utilization than others, it's worth checking your CRUSH map weights and `
rbd du` per pool to identify unexpectedly large images.
