Backup failed with: unable to connect to VM 105 qmp socket; VM 105 is broken now

[inxamc]

Hallo Forum,

heute nacht ist das Backup unseres Mailservers fehlgeschlagen und die VM ist nun auch nach unlock und reboot im status running, es kann aber kein Connect auf der Konsole hergestellt werden ( CPU ist 0/DISK IO ist 0) und die VM ist funktionslos.
Es handelt sich um einen älteren Cluster mit 3 x 15 HDDS: pve-manager/7.4-19/f98bf8d4 (running kernel: 5.15.158-2-pve)
Ich habe den Ablauf versucht aus syslog zu dokumentieren:

-- Backup-stop starts at 3:00

Apr 18 03:00:05 amcvh12 pvescheduler[3135106]: INFO: Starting Backup of VM 105 (qemu)
Apr 18 03:00:07 amcvh12 qm[3135147]: shutdown VM 105: UPID:amcvh12:002FD6AB:550F027F:6801A417:qmshutdown:105:root@pam:
Apr 18 03:01:13 amcvh12 pvestatd[1842]: VM 105 qmp command failed - VM 105 not running
Apr 18 03:01:15 amcvh12 qmeventd[3135958]: Starting cleanup for 105
Apr 18 03:01:15 amcvh12 qmeventd[3135958]: trying to acquire lock...
Apr 18 03:01:18 amcvh12 qmeventd[3135958]:  OK
Apr 18 03:01:18 amcvh12 qmeventd[3135958]: vm still running
Apr 18 13:41:11 amcvh12 pvedaemon[1786007]: VM 105 qmp command failed - VM 105 qmp command
    'query-proxmox-support' failed - unable to connect to VM 105 qmp socket - timeout after 51 retries
Apr 18 03:00:05 amcvh12 pvescheduler[3135106]: INFO: starting new backup job: vzdump 103 213 105 --quiet 1 --storage pbs2zfs0 --mailto it@amecko.com --mode stop --mailnotification always
...
Apr 18 13:41:11 amcvh12 pvedaemon[1786007]: VM 105 qmp command failed - VM 105 qmp command 'query-proxmox-support' failed
    - unable to connect to VM 105 qmp socket - timeout after 51 retries
...
Apr 18 13:47:01 amcvh12 pvedaemon[1684161]: VM 105 qmp command 'query-status' failed - unable to connect to VM 105 qmp socket - timeout after 51 retries#012
Apr 18 13:47:01 amcvh12 pvedaemon[3623159]: requesting reboot of VM 105: UPID:amcvh12:003748F7:554A3C32:68023BB5:qmreboot:105:root@pam:
Apr 18 13:47:01 amcvh12 pvestatd[1842]: VM 105 qmp command failed - VM 105 qmp command 'query-proxmox-support' failed -
    unable to connect to VM 105 qmp socket - timeout after 51 retries 
-- reboot
Apr 18 14:13:47 amcvh12 pvesh[4931]: Starting VM 105
Apr 18 14:13:47 amcvh12 pve-guests[6714]: start VM 105: UPID:amcvh12:00001A3A:00002F5F:680241FB:qmstart:105:root@pam:
Apr 18 14:14:13 amcvh12 pvestatd[1899]: VM 105 qmp command failed - VM 105 qmp command 'query-proxmox-support' failed - got timeout
Apr 18 14:14:20 amcvh12 pvesh[4931]: Starting VM 105 failed: start failed: command '/usr/bin/kvm -id 105 -name 'amcbbx-new,debug-threads=on' -no-shutdown -chardev ...
  

-- Ereignis zuvor:
Apr 18 00:00:01 amcvh12 ceph-mon[1651]: 2025-04-18T00:00:01.176+0200 7f2b1ec6b700 -1 received  signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror  (PID: 2999425) UID: 0
Apr 18 00:00:01 amcvh12 ceph-mon[1651]: 2025-04-18T00:00:01.176+0200 7f2b1ec6b700 -1 mon.amcvh12@1(peon) e16 *** Got Signal Hangup ***
Apr 18 00:00:01 amcvh12 ceph-osd[3303]: 2025-04-18T00:00:01.176+0200 7fe531d56700 -1 received  signal: Hangup from killall -q -1 ceph-mon ceph-mgr ceph-mds ceph-osd ceph-fuse radosgw rbd-mirror cephfs-mirror  (PID: 2999425) UID: 0

-- Probleme im Ceph Cluster:

pve-manager/7.4-19/f98bf8d4 (running kernel: 5.15.158-2-pve)

ceph -s
  cluster:
    id:     ae713943-83f3-48b4-a0c2-124c092c250b
    health: HEALTH_ERR
            1 MDSs report slow metadata IOs
            2 scrub errors
            Too many repaired reads on 1 OSDs
            Reduced data availability: 291 pgs inactive, 291 pgs peering
            Possible data damage: 1 pg inconsistent
            1234 slow ops, oldest one blocked for 10467 sec, daemons [osd.0,osd.1,osd.10,osd.12,osd.17,osd.18,osd.19,osd.2,osd.45,osd.47]... have slow ops.
 
  services:
    mon: 3 daemons, quorum amcvh11,amcvh12,amcvh13 (age 75m)
    mgr: amcvh11(active, since 5M), standbys: amcvh13, amcvh12
    mds: 1/1 daemons up, 2 standby
    osd: 45 osds: 45 up (since 2h), 45 in (since 5M)
 
  data:
    volumes: 1/1 healthy
    pools:   6 pools, 433 pgs
    objects: 1.00M objects, 1.9 TiB
    usage:   5.6 TiB used, 6.6 TiB / 12 TiB avail
    pgs:     67.206% pgs not active
             290 peering
             142 active+clean
             1   inconsistent+peering

Es gibt ein verifiziertes PBS-Backup vom Vortag, aber solange die ursächlichen Probleme nicht erkannt bzw. gelöst sind, möchte ich die VM nicht voreilig wieder herstellen.
Ich bräuchte nun dringend Unterstützung beim weiteren Vorgehen.

 

[Falk R.]

@inxamc
Hi du hast eine inkonsistente PG und vermutlich liegen da die Daten vom Mailserver drin. Die eine OSD welche angemeckert wird, würde ich schnellstmöglich ersetzen.
Da die Daten inkonsistent sind, bringt eine Reparatur in der Regel nicht viel. Also mindestens die eine vDisk aus dem Backup wiederherstellen.
Wenn du die betroffene vDisk löschst, sollte auch automatisch die inkonsistente PG verschwinden, ausser da liegen noch Daten anderer VMs.

 

[inxamc]

Hallo Falk, Danke für deine Antwort! Ich verstehe allerdings nicht, was du mit 'eine OSD welche angemeckert wird' meinst? Die inkonsistente pg ist pg17.6e und wird auf [66,59,7] repliziert. Und was meinst du mit 'die betroffene vDisk'? Der MailServer ist die VM 105 und diese wird auf den PBS gesichert.

 

[Falk R.]

Hallo Falk, Danke für deine Antwort! Ich verstehe allerdings nicht, was du mit 'eine OSD welche angemeckert wird' meinst?

Du hast die Meldung:
Too many repaired reads on 1 OSDs
Da musst du mal schauen welche das ist.

Die inkonsistente pg ist pg17.6e und wird auf [66,59,7] repliziert. Und was meinst du mit 'die betroffene vDisk'? Der MailServer ist die VM 105 und diese wird auf den PBS gesichert.

Und bei der Sicherung muss gelesen werden, wobei Ceph festgestellt hat, dass die PG inkonsistent ist.
Eventuell mal checken ob das Scrubbing sauber läuft, weil das eigentlich diesen Fehler eher bemerken sollte, als das direkte lesen beim Backup.
Die inkonsistente PG reparieren, würde ich nicht versuchen, weil aufwändig und auch wenn die Checksumme irgendwann wieder passt, können die Nutzdaten unter Umständen trotzdem inkonsistent sein.