qmp command 'query-proxmox-support' failed

[MG_100]

FYI: Wo das Problem initial in Forum gemeldet wurde habe ich zu den anderen Tests extra noch eine alte/lahme core2duo Kiste genommen, ein Paar VMs drauf gemacht und im Minutentakt für mehrere Tage auf ein externes PBS Instanz gesichert.
Waren über 10 Tausend einzelne Backups nur von dem Server, ohne dass eine der VMs hing, ein Backup fehlgeschlagen ist o.ä. Fehler, ein Grundproblem kann man hier also ausschließen.

Es wäre also Interessant zu wissen welcher Teil deines Setups so ein verhalten provozieren kann.
Welchen Storage verwenden die VMs, welchen die PBS Instanz?
Welche CPUs sind im einsatz, wie viel Last ist auf den Systemen, ...?

Heute hatte ich nach einer Woche ruhe die erneuten Fehlern, allerdings nur auf einem Host was relativ merkwürdig ist.

Betroffen war folgender Host:
2 x Intel Xeon E5-2690v2
Lokale SSD Festplatte
Durschnittliche CPU Last ca. 40 %

Auf dem PBS:
Intel Xeon E3-1275v6
Lokaler HDD Speicher als Directory in den PBS eingebunden.

Was merkwürdig ist von dem Host haben ich mehrfache die identische Konfiguration allerdings ist dies nur bei einem aufgetreten, der PBS backup hat verschiedene VM's auf den Nodes gebackupt allerdings ist dieser nur auf einem Host aufgetreten. Beide haben die selben Proxmox Versionen 6.3-6 bzw. qemu-server: 6.3-10

Dieses Syntom ist bei allen VM's auf den betroffenen Node aufgetreten 10 Sekunden später wo der Backup Job komplett durch war.

Apr  2 01:08:50 vhost06 vzdump[1139474]: INFO: Finished Backup of VM 1146 (00:00:14)
Apr  2 01:08:50 vhost06 vzdump[1139474]: INFO: Starting Backup of VM 1197 (qemu)
Apr  2 01:08:58 vhost06 qm[1146668]: VM 1197 qmp command failed - VM 1197 qmp command 'query-proxmox-support' failed - got timeout

 

[t.lamprecht]

Dieses Syntom ist bei allen VM's auf den betroffenen Node aufgetreten 10 Sekunden später wo der Backup Job komplett durch war.

Also nach dem backup job? Komisch... Die VMs liefen weiter?

 

[MG_100]

Also nach dem backup job? Komisch... Die VMs liefen weiter?

Genau bei einem Host lief paar Sekunden nach dem Backup Schritt für Schritt alle VM's aus, aber auf einen anderen komplett identischen Node lief das Backup ebenfalls aber ohne Nachwirkungen.

 

[CSakel]

Das neuste Update ist installiert und Hostsystem inkl. VMs neugestartet. Problem besteht noch immer!


Auch hier konnte ich feststellen, dass wenn das Backup fertig ist auf den PBS der Fehler erscheint.

 

[t.lamprecht]

Das neuste Update ist installiert und Hostsystem inkl. VMs neugestartet. Problem besteht noch immer!

Hängt eine VM? Das war das eigentliche Problem...

Die "QMP Timeout" Nachricht kann bei einem überladenen Host auch völlig normal sein, aber für immer hängen sollte keine VM mehr.

 

[CSakel]

Hängt eine VM? Das war das eigentliche Problem...

Die "QMP Timeout" Nachricht kann bei einem überladenen Host auch völlig normal sein, aber für immer hängen sollte keine VM mehr.

Die VMS hängen sich auf und die API/pveproxy arbeitet nicht mehr und lädt ewig lang.

 

[t.lamprecht]

Die VMS hängen sich auf und die API/pveproxy arbeitet nicht mehr und lädt ewig lang.

Poste bitte nochmal deine aktuelle pveversion -v.

Auch interessant:

* System (CPU/Mainboard)?
* Memory am Host?
* Wieviele VMs laufen da?
* Welchen Storage nutzen die VMs?
* Last? head -n -0 /proc/pressure/*

 

[CSakel]

Gerne

pveversion -v
proxmox-ve: 6.3-1 (running kernel: 5.4.106-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-8
pve-kernel-helper: 6.3-8
pve-kernel-5.4.106-1-pve: 5.4.106-1
pve-kernel-5.4.103-1-pve: 5.4.103-1
ceph: 15.2.9-pve1
ceph-fuse: 15.2.9-pve1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: residual config
ifupdown2: 3.0.0-1+pve3
ksmtuned: 4.20150325+b1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.8
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-7
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.11-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-9
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.2.0-4
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-9
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.4-pve1

AMD EPYC 7402P
H12SSW-iN
512GB DDR4 ECC Reg. 3200MHz
Etwa 60VMS welche den Ceph Storage nutzen(rep.2).


head -n -0 /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=5.69 avg60=5.89 avg300=6.41 total=54112525121

==> /proc/pressure/io <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=20915604
full avg10=0.00 avg60=0.00 avg300=0.00 total=13063493

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=30891979
full avg10=0.00 avg60=0.00 avg300=0.00 total=14682918

 

[PMDS]

Hallo

Ich bin gestern schmerzlich auf dasselbe Problem gestoßen. Der Trigger scheint hierbei ein "move disk" zu sein. Es trifft allerdings Maschinen, die in keinem Zusammenhang mit dem Vorgang stehen, außer eben auf demselben Proxmox Host zu laufen.

Die Fehlermeldung(en) im syslog sind fast gleichzeitig zum auslösen von "move disk":
pvestatd[1797]: VM <id> qmp command failed - VM <id> qmp command 'query-proxmox-support' failed - got timeout
pvedaemon[3527136]: VM <id> qmp command failed - VM <id> qmp command 'query-proxmox-support' failed - unable to connect to VM <id> qmp socket - timeout after 31 retries

Die Aktion "move disk" wird allerdings nicht ausgeführt, sondern lediglich begonnen (Fortschrittsanzeige erscheint nicht und auf dem Host ist auch keine Aktivität zu verzeichnen).

Bevor der Fehler auftrat (ist über "move disk" reproduzierbar) sind Updates eingespielt worden (Abend des 06.04.2021) bzw. über die Funktion unattended updates ins System gekommen.

Dabei handelt es sich um folgende Pakete:

libjs-underscore (1.9.1~dfsg-1+deb10u1)
libldb1:amd64 (2:1.5.1+really1.4.6-3+deb10u1)
python-ldb (2:1.5.1+really1.4.6-3+deb10u1)
libopenjp2-7:amd64 (2.3.0-2+deb10u2)
librados2 (14.2.19-pve1)
librgw2 (14.2.19-pve1)
python-rados (14.2.19-pve1)
libcephfs2 (14.2.19-pve1)
libradosstriper1 (14.2.19-pve1)
python-rgw (14.2.19-pve1)
librbd1 (14.2.19-pve1)
python-ceph-argparse (14.2.19-pve1)
python-rbd (14.2.19-pve1)
python-cephfs (14.2.19-pve1)
ceph-common (14.2.19-pve1)
ceph-base (14.2.19-pve1)
ceph-mds (14.2.19-pve1)
ceph-mgr (14.2.19-pve1)
ceph-osd (14.2.19-pve1)
ceph-mon (14.2.19-pve1)
ceph (14.2.19-pve1)
proxmox-backup-client (1.0.13-1)
ceph-fuse (14.2.19-pve1)
libpve-storage-perl (6.3-8)

Die Aktion "move disk" lief am 05.04.2021 noch problemlos - jedenfalls waren keine derartigen Stillstände zu beobachten, wurde über das WebGUI ausgelöst und läuft auf Fehler bei der Migration von CepH RBD zu "local storage" (LV in VG).

Da eine Disk zwingend wieder von CepH zu LS mirgiert werden muss, bin ich ebenfalls an einer schnellen Lösung oder zumindest an einem Workaround interessiert.

Vielleicht hilft die Info ...

Gruß, Dietmar

 

[t.lamprecht]

Etwa 60VMS welche den Ceph Storage nutzen(rep.2).

Ist beim RBD Storage Eintrag KRBD gesetzt? KRBD erhöht bei QEMU die Performance von einigen Aktionen um einiges.

Wo läuft Ceph, hyper-converged auf der und anderen Nodes oder extern?

==> /proc/pressure/cpu <==
some avg10=5.69 avg60=5.89 avg300=6.41 total=54112525121

Also CPU Last ist schon eher hoch, in den letzten 5 Minuten konnten durchschnittlich 6.4 Prozesse nicht laufen, obwohl sie wollten (also nicht idle o.ä. waren). Aber naja, hängen sollten VMs nur deswegen nicht unbedingt. Sind die KVM prozesse im "D" state, also wenn top/htop aufmachst?

 

[PMDS]

Hallo

Bedingt durch einen notwendigen "Rückbau" von CepH RBD Storage zu LVM ließ sich feststellen, dass der qmp command timeout auftritt, wenn eine Online Migration der Disk durchgeführt wird; d.h. wenn die Maschine lief und eine der virtuellen Disks migriert werden sollten, kam es zu timeouts.

Vielleicht hilft's.

Ich kann das leider nicht so ohne weiteres ausprobieren oder nachstellen ... versuche es aber mal.

Gruß, Dietmar

 

[t.lamprecht]

Bedingt durch einen notwendigen "Rückbau" von CepH RBD Storage zu LVM ließ sich feststellen, dass der qmp command timeout auftritt, wenn eine Online Migration der Disk durchgeführt wird; d.h. wenn die Maschine lief und eine der virtuellen Disks migriert werden sollten, kam es zu timeouts.

Kann ich nicht generell nachvollziehen.

Um sicherzugehen: Es wird von Ceph RBD (ohne KRBD?) nach LVM (thin?) migriert?

Die Lastmetriken wären auch hier interessant: head -n -0 /proc/pressure/*

Kann evtl. eine Test-VM erstellt werden und die zum Nachstellen verwendet werden?
Wenn das klappt und eine VM wirklich komplett hängt, bitte einen stacktrace posten. Wie man das macht, ist hier beschrieben:
https://forum.proxmox.com/threads/a...er-latest-pve-update.85397/page-2#post-377434

Das hat auch beim Beheben des eigentlichen QMP Fehlers behoben. Unser Fix wurde mittlerweile auch von Upstream-QEMU Entwicklern überprüft und aufgenommen. Es kann noch einen weiteren geben, zumindest ist der aber dann noch spezieller, da die meisten User melden das QEMU 5.2-5 ihre Probleme mit QMP und hängenden VMs gelöst hat.

 

[PMDS]

Hallo

Es handelt sich um ein Cluster aus 4 Nodes, wobei 3 produktiv eingesetzt sind; an allen Nodes existiert dieselbe Konfiguration in punkto Storage; 3 der 4 Nodes sind hinsichtlich der Hardware identisch aufgebaut, die Installation Proxmox ist auf allen 4 identisch.

Die Aktion: Migration einer Disk von CepH zu LVM der VM mit ID 162. Einige Sekunden später tritt der qmp command timeout bei VM ID 106 auf, dann wird die Migration meinerseits abgebrochen; die timeouts kommen jedoch noch einige Mal und betreffen auf VM ID 107.

Die Disks der VM 106 und 107 liegen zu diesem Zeitpunkt auf LVM (Type LVM, nicht LVM Thin).

CepH läuft im Standard installiert, in der Summary wird Typ RBD angegeben; ich gehe davon aus, dass das Storage via GUI eingerichtet wurde - leider sind die Maschinen initial nicht von mir aufgesetzt und es liegt auch keine tiefergehende Dokumentation vor.

Apr 10 12:58:00 <node> systemd[1]: Started Proxmox VE replication runner.
Apr 10 12:58:07 <node> pvedaemon[1984634]: <root@pam> move disk VM 162: move --disk scsi0 --storage store2_vg02
Apr 10 12:58:07 <node> pvedaemon[1984634]: <root@pam> starting task UPID:<node>:001F38CC:26275F10:607184BF:qmmove:162:root@pam:
Apr 10 12:58:20 <node> pvestatd[2438]: status update time (6.087 seconds)
Apr 10 12:58:30 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - got timeout
Apr 10 12:58:33 <node> pvestatd[2438]: status update time (9.204 seconds)
Apr 10 12:58:39 <node> pvedaemon[1984634]: <root@pam> end task UPID:<node>:001F38CC:26275F10:607184BF:qmmove:162:root@pam: unexpected status
Apr 10 12:58:43 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - unable to connect to VM 106 qmp socket - timeout after 31 retries
Apr 10 12:58:46 <node> pvestatd[2438]: status update time (11.239 seconds)
Apr 10 12:58:52 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - unable to connect to VM 106 qmp socket - timeout after 31 retries
Apr 10 12:58:55 <node> pvestatd[2438]: status update time (9.255 seconds)
Apr 10 12:59:00 <node> systemd[1]: Starting Proxmox VE replication runner...
Apr 10 12:59:00 <node> systemd[1]: pvesr.service: Succeeded.
Apr 10 12:59:00 <node> systemd[1]: Started Proxmox VE replication runner.
Apr 10 12:59:02 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - got timeout
Apr 10 12:59:05 <node> pvestatd[2438]: VM 107 qmp command failed - VM 107 qmp command 'query-proxmox-support' failed - got timeout
Apr 10 12:59:09 <node> pvestatd[2438]: status update time (13.254 seconds)
Apr 10 12:59:15 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - got timeout
Apr 10 12:59:18 <node> pvestatd[2438]: VM 107 qmp command failed - VM 107 qmp command 'query-proxmox-support' failed - got timeout
Apr 10 12:59:20 <node> pvestatd[2438]: status update time (10.967 seconds)
Apr 10 12:59:26 <node> pvestatd[2438]: VM 106 qmp command failed - VM 106 qmp command 'query-proxmox-support' failed - unable to connect to VM 106 qmp socket - timeout after 31 retries
Apr 10 12:59:28 <node> pvestatd[2438]: status update time (7.923 seconds)
Apr 10 12:59:51 <node> pvestatd[2438]: storage 'backup' is not online
Apr 10 12:59:52 <node> pvestatd[2438]: status update time (11.707 seconds)
Apr 10 13:00:00 <node> systemd[1]: Starting Proxmox VE replication runner...
Apr 10 13:00:00 <node> systemd[1]: pvesr.service: Succeeded.

Die Auslastung auf dem Knoten:

[root@<node>:~]# head -n -0 /proc/pressure/*
==> /proc/pressure/cpu <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=1182452240

==> /proc/pressure/io <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=47433409835
full avg10=0.00 avg60=0.00 avg300=0.00 total=46610544791

==> /proc/pressure/memory <==
some avg10=0.00 avg60=0.00 avg300=0.00 total=420214311
full avg10=0.00 avg60=0.00 avg300=0.00 total=337062729

Einen erneuten Test mit Erstellung eines trace kann ich nicht so ohne weiteres fahren, da u.a. VMs mit zentralen Diensten stehenbleiben und somit dann die Produktion gestört wird.

Beobachten ließ sich bei Linux Guests "ein" CPU stuck (watchdog), ein Windows 2019 Server hat es mit einem Reboot quittiert.

watchdog: BUG: soft lockup - CPU#3 stuck for 56s! [swapper/3:0]

EDIT: CepH läuft auf intern in den Nodes verfügbaren SSDs, LVM wird über iSCSI von extern eingebunden.

EDIT2: was ebenfalls auffällig war, dass bei einer "offline" Migration, d.h. die betreffende VM war gestoppt und dann wurden die Disks von CepH zu LVM migriert, die Wartezeit bis zum Anlauf der Migration scheinbar abhängig von der Größe der Disk war - ich konnte rund 4 Minuten Wartezeit bei 50GB beobachten, bevor der Prozess überhaupt etwas tat (zuvor zuckte qm move_disk mit <1% CPU) und bei einer 500 GB vergingen rund 15 Minuten und mehr (müsste ich in den Protokollen suchen), allerdings fielen während der Wartezeit keine qmp timeouts auf

Gruß, Dietmar

 

[Stefan_R]

Das neuste Update ist installiert und Hostsystem inkl. VMs neugestartet. Problem besteht noch immer!

Auch hier konnte ich feststellen, dass wenn das Backup fertig ist auf den PBS der Fehler erscheint.

Die Meldungen "got timeout" treten hier anscheinend auch unabhängig vom QMP timeout auf (also auch noch viel später). Das deutet für mich eher auf einen hängenden oder sehr langsamen storage hin.

Bevor der Fehler auftrat (ist über "move disk" reproduzierbar) sind Updates eingespielt worden (Abend des 06.04.2021) bzw. über die Funktion unattended updates ins System gekommen.

Dabei handelt es sich um folgende Pakete:

libjs-underscore (1.9.1~dfsg-1+deb10u1)
libldb1:amd64 (2:1.5.1+really1.4.6-3+deb10u1)
python-ldb (2:1.5.1+really1.4.6-3+deb10u1)
libopenjp2-7:amd64 (2.3.0-2+deb10u2)
librados2 (14.2.19-pve1)
librgw2 (14.2.19-pve1)
python-rados (14.2.19-pve1)
libcephfs2 (14.2.19-pve1)
libradosstriper1 (14.2.19-pve1)
python-rgw (14.2.19-pve1)
librbd1 (14.2.19-pve1)
python-ceph-argparse (14.2.19-pve1)
python-rbd (14.2.19-pve1)
python-cephfs (14.2.19-pve1)
ceph-common (14.2.19-pve1)
ceph-base (14.2.19-pve1)
ceph-mds (14.2.19-pve1)
ceph-mgr (14.2.19-pve1)
ceph-osd (14.2.19-pve1)
ceph-mon (14.2.19-pve1)
ceph (14.2.19-pve1)
proxmox-backup-client (1.0.13-1)
ceph-fuse (14.2.19-pve1)
libpve-storage-perl (6.3-8)

Bei den Paketen wäre jedenfalls nichts direkt QEMU-bezogenes dabei, also mehr Hinweis auf ein storage-problem, zumindest eher als eins mit der VM direkt.

Ich habe versucht den Fehler lokal nachzustellen, mit vielen move-disks zwischen RBD/LVM/iSCSI(+LVM), hat aber alles problemlos funktioniert. Dementsprechen wäre es sehr hilfreich wenn der Fehler u.U. auf einem Testsystem oder dergleichen reproduziert werden könnte, dann könnte man als ersten Schritt die Pakete downgraden und schauen ob der Fehler dadurch behoben wird. Heiße tipps wären hier wohl 'libpve-storage-perl' auf 6.3-7 und 'librbd1' auf die Vorgängerversion. Geht einfach mit apt install libpve-storage-perl=6.3-7 und ähnlich, u.U. gibts auch tab-completion nach dem "=" um die Versionen zu sehen, ansonsten im 'apt changelog <package>' nachschauen. KRBD einschalten wäre auch einen Versuch Wert, die userspace-RBD libraries machen in letzter Zeit häufiger kleine Problemchen.

Ein Trace einer hängenden VM wäre jedenfalls die beste Möglichkeit...

EDIT2: was ebenfalls auffällig war, dass bei einer "offline" Migration, d.h. die betreffende VM war gestoppt und dann wurden die Disks von CepH zu LVM migriert, die Wartezeit bis zum Anlauf der Migration scheinbar abhängig von der Größe der Disk war - ich konnte rund 4 Minuten Wartezeit bei 50GB beobachten, bevor der Prozess überhaupt etwas tat (zuvor zuckte qm move_disk mit <1% CPU) und bei einer 500 GB vergingen rund 15 Minuten und mehr (müsste ich in den Protokollen suchen), allerdings fielen während der Wartezeit keine qmp timeouts auf

Das hat wahrscheinlich mit dem allocation-verhalten von LVM zu tun, beim erstellen des volumes werden alle darin enthaltenen disk-blöcke mit '0' beschrieben. Passiert das beim online-migrate auch? (also wenn es nicht gerade ganz crasht) Sonst kann es auch ein bug auf unserer Seite sein.

 

[PMDS]

Hallo

Ich habe ebenfalls schon versucht, den Fehler zu reproduzieren; aber im Test - wie immer ;-) - läuft natürlich alles problemlos; morgen werde ich mal die Paketversionen zwischen Produktion und Test (also Test auf exakt den Stand der Produktion bringen) angleichen.

Das Storage, zumindest das LVM, ist ausreichend schnell. Benchmarks könnte ich fahren; CepH hat aber in der Implementierung scheinbar massive Latenzen im write, was aber bei einem move_disk von CepH zu LVM keine Rolle spielen sollte (CepH liest dann ja nur).

Ob LVM nun im Vorfeld allokiert hat, habe ich nicht verfolgt - ich bin aber als PM Neuling mal von einem "grow by write" ausgegangen, wie man es z.B. in VMWare einstellen kann.

Die Online Migration verhält sich scheinbar genauso, wobei da schneller der Ausfall einer "benachbarten" VM eintritt, als ein Schreibvorgang ausgelöst wird. Stellt sich die Frage, ob ggf. sogar die stillstehenden VMs da dann den I/O Stack blockieren.

Den Downgrade der Pakete kann ich mir mal anschauen; vielleicht schaffe ich es auch, einen Knoten des Cluster freizuschaufeln und kann dann dort einen Test machen.

Gruß, Dietmar

 

[PMDS]

Hallo

Mittlerweile kann ich das Problem grundsätzlich nachstellen und würde den qmp timeout eher als Effekt sehen; es scheint, wie schon ursprünglich von mir angemerkt, ein I/O Problem bei I/O intensiven Operationen zu sein.

In meinem Testaufbau konnte ich die Situation (noch) nicht zu 100% nachstellen, habe aber zwei Beobachtungen machen können:

a) Migration von Disks von CepH zu LVM (via iSCSI eingebunden) ist extrem langsam, sowohl der Beginn der Operation als auch der Verlauf (Übertragungsrate) trotz entsprechender Netzwerkanbindung
b) es scheint ein Problem hinsichtlich der "Verfügbarkeit" von iSCSI Devices in / an Proxmox Nodes zu geben, wenn die Targets Ubuntu 18.04 sind (jedenfalls hatte ich entsprechende negative Effekte in meinem Testaufbau).

Ich versuche das noch einmal zu verifizieren und würde dann Details aufführen.

Gruß, Dietmar

 

[informant]

Hallo Zusammen, hat jmd,. eine Lösung? habe die neuste Version und auch den Fehler "Jul 30 15:09:40 prometheus pvestatd[1967]: VM 4146 qmp command failed - VM 4146 qmp command 'query-proxmox-support' failed - The command query-proxmox-support has not been found"
Auf allen unseren Servern. Jmd. eine Idee zur Behebung?

 

[t.lamprecht]

D.h. wohl das eine QEMU Version läuft die nicht von der Proxmox VE distro kommt bzw. recht alt ist, wäre zummindest am wahrscheinlichsten.

Kannst du bitte mal die Ausgabe von pveversion -v posten?

 

[informant]

Hallo, gerne:

pveversion -v
proxmox-ve: 6.4-1 (running kernel: 5.4.44-1-pve)
pve-manager: 6.4-13 (running version: 6.4-13/9f411e79)
pve-kernel-5.4: 6.4-5
pve-kernel-helper: 6.4-5
pve-kernel-5.4.128-1-pve: 5.4.128-1
pve-kernel-5.4.124-1-pve: 5.4.124-2
pve-kernel-5.4.44-1-pve: 5.4.44-1
pve-kernel-4.15: 5.4-18
pve-kernel-4.15.18-29-pve: 4.15.18-57
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.2-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.1.0
libproxmox-backup-qemu0: 1.1.0-1
libpve-access-control: 6.4-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.4-3
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.2-3
libpve-storage-perl: 6.4-1
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.1.12-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.6-1
pve-cluster: 6.4-1
pve-container: 3.3-6
pve-docs: 6.4-2
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-4
pve-firmware: 3.2-4
pve-ha-manager: 3.1-1
pve-i18n: 2.3-1
pve-qemu-kvm: 5.2.0-6
pve-xtermjs: 4.7.0-3
qemu-server: 6.4-2
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.5-pve1~bpo10+1

 

[Stefan_R]

Wurden die entsprechenden VMs neu gestartet seit dem letzten upgrade (insbesondere von pve-qemu-kvm)? Ansonsten laufen diese einfach noch mit einer alten Version, der Hinweis im Log dazu ist mehr Warnung als Fehler. Ein reboot oder eine live-migration der betroffenen VMs sollte helfen, die Paketversionen laut 'pveversion' sind grundsätzlich neu genug.