Debian VM - Tastatur-Eingaben u. Maus sehr stark zeitvergögert

[frank@vmforum]

Hallo,
benutze schon sehr lange eine Debian-VM unter Workstation Pro.
Dies lief sehr lange absolut reibungslos. Es war praktisch nicht zu spüren, daß man in einer virtuellen Umgebung arbeitet.
Seit einiger Zeit gibt es zuerst immer mal wieder starke Aussetzer bei der Tastatur-Eingabe oder auch beim Arbeiten mit der Maus.
Die VM ist immer mal wieder wie "eingefroren", nach dem Aussetzer kommen dann plötzlich alle Tastatureingaben auf einmal oder die Maus saußt über den Bildschirm, weil alles aus dem "Puffer" dann adhoc nachgezogen wird.

Das Problem wird nun immer schlimmer. Je mehr ich tue/ausprobiere, desto mehr verstärkt sich das Problem

• Ich hatte die Hoffnung, daß ein Wechsel von Debian 11 auf Debian 12 vielleicht etwas bewirkt.
• Dann habe ich nach dem Wechsel die VMware Tools neu installiert
• Tools wieder deinstalliert und open-vm-tools aus Distribution installiert

Angefangen hat es schon vor einiger Zeit, war anfänglich zwar nervig, aber erträglich, deshalb kann ich nicht mehr sagen, was das Problem ausgelöst haben könnte.
Das Problem findet auf jeden Fall innerhalb der VM statt. Ich kann zu den Problemzeitpunkten problemlos in anderen VMs oder dem VM-Host selbst arbeiten. Dort hatte ich das Problem noch nie.
Wenn es mich zu sehr nervt und ich die Debian-VM neu starte, dann ist das Problem eine gewisse Zeit weg.
Ich habe auch festgestellt, daß es häufig reicht, wenn ich nur die Workstation-GUI beendet, die VM im Hintergrund laufen lasse und dann die Workstation-GUI wieder neu starte.

hat jemand ein paar Tipps, Tricks, wie ich der Ursachr auf die Schliche kommen könnte?
ich würde ungern die Debian-VM neu aufsetzen, da hierin schon einige Arbeit steckt

ciao

[rprengel]

Hallo,
benutze schon sehr lange eine Debian-VM unter Workstation Pro.
Dies lief sehr lange absolut reibungslos. Es war praktisch nicht zu spüren, daß man in einer virtuellen Umgebung arbeitet.
Seit einiger Zeit gibt es zuerst immer mal wieder starke Aussetzer bei der Tastatur-Eingabe oder auch beim Arbeiten mit der Maus.
Die VM ist immer mal wieder wie "eingefroren", nach dem Aussetzer kommen dann plötzlich alle Tastatureingaben auf einmal oder die Maus saußt über den Bildschirm, weil alles aus dem "Puffer" dann adhoc nachgezogen wird.

Das Problem wird nun immer schlimmer. Je mehr ich tue/ausprobiere, desto mehr verstärkt sich das Problem

• Ich hatte die Hoffnung, daß ein Wechsel von Debian 11 auf Debian 12 vielleicht etwas bewirkt.
• Dann habe ich nach dem Wechsel die VMware Tools neu installiert
• Tools wieder deinstalliert und open-vm-tools aus Distribution installiert

Angefangen hat es schon vor einiger Zeit, war anfänglich zwar nervig, aber erträglich, deshalb kann ich nicht mehr sagen, was das Problem ausgelöst haben könnte.
Das Problem findet auf jeden Fall innerhalb der VM statt. Ich kann zu den Problemzeitpunkten problemlos in anderen VMs oder dem VM-Host selbst arbeiten. Dort hatte ich das Problem noch nie.
Wenn es mich zu sehr nervt und ich die Debian-VM neu starte, dann ist das Problem eine gewisse Zeit weg.
Ich habe auch festgestellt, daß es häufig reicht, wenn ich nur die Workstation-GUI beendet, die VM im Hintergrund laufen lasse und dann die Workstation-GUI wieder neu starte.

hat jemand ein paar Tipps, Tricks, wie ich der Ursachr auf die Schliche kommen könnte?
ich würde ungern die Debian-VM neu aufsetzen, da hierin schon einige Arbeit steckt

ciao

welche VM Version?
Welcher Desktop im Hostsystem.
Tools überall aktuell?
Tritt das problem auch auch wenn in der VM nur in der Konsole gearbeitet wird? Remote per shh etc..
Standardauflösungen in Gebrauch?

Im esrten Wurf würde ich beim Desktop/ Grafiktreibern suchen.

[frank@vmforum]

welche VM Version?
Welcher Desktop im Hostsystem.
Tools überall aktuell?
Tritt das problem auch auch wenn in der VM nur in der Konsole gearbeitet wird? Remote per shh etc..
Standardauflösungen in Gebrauch?

Der VM-Host läuft unter Debian11 mit XFCE (also Gnome)
Es kommt Workstation 17 Pro zum Einsatz
In der VM selbst kommt open-vmtools zum Einsatz, aktuellste Version aus Debian12 incl. Backports
Ich verwende meine VMs alle im Full-Screen mit automatischer Auflösungsanpassung.
Per ssh/remote habe ich noch nie auf meine VMs zugegriffen, ich vermute Du meinst die Option VNC Connection, die habe ich überall abgeschaltet, weil sich der Sinn auf meinem Laptop mir noch nicht erschlossen hat.

Im esrten Wurf würde ich beim Desktop/ Grafiktreibern suchen.

ich bin mir im Moment auch nicht mehr so sicher, ob das Problem in der VM oder außerhalb liegt. Da ich aber bisher immer nur in dieser einen VM habe, bin ich davon ausgegangen, daß das Problem in dieser VMs liegen muß.
In anderen VMs und im Host selbst habe ich diese Probleme noch nie erlebt. Diese funktionieren auch immer weiterhin reibungslos, selbst wenn die problematische VM mal wieder zickt
Allerdings muß ich auch sagen, daß ich mich zu 90% in der problematischen VM bewege (Hauptarbeitsgebiet), die restlichen VMs sind nur seltenes Beiwerk, der Host ist nur der Host

[Dayworker]

VMware bevorzugt eigentlich immer die externen Zugriffsmöglichkeiten des jeweiligen Gastes zu nutzen, weil dann dafür optimierte Wege genutzt werden und die VMware-Console rein für alle administrativen Dinge (OS-Install etc) einzusetzen. Für die Performance in der VM ist es ungemein wichtig, daß die Energiesparfunktionen im Gast abgeschaltet sind. Nutzt man die VMware-Anwendung auch zum Arbeiten im Gast, machen sich dann sowohl die Auflösung als auch die Bildwiederholrate des Gastes trotz installierter Open-VM-Tools noch in einer höheren CPU-Belastung des Hosts bemerkbar. Nutzt man beispielsweise RDP unter Windows oder SSH unter Linux fallen diese beiden Zusatzaufgaben weg. Es müssen nur noch veränderliche Daten übertragen werden und die aufwendige Grafische Darstellung übernimmt dann der zugreifende Rechner. Die CPU-Belastung sinkt dadurch zusätzlich.

Bei stark verzögerter Reaktion oder springenden Mauszeiger in einer VM könnte auch eine zu großzügige Gast-Austattung bei vRAM und vCPU infrage kommen. Entsprechend dem vRAM im Gast wird immer auch eine entsprechend große VMEM-Datei auf dem Host angelegt, das fordert den Host-Datenträger zusätzlich und mit zuviel vCPUs muß der Gast immer wieder darauf warten, daß diese Menge an Kernen auf dem Host auch frei ist. Es ist bei VMware daher nie verkehrt, einen Gast erstmal nur minimal mit Hardware auszustatten und ggf zu erhöhen. Für maximale Performance sind VMs sowieso nicht gemacht, Echtblech ist immer schneller.

[frank@vmforum]

Es geht mir nicht um maximale Performance, klar das die VM Leistung schluckt.
Der Host hat neben dem Betrieb der VMs keine zusätzlichen Aufgaben, Leistung ist genug da. Der Host hat 8 CPUs u. 32GB Speicher, die betroffene VM hat 4 CPUs und hatte bisher 10GB Speicher. Daneben läuft noch eine winzige VM, meist im suspend mode, d.h. die zieht auch nicht den Saft weg.
Ich betreibe die VM schon sehr lange, zuvor auch auf einem schwächeren Rechner und das Handling in der VM war immer zufriedenstellend.
Jetzt aber war das Arbeiten darin immer mal wieder nicht mehr möglich. Wenn Du etwas tippst, wie jetzt gerade hier, aber Du Deine Eingaben gar nicht siehst, sondern diese dann gefühlt 10sec später am Stück auftauchen.
oder Du mit der Maus wohin klickst und nicht weißt, ob Du nicht richtig geklickt oder die Maus mal wieder "hängt"

Ich habe jetzt mal den Speicher und CPU reduziert, mal sehen ob dies etwas bringt.
Der Wechsel von Workstation 16 auf 17 vor nicht allzulanger Zeit hat das Problem auf jeden Fall auch reduziert (oder Zufall?)

[Dayworker]

Würde das eigentlich eher als Zufall bezeichnen. Bisher wurde mit wenigen Ausnahmen jede neue WS-Version langsamer, weil immer entweder das Host-OS fetter oder/und dessen Logging noch umfangreicher wurde.
Die größte und inzwischen fast einzigste lösbare Bremse ist die Abschaltung der VMEM-Datei, damit das VMware-Desktopprodukt nicht ständig den vRAM-Inhalt zwischen VMEM-Datei und Auslagerungsspeicher (Windows: Auslagerungsdatei, Linux: SWAP) synchronisieren muß.

[frank@vmforum]

inzwischen fast einzigste lösbare Bremse ist die Abschaltung der VMEM-Datei

klingt nach einem guten Tipp, scheinbar kann ich es so abschalten, wenn ich richtig gesucht und gefunden habe
https://gist.github.com/extremecoders-re/cf8d829c108d58bfbb2e3c1f4121d7e1

Mit welchen Auswirkungen muß ich da rechnen? Irgendwelche negaiven Konsequenzen?

[frank@vmforum]

nach längerer Zeit muß ich das Thema doch nochmals aufgreifen, den gelöst ist es leider bisher nicht.
Im Gegenteil scheint es sich zu verschlimmern

Im Oktober 23 bin ich dem Vorschlag gefolgt und habe die VMEM-Datei abgeschaltet.
keine positive, aber auch keine negative Veränderung bemerkbar.

Leider ist es beim aktuellen Stand nicht dabei geblieben, daß die Eingaben über Tastatur oder Maus sehr zeitverzögert sind, sondern die GUI (vermutlich x-server) friert immer wieder komplett ein, d.h. keinerlei Maus-Aktion oder Tastatur-Eingabe sind noch möglich. Nur noch die Hotkey um aus der VM auszubrechen und zum Host zu wechseln ist möglich.
Die VM bzw. Debian selbst leben noch, über die Workstation-GUI kann die VM noch normal runtergefahren werden.

Folgende Dinge sind inzwischen aufgefallen, die hoffentlich eine Problemlösung näher bringen:

• es macht den Eindruck, daß das Problem häufig durch die Maus ausgelöst wird. Z.B. viel und schnell mit dem Mausrad scrollen, mehrere Dinge mit STRG+Maus-Taste anklicken
• wenn die Tastatur-Eingaben anfangen langsamer am Bildschirm sichtbar zu werden, dann am besten gleich die VM neu starten. Das Einfrieren der GUI ist sonst nur eine Frage kurzer Zeit.
• Reboot hilft immer, bis zum nächsten Auftreten
• wenn die GUI eingefroren und die VM runtergefahren wird, kommt zuletzt immer (?, zumindest häufig) die Fehlermeldung "psmouse failure" (oder so ähnlich). Nur kurz am Bildschirm, dann kommt der reboot.
• Das Problem ist nicht spezifisch für meine meist genutzte VM. Zwischenzeitlich habe ich eine VM komplett neu aufgebaut (Debian12). Nach wenigen Tagen war das Problem dort ebenfalls. Hier läuft von Anfang an open-vmtools.
• im Xorg.log sind mir einige Zeilen aufgefallen, die mir komisch vorkommen. Vielleicht weil ich sowieso die Maus u. Tastatur im Verdacht habe. Ist folgendes normal?

[ 5.632] (**) Power Button: always reports core events
[ 5.691] (**) VMware VMware Virtual USB Mouse: always reports core events
[ 5.860] (**) AT Translated Set 2 keyboard: always reports core events
[ 5.892] (**) VirtualPS/2 VMware VMMouse: always reports core events
[ 5.946] (**) VirtualPS/2 VMware VMMouse: always reports core events

oder

[ 5.892] (**) VirtualPS/2 VMware VMMouse: Applying InputClass "libinput pointer catchall"
[ 5.892] (II) Using input driver 'libinput' for 'VirtualPS/2 VMware VMMouse'
[ 5.892] (**) VirtualPS/2 VMware VMMouse: always reports core events
[ 5.895] (II) event3 - VirtualPS/2 VMware VMMouse: is tagged by udev as: Mouse
[ 5.896] (II) event3 - VirtualPS/2 VMware VMMouse: device is a pointer
[ 5.897] (II) event3 - VirtualPS/2 VMware VMMouse: device removed
[ 5.936] (II) XINPUT: Adding extended input device "VirtualPS/2 VMware VMMouse" (type: MOUSE, id 9)
[ 5.937] (**) VirtualPS/2 VMware VMMouse: (accel) selected scheme none/0
[ 5.937] (**) VirtualPS/2 VMware VMMouse: (accel) acceleration factor: 2.000
[ 5.937] (**) VirtualPS/2 VMware VMMouse: (accel) acceleration threshold: 4
[ 5.940] (II) event3 - VirtualPS/2 VMware VMMouse: is tagged by udev as: Mouse
[ 5.941] (II) event3 - VirtualPS/2 VMware VMMouse: device is a pointer
[ 5.943] (II) config/udev: Adding input device VirtualPS/2 VMware VMMouse (/dev/input/mouse1)
[ 5.945] (II) config/udev: Adding input device VirtualPS/2 VMware VMMouse (/dev/input/event2)
[ 5.946] (**) VirtualPS/2 VMware VMMouse: Applying InputClass "libinput pointer catchall"

komplettes Log:

Xorg.log.gz

(4.93 KiB) 57-mal heruntergeladen

[frank@vmforum]

mein Problem muß ein Bug in VMware sein.
Ich habe nun die VM nach QEMU umgezogen, indem ich meine VMDK dort importiert habe (genauer konvertiert).
Anschließend noch die open-vmtools in der VM deinstalliert.

Das Problem ist weg.
Es kann also weder an Debian in der VM, noch am Debian auf dem Host gelegen haben.

[Dayworker]

Der Fehler dürfte durch den Xorg-Server produziert sein. Den bietet eigentlich kaum noch eine Distribution an, seitdem Wayland funktional ist. Hier zeigt sich einmal mehr, daß man immer die vom jeweiligen Gast-OS angebotenen Wege des Remote-Zugriffs und die VMware-Anwendung nur für rein Administrative Zwecke nutzen sollte.