Ceph: VM-Backup hängt, rbd info läuft in Timeout

D

DzTimo

New Member
Proxmox Subscriber
Jul 30, 2025
11
2
3
Moin zusammen!

beim betroffenen Cluster handelt es sich um einen 8-Node Proxmox-Cluster, bei dem 6 Nodes davon einen Ceph-Cluster bereitstellen.

Auf einem der Nodes (vs4, stellt keine Ceph-Dienste bereit, nutzt aber den Ceph-rbd-Pool für VMs) habe ich das Problem, dass sich die darauf befindliche VM nicht backuppen lässt. Das Problem tritt auf dem Node auch mit anderen VMs auf. Sofern man diese auf einen anderen Node migriert ist das Backup kein Problem. Auch der andere Node, der die selbe Netzwerkkonfiguration nutzt und auch keine Ceph-Dienste bereitstellt, hat keine derartigen Probleme.

Der Log vom Backup sieht wie folgt aus:

code_language.shell: 
INFO: starting new backup job: vzdump 119 --notes-template '{{guestname}}' --storage backupvm --notification-mode auto --mode snapshot --remove 0 --node virtualserv4
INFO: Starting Backup of VM 119 (qemu)
INFO: Backup started at 2025-07-30 13:10:46
INFO: status = running
INFO: VM Name: cnetz
INFO: include disk 'scsi0' 'remote-ceph:vm-119-disk-0' 50G
[klicke auf Abbrechen]
ERROR: Backup of VM 119 failed - cannot determine size of volume 'remote-ceph:vm-119-disk-0' - rbd error: interrupted by signal
INFO: Failed at 2025-07-30 13:14:35
INFO: Backup job finished with errors
INFO: notified via target `mail-to-root`
TASK ERROR: job errors

In diesem Zustand bleibt der Backup-Job hängen, wenn man ihn nicht manuell abbricht. Selbst nach Tagen bricht der Backup-Job nicht ab. Auch wenn Testweise nur eine einzige VM auf dem Node läuft, tritt das Problem auf. Sobald die VM auf dem Node läuft, können die RBD-Volumeninformationen via
code_language.shell: 
rbd info remote-ceph/vm-119-disk-0
nicht mehr abgefragt werden. Wenn die VM auf einen anderen Node migriert wurde, funktioniert das rbd info so wie erwartet. Generell funktioniert rbd info auf den anderen Nodes im Cluster klaglos, egal ob die betroffene VM auf demselben Node läuft oder nicht.

rbd-info
code_language.shell: 
rbd image 'vm-119-disk-0':
        size 2025-07-30T12:55:24.665+0200 7f6211bb1980 10 librados: Objecter returned from call r=0
171 GiB in 43776 objects
        order 22 (4 MiB objects)
        snapshot_count: 0
        id: 27c5cb2a390f51
        block_name_prefix: rbd_data.27c5cb2a390f51
        format: 2
        features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
        op_features:
        flags:
        create_timestamp: Tue Sep  7 13:49:17 2021
        access_timestamp: Wed Jul 30 12:55:01 2025
        modify_timestamp: Wed Jul 30 12:54:31 2025

Wenn die VM auf dem betroffenen Node läuft und es nicht funktioniert:

code_language.shell: 
rbd --debug-rados 20 info remote-ceph/vm-119-disk-0
2025-07-30T13:21:45.220+0200 74d507a60980  1 librados: starting msgr at
2025-07-30T13:21:45.220+0200 74d507a60980  1 librados: starting objecter
2025-07-30T13:21:45.220+0200 74d507a60980  1 librados: setting wanted keys
2025-07-30T13:21:45.220+0200 74d507a60980  1 librados: calling monclient init
2025-07-30T13:21:45.222+0200 74d507a60980  1 librados: init done
2025-07-30T13:21:45.222+0200 74d507a60980 10 librados: wait_for_osdmap waiting
2025-07-30T13:21:45.227+0200 74d507a60980 10 librados: wait_for_osdmap done waiting

Was mich daran am meisten wundert ist, dass die VM ansonsten völlig klaglos läuft.

pveversion -v (auf allen Nodes gleich, PVE 8.4.0, Ceph 19.2 squid):

Code: 
proxmox-ve: 8.4.0 (running kernel: 6.8.12-11-pve)
pve-manager: 8.4.1 (running version: 8.4.1/2a5fa54a8503f96d)
proxmox-kernel-helper: 8.1.1
pve-kernel-6.1: 7.3-6
pve-kernel-5.19: 7.2-15
pve-kernel-5.13: 7.1-9
proxmox-kernel-6.8.12-11-pve-signed: 6.8.12-11
proxmox-kernel-6.8: 6.8.12-11
proxmox-kernel-6.8.12-8-pve-signed: 6.8.12-8
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
pve-kernel-6.1.15-1-pve: 6.1.15-1
pve-kernel-5.19.17-2-pve: 5.19.17-2
pve-kernel-5.13.19-6-pve: 5.13.19-15
ceph: 19.2.1-pve3
ceph-fuse: 19.2.1-pve3
corosync: 3.1.9-pve1
criu: 3.17.1-2+deb12u1
frr-pythontools: 10.2.2-1+pve1
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
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.2
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
libqb0: 1.0.5-1
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
proxmox-backup-client: 3.4.1-1
proxmox-backup-file-restore: 3.4.1-1
proxmox-firewall: 0.7.1
proxmox-kernel-helper: 8.1.1
proxmox-mail-forward: 0.3.2
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.11
pve-cluster: 8.1.0
pve-container: 5.2.7
pve-docs: 8.4.0
pve-edk2-firmware: 4.2025.02-3
pve-esxi-import-tools: 0.7.4
pve-firewall: 5.1.2
pve-firmware: 3.15-4
pve-ha-manager: 4.0.7
pve-i18n: 3.4.4
pve-qemu-kvm: 9.2.0-6
pve-xtermjs: 5.5.0-2
qemu-server: 8.4.1
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.7-pve2

Der Ceph-Cluster meldet "HEALTH_OK".

Habt ihr eine Idee, woran das liegen könnte?
 
mhm, du schriebst:
8-Node Proxmox-Cluster, bei dem 6 Nodes davon einen Ceph-Cluster bereitstellen.
Click to expand...

Könntest du ggf. erläutern, wie der ceph storage auf den zwei Hosts ohne Ceph Dienste eingebunden ist?
Code: 
cat /etc/pve/storage.cfg

Habt ihr auf den Knoten ganz normal die ceph packages installiert und dort einfach nur keine OSDs eingebunden?
 
Ja, wir haben über PVE die Ceph-Packages installiert, jedoch keine Mon/Mgr/OSDs auf den beiden Nodes konfiguriert.

Die storage-Konfiguration:

Code: 
rbd: remote-ceph
        content rootdir,images
        krbd 0
        pool remote-ceph
 
Bist du dir sicher, das alles im Netzwerk identisch ist? Auch LACP und MTU Size?
Läuft die VM denn ganz normal auf dem Host? Patchstände alle identisch?
 
Moin,

das Ceph Front/Backend läuft auf dem selben Netz. Dort sind alle NICs als Active/Backup konfiguriert, MTU ist überall auf default (1500).

Die VM läuft ganz normal auf dem Host, Patchstand ist überall der selbe - Das Problem gibt es wohl schon länger.

Was mich am meisten wundert ist, dass sich "rbd info" ganz normal verhält, solange keine VM auf dem betroffenen Node läuft. Sobald die VM dort läuft, funktioniert rbd info nicht mehr.
 
DzTimo said:
Moin,

das Ceph Front/Backend läuft auf dem selben Netz. Dort sind alle NICs als Active/Backup konfiguriert, MTU ist überall auf default (1500).

Die VM läuft ganz normal auf dem Host, Patchstand ist überall der selbe - Das Problem gibt es wohl schon länger.

Was mich am meisten wundert ist, dass sich "rbd info" ganz normal verhält, solange keine VM auf dem betroffenen Node läuft. Sobald die VM dort läuft, funktioniert rbd info nicht mehr.
Click to expand...
Da kann man jetzt viel Energie ins Troubleshooting stecken, eventuell mal Dienstleister wie z.B. inett mal anfragen oder den Node mal eben neu installieren.
 
Hallo,

kann auch was ganz Doofes sein, z.B. wenn die VM eine IP des PVE Nodes benutzt oder die MAC Adresse, sowas Fieses.
 
mhm also aus der Ferne ist das schwierig zu beurteilen.

ggf. hilft dir ein strace.

Code: 
apt install strace
strace rbd --debug-rados 20 info remote-ceph/vm-119-disk-0

(Oder eine Neuinstallation des Knotens bzw. ggf. auch schon des Cephs.)
 
You must log in or register to reply here.
Top Bottom