Löschen von Ceph RBD Images schlägt fehl

[arausch_mgr]

Hallo zusammen,

wir betreiben einen Proxmox-Cluster mit 17 PVE Nodes und dazu einen Ceph-Storage Cluster mit 5 Nodes. Die Deployments von VMs erledigen wir durchweg automatisiert mit Terraform/OpenTofu.
Ein Problem, das wir neuerdings sehen, ist, dass beim Löschen von VMs Fehler beim Entfernen der VM-Images im Ceph auftreten. Folgender Fehler wird im Löschen-Task gelogged:

Removing image: 100% complete...done.
Removing image: 1% complete...
Removing image: 2% complete...
Removing image: 3% complete...
Removing image: 4% complete...
Removing image: 5% complete...
Removing image: 6% complete...
Removing image: 7% complete...
Removing image: 8% complete...
Removing image: 9% complete...
Removing image: 10% complete...
Removing image: 11% complete...
Removing image: 12% complete...
Removing image: 13% complete...
Removing image: 14% complete...
Removing image: 15% complete...
Removing image: 16% complete...
Removing image: 17% complete...
Removing image: 18% complete...
Removing image: 19% complete...
Removing image: 20% complete...
Removing image: 21% complete...
Removing image: 22% complete...
Removing image: 23% complete...
Removing image: 24% complete...
Removing image: 25% complete...
Removing image: 26% complete...
Removing image: 27% complete...
Removing image: 28% complete...
Removing image: 29% complete...
Removing image: 30% complete...
Removing image: 31% complete...
Removing image: 32% complete...
Removing image: 33% complete...
Removing image: 34% complete...
Removing image: 35% complete...
Removing image: 36% complete...
Removing image: 37% complete...
Removing image: 38% complete...
Removing image: 39% complete...
Removing image: 40% complete...
Removing image: 41% complete...
Removing image: 42% complete...
Removing image: 43% complete...
Removing image: 44% complete...
Removing image: 45% complete...
Removing image: 46% complete...
Removing image: 47% complete...
Removing image: 48% complete...
Removing image: 49% complete...
Removing image: 50% complete...
Removing image: 51% complete...
Removing image: 52% complete...
Removing image: 53% complete...
Removing image: 54% complete...
Removing image: 55% complete...
Removing image: 56% complete...
Removing image: 57% complete...
Removing image: 58% complete...
Removing image: 59% complete...
Removing image: 60% complete...
Removing image: 61% complete...
Removing image: 62% complete...
Removing image: 63% complete...
Removing image: 64% complete...
Removing image: 65% complete...
Removing image: 66% complete...
Removing image: 67% complete...
Removing image: 68% complete...
Removing image: 69% complete...
Removing image: 70% complete...
Removing image: 71% complete...
Removing image: 72% complete...
Removing image: 73% complete...
Removing image: 74% complete...
Removing image: 75% complete...
Removing image: 76% complete...
Removing image: 77% complete...
Removing image: 78% complete...
Removing image: 79% complete...
Removing image: 80% complete...
Removing image: 81% complete...
Removing image: 82% complete...
Removing image: 83% complete...
Removing image: 84% complete...
Removing image: 85% complete...
Removing image: 86% complete...
Removing image: 87% complete...
Removing image: 88% complete...
Removing image: 89% complete...
Removing image: 90% complete...
Removing image: 91% complete...
Removing image: 92% complete...
Removing image: 93% complete...
Removing image: 94% complete...
Removing image: 95% complete...
Removing image: 96% complete...
Removing image: 97% complete...
Removing image: 98% complete...
Removing image: 99% complete...
Removing image: 100% complete...done.
TASK ERROR: rbd error: rbd: listing images failed: (2) No such file or directory

Interessanterweise ergibt ein

pvesh ls /nodes/<node>/storage/<pool>/content | grep <VMID>

, dass die VM Disk tatsächlich entfernt wurde, in der PVE WebUI ist die VM aber noch vorhanden mit der Referenz auf die VM Disk im Ceph-Pool.
Aufgrund des beschriebenen Problems schlagen alle automatisierten Deployments fehl und man muss die betreffende VM manuell entfernen. Es macht den Eindruck, dass das Problem erst auftritt, wenn im Pool eine gewisse Anzahl von VM Disks gespeichert ist (und ggf. das Löschen/Listing der VM Images zu lange braucht). 100% sicher ist das aber nicht und auch eine "Grenze" in der Anzahl konnten wir bisher nicht identifizieren.

Hat jemand schon mal ein ähnliches Verhalten beobachten können? Gibt's eine Lösung?

Besten Dank und viele Grüße

A. Rausch

 

[fiona]

Hi,
was sagt denn rbd ls -l auf dem Pool? Möglicherweise gibt es da kaputte/partielle Images, die zum Problem führen, siehe:

R

[SOLVED] Post in thread 'rbd error: rbd: listing images failed: (2) No such file or directory (500)'

Aug 20, 2019

Ok, solved...

rbd ls -l cephpool
showed a few correct images but also:
rbd: error opening vm-124-disk-1: (2) No such file or directory
NAME SIZE PARENT FMT PROT LOCK
vm-100-disk-0 80 GiB 2
vm-101-disk-0 80 GiB 2
vm-102-disk-0 80 GiB 2
vm-124-disk-2 550 GiB 2

vm-124-disk-1 was created via "GUI>Create CT" for an unprivileged container.
I then made the mistake to try to restore a privileged containers backup - which obviously failed.
Not sure, but I think the container disappeared when the restore failed or maybe I did delete it.
I then...

• Ralf Zenklusen

• 

 

[arausch_mgr]

Hallo Fiona,

das hatte ich auch schon gesehen und geprüft. Im betreffenden Pool existieren jedoch keine partiellen/kaputten Images. Ich bekomme da eine vollständige Liste der Images ohne jegliche Fehlermeldung.
Auf mich macht es den EIndruck, dass das Löschen des VM Images im Ceph schon erledigt ist, die PVE API aber erst danach versucht, die VM Config zu entfernen und dort dann nochmal ein Delete des VM Images im Ceph triggert (was dann natürlich fehlschlägt) - siehe auch die erste Zeile im Log-Output oben.

Viele Grüße
Andreas

 

[fiona]

Ich würde mal vermuten, die erste Zeile referenziert ein anderes Image oder einen Snapshot, was vorher gelöscht wird. Wie schaut denn die VM-Konfiguration aus? Welche Ceph-Version/Proxmox VE-Version ist in Verwendung, i.e. pveversion -v? Ist beim API-Aufruf der destroy-unreferenced-disks Parameter gesetzt?

 

[arausch_mgr]

Soweit ich das sehe ist destroy-unreferenced-disks gesetzt. Hier mal ein Auszug aus dem Log des betreffenden Nodes:
::ffff:<IP removed> - terraform@pam!gitlab-ci [28/05/2025:11:27:23 +0200] "DELETE /api2/json/nodes/<node>/qemu/806/?destroy-unreferenced-disks=1&purge=1 HTTP/1.1" 200 93

Ceph läuft auf 17.2, PVE auf 8.4.1:

proxmox-ve: 8.4.0 (running kernel: 6.8.12-7-pve)
pve-manager: 8.4.1 (running version: 8.4.1/2a5fa54a8503f96d)
proxmox-kernel-helper: 8.1.1
proxmox-kernel-6.8: 6.8.12-7
proxmox-kernel-6.8.12-7-pve-signed: 6.8.12-7
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.11-6-pve-signed: 6.5.11-6
amd64-microcode: 3.20191218.1
ceph-fuse: 17.2.8-pve2
corosync: 3.1.9-pve1
criu: 3.17.1-2+deb12u1
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx11
intel-microcode: 3.20230214.1~deb11u1
ksmtuned: 4.20150326+b1
libjs-extjs: 7.0.0-5
libknet1: 1.30-pve2
libproxmox-acme-perl: 1.6.0
libproxmox-backup-qemu0: 1.5.1
libproxmox-rs-perl: 0.3.5
libpve-access-control: 8.2.2
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.1.0
libpve-cluster-perl: 8.1.0
libpve-common-perl: 8.3.1
libpve-guest-common-perl: 5.2.2
libpve-http-server-perl: 5.2.2
libpve-network-perl: 0.11.2
libpve-rs-perl: 0.9.4
libpve-storage-perl: 8.3.6
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.6.0-2
openvswitch-switch: 3.1.0-2+deb12u1
proxmox-backup-client: 3.4.1-1
proxmox-backup-file-restore: 3.4.1-1
proxmox-kernel-helper: 8.1.1
proxmox-mail-forward: 0.3.2
proxmox-mini-journalreader: 1.4.0
proxmox-widget-toolkit: 4.3.10
pve-cluster: 8.1.0
pve-container: 5.2.6
pve-docs: 8.4.0
pve-edk2-firmware: 4.2025.02-3
pve-firewall: 5.1.1
pve-firmware: 3.15-3
pve-ha-manager: 4.0.7
pve-i18n: 3.4.2
pve-qemu-kvm: 9.2.0-5
pve-xtermjs: 5.5.0-2
qemu-server: 8.3.12
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0

Hier noch die VM config:

agent: enabled=1,fstrim_cloned_disks=1,type=virtio
balloon: 0
boot: order=scsi0;net0
cicustom: user=cephfs-misc-pool:snippets/testvm_userdata.yaml
cores: 2
cpu: cputype=host
cpuunits: 1024
ide2: vm-pool-ci:vm-806-cloudinit,media=cdrom
ipconfig0: gw=<GW IP>,ip=<IP>
kvm: 1
memory: 1024
meta: creation-qemu=9.0.2,ctime=1743413180
name: testvm
nameserver: <DNS IP>
net0: virtio=06:01:20:72:ec:0c,bridge=vmbr0,firewall=0
numa: 0
onboot: 1
ostype: l26
scsi0: vm-pool:vm-806-disk-0,cache=none,replicate=0,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=20125c7d-be48-456d-9f89-1b367ede5a52
sockets: 1
vga: memory=16,type=std
vmgenid: 2c5692ba-01e9-4e34-a69d-be99d765d742

 

[fiona]

Soweit ich das sehe ist destroy-unreferenced-disks gesetzt. Hier mal ein Auszug aus dem Log des betreffenden Nodes:
::ffff:<IP removed> - terraform@pam!gitlab-ci [28/05/2025:11:27:23 +0200] "DELETE /api2/json/nodes/<node>/qemu/806/?destroy-unreferenced-disks=1&purge=1 HTTP/1.1" 200 93

Mit destroy-unreferenced-disks=1 werden, nach dem Löschen der referenzierten Disks, alle Storages gescannt, um unreferenzierte Disks, die der VM gehören, zu finden und zu löschen. Im Normalfall gibt es eh keine solchen Disks. Nur durch Fehler-Situationen bei manchen Operationen wie Migration mit lokalen Disken, kann es manchmal passieren, dass Disken ohne Referenz "liegen bleiben".

Schätze beim Scannen tritt das Problem mit dem listing images failed auf. Es könnte am Pool noch irgendwas nicht ganz synchronisiert/aufgeräumt sein. destroy-unreferenced-disks=0 könnte ein Workaround sein.

ide2: vm-pool-ci:vm-806-cloudinit,media=cdrom

Die erste Log-Zeile bezieht sich vermutlich auf diese Disk.

 

[arausch_mgr]

Richtig, dass die Cloudinit-Disk auch in einem Ceph-Pool liegt, war mir entfallen
Kann man zentral destroy-unreferenced-disks=0 setzen bzw. das Verhalten dazu konfigurieren oder ist das tatsächlich eine Option, die bei jedem API-Call gesetzt werden müsste?

 

[fiona]

Richtig, dass die Cloudinit-Disk auch in einem Ceph-Pool liegt, war mir entfallen
Kann man zentral destroy-unreferenced-disks=0 setzen bzw. das Verhalten dazu konfigurieren oder ist das tatsächlich eine Option, die bei jedem API-Call gesetzt werden müsste?

Die Option muss eigentlich gar nicht gesetzt werden, der Default-Wert ist schon 0. Bei Dir ist aber explizit destroy-unreferenced-disks=1 gesetzt. Musst schauen, wo Du das bei Terraform einstellen kannst.

 

[arausch_mgr]

Besten Dank für den Support. Wir haben unsere API entsprechend angepaßt und jetzt läufts. Dank nochmal!