VM wiederholt in "Resume"-Zustand, anschließend Guest-Agent-Timeouts und VM stoppt

H

high_performer

Well-Known Member
Jul 16, 2018
30
6
68

​

Hallo zusammen,

da meine KI auch nicht weiter weiß, wende ich mich lieber an richtiges Wissen.
Es folgt ein KI generierter Text (muß man das mittlerweile auch (hier) kennzeichnen? ;)), der meine Aktivitäten darstellt.

Ich beobachte bei einer einzelnen Windows-VM ein merkwürdiges Verhalten und hoffe auf Ideen, in welche Richtung ich weiter analysieren kann.

Umgebung​

  • Proxmox VE 9.x
  • VM auf Ceph RBD
  • OVMF / UEFI
  • TPM 2.0
  • VirtIO SCSI (virtio-scsi-single)
  • VirtIO Netzwerk
  • VirtIO-Treiber 0.1.285 im Gast
  • Windows Server als Gast
  • Proxmox Backup Server für Snapshot-Backups mit QEMU Guest Agent

Symptome​

Die VM gerät offenbar wiederholt in einen Zustand, in dem sie nicht mehr normal reagiert.

Im PVE-Log erscheinen dann QGA-Timeouts:



VM xxx qga command failed - VM xxx qga command 'guest-ping' failed - got timeout


Beispiel:



08:09:51 qga command failed - guest-ping timeout
08:21:21 qga command failed - guest-ping timeout


Anschließend wurde manuell ein Resume ausgelöst:



qmresume:<vmid>


Der Task endet dabei mit:



stopped: OK


Direkt danach erscheinen im Journal:



tapXXXi0 ... entered disabled state
...
<vmid>.scope: Deactivated successfully.
Starting cleanup for <vmid>
Finished cleanup for <vmid>


Danach steht die VM auf:



status: stopped


Auffälligkeit​

Bereits einige Tage zuvor gab es während eines Node-Neustarts die Meldung:



VM is paused - stop instead of shutdown


Daher vermute ich inzwischen, dass die VM bereits vor dem Resume in einem Paused-/Suspended-ähnlichen Zustand war.

Backup-Verhalten​

PBS-Backups laufen erfolgreich:



guest-fsfreeze
guest-fsthaw


Auch inkrementelle Dirty-Bitmap-Backups funktionieren problemlos.

Beispiel:



using fast incremental mode (dirty-bitmap)
backup was done incrementally


Es gibt keine Backup-Fehler.

Windows-Seite​

Die Windows-VM wurde umfangreich geprüft:

Dateisystem​



chkdsk /scan
Dateisystem wurde überprüft, keine Probleme festgestellt.


Systemdateien​



sfc /scannow
Windows-Ressourcenschutz hat keine Integritätsverletzungen gefunden.


Komponentenstore​



DISM /Online /Cleanup-Image /CheckHealth
Es wurde keine Komponentenspeicherbeschädigung erkannt.


Eventlogs​

Keine Hinweise auf:

  • Bluescreens
  • Bugchecks (Event 1001)
  • NTFS-Fehler
  • StorPort-Fehler
  • Disk-Fehler
  • VirtIO-Treiberfehler

Ceph / Host​

Bisher keine auffälligen Korrelationen gefunden:

  • keine OOM-Killer-Ereignisse
  • keine offensichtlichen Ceph-Fehler
  • keine PBS-Fehler
  • keine erkennbaren Host-Kernel-Fehler zum Zeitpunkt des Auftretens

Frage​

Hat jemand schon einmal beobachtet, dass eine VM wiederholt in einen Zustand gerät, in dem:



guest-ping -> timeout
Resume
VM stoppt unmittelbar danach


bzw. dass eine VM als „paused“ erscheint und beim Resume anschließend beendet wird?

Mich interessiert insbesondere:

  • bekannte Probleme mit PVE 9.x und qmresume
  • Erfahrungen mit VirtIO-Treiber 0.1.285
  • bekannte QEMU-/QGA-bezogene Ursachen
  • weitere Logs oder Debug-Möglichkeiten, die beim nächsten Auftreten hilfreich wären
Vielen Dank!
 
Die guest-ping-Timeouts würd ich eher als Folge sehen. Wenn QEMU die VM pausiert hat, antwortet auch der Agent nicht mehr. Spannender ist, warum sie pausiert. Beim nächsten Mal bitte vor dem Resume nachschauen:
Code: 
qm status <vmid> --verbose | grep -i status
qm monitor <vmid>
# dort dann: info status
Steht da sowas wie paused (io-error) oder internal-error, hast du schon die Richtung. Bei io-error auf RBD würd ich direkt Richtung Ceph schauen, z.B. nearfull/full Pool (ENOSPC pausiert die VM), slow ops oder ein geblocklisteter Client. Dafür ceph health detail und ceph df zum Zeitpunkt.

Dass die VM direkt nach dem Resume weg ist, deutet drauf hin, dass sich der QEMU-Prozess beim Fortsetzen selbst beendet. Das cleanup-Zeug im Log kommt nur danach. Schau mal im Journal rund um den Zeitpunkt nach Zeilen von kvm/QEMU, also Assertions, segfault o.ä.: journalctl -b --since "..." | grep -iE 'kvm|qemu|<vmid>'. Poste außerdem mal qm config <vmid> und pveversion -v, mit "9.x" kann man wenig anfangen. Interessant sind vor allem Maschinentyp, cache-Modus und die QEMU-Version.
 
  • Like
Reactions: UdoB
Ergänzende Informationen:

  • Die VM wurde inzwischen auf einen anderen Cluster-Node migriert (offline, da die VM bereits gestoppt war).
  • Innerhalb des Windows-Gasts wurden folgende Prüfungen durchgeführt:



chkdsk /scan
→ keine Fehler

sfc /scannow
→ keine Integritätsverletzungen

DISM /Online /Cleanup-Image /CheckHealth
→ keine Komponentenspeicherbeschädigung
  • Im Gerätemanager keine unbekannten Geräte oder Treiberfehler. VirtIO-Netzwerk, VirtIO-SCSI und VirtIO-Serial werden fehlerfrei angezeigt.
  • Die VM verwendet:


VirtIO-Treiber: 0.1.285

Display: QXL

Machine Type: pc-q35-7.2

BIOS: OVMF + Secure Boot

TPM 2.0

Storage: Ceph RBD
  • Ich habe außerdem festgestellt, dass in Windows per Gruppenrichtlinie ein Energiesparmodus nach 8 Stunden konfiguriert ist.

powercfg /a
→ Standby (S3) verfügbar
Allerdings finden sich in den Windows-Ereignisprotokollen keine Hinweise auf einen tatsächlichen Wechsel in den Standby bzw. ein Resume:

keine Event ID 42 (Entering Sleep)

keine Event ID 107 (Resume from Sleep)
Daher habe ich aktuell keinen Beleg dafür, dass die VM tatsächlich in den Windows-Energiesparmodus gewechselt ist.

  • Der letzte erfolgreiche PBS-Backup-Lauf erfolgte am Vorabend. Guest Agent, fs-freeze/fs-thaw und das inkrementelle Backup funktionierten dabei fehlerfrei.
  • Versionsstand:


  • pveversion -v
    proxmox-ve: 9.2.0 (running kernel: 7.0.14-25-pve)
    pve-manager: 9.2.21 (running version: 9.2.21/4f6e0ac86f9e8c7f)
    proxmox-kernel-helper: 9.2.0
    proxmox-kernel-7.0: 7.0.14-25
    proxmox-kernel-7.0.14-25-pve-signed: 7.0.14-25
    proxmox-kernel-7.0.14-23-pve-signed: 7.0.14-23
    proxmox-kernel-7.0.12-1-pve-signed: 7.0.12-1
    proxmox-kernel-7.0.2-6-pve-signed: 7.0.2-6
    amd64-microcode: 3.20251202.1~bpo13+1
    ceph: 19.2.6-pve4
    ceph-fuse: 19.2.6-pve4
    corosync: 3.1.10-pve3
    criu: 4.1.1-1
    frr-pythontools: 10.6.1-1+pve3
    ifupdown2: 3.3.0-1+pmx12
    ksm-control-daemon: 1.5-1
    libjs-extjs: 7.0.0-7
    libproxmox-acme-perl: 1.7.2
    libproxmox-backup-qemu0: 2.0.3
    libproxmox-rs-perl: 0.4.1
    libpve-access-control: 9.1.2
    libpve-apiclient-perl: 3.4.3
    libpve-cluster-api-perl: 9.1.6
    libpve-cluster-perl: 9.1.6
    libpve-common-perl: 9.2.3
    libpve-guest-common-perl: 6.0.5
    libpve-http-server-perl: 6.0.5
    libpve-network-perl: 1.6.7
    libpve-notify-perl: 9.1.6
    libpve-rs-perl: 0.15.3
    libpve-storage-perl: 9.1.13
    libspice-server1: 0.15.2-1+b1
    lvm2: 2.03.31-2+pmx1
    lxc-pve: 7.0.0-2
    lxcfs: 7.0.0-pve1
    novnc-pve: 1.7.0-2
    proxmox-backup-client: 4.2.8-1
    proxmox-backup-file-restore: 4.2.8-1
    proxmox-backup-restore-image: 1.0.0
    proxmox-enterprise-support-keyring: 1.1
    proxmox-firewall: 1.2.3
    proxmox-kernel-helper: 9.2.0
    proxmox-mail-forward: 1.0.3
    proxmox-mini-journalreader: 1.7
    proxmox-offline-mirror-helper: 0.7.4
    proxmox-widget-toolkit: 5.2.10
    pve-cluster: 9.1.6
    pve-container: 6.1.14
    pve-docs: 9.2.13
    pve-edk2-firmware: 4.2026.08-1
    pve-esxi-import-tools: 1.0.1
    pve-firewall: 6.0.6
    pve-firmware: 3.18-7
    pve-ha-manager: 5.2.5
    pve-i18n: 3.10.0
    pve-qemu-kvm: 11.0.3-4
    pve-xtermjs: 6.0.0-2
    qemu-server: 9.2.11
    smartmontools: 7.5-pve2
    spiceterm: 3.4.2
    swtpm: 0.8.0+pve3
    vncterm: 1.9.2
    zfsutils-linux: 2.4.4-pve1
 
You must log in or register to reply here.
Top Bottom
Back