[SOLVED] Lexware Premium unter Win11 läuft sehr langsam, keinen offensichtlichen Grund, neue Hardware

A

AWilan-IT

New Member
Proxmox Subscriber
Mar 24, 2026
4
5
3
Hallo miteinander,

ich habe Proxmox VE-Server für verschiedene Anwendungen am laufen, unter anderem für verschiedene Windows als VM. Bei der neuesten unterlief mir anfangs ein Fehler: Ich hatte die Festplatte als IDE statt SCSI eingehängt. Dies fiel mir nach der Installation aller benötigten Komponenten auf. Daraufhin hatte ich die virtuelle Platte ausgehängt, den Controller auf SCSIsingle gestellt, und die Platte mit SCSI wieder eingehängt. Die VM funktionierte danach genauso einwandfrei wie vorher, leider sind die Lags aber auch noch genau so vorhanden.

Aktuell überlege ich, die VM, die hier vorerst als einzige auf dem neuen Gerät liegt, mal auf eine andere Umgebung umzuziehen und zu sehen, ob die Probs da genauso auftauchen. Hat vielleicht jemand eine Idee woran es noch liegen könnte? Würde eine Sicherung und reinstallation auf neuer virtueller Hardware etwas bringen?

Lexware Premium hat einen Umzug von einer MySQL auf eine PostgreSQL durch.

Zur Lag-Definition: Wenn man eine Person mit Anwesenheitszeiten öffnet, so dauert das öffnen einer Person (durchschnittlich 20 Arbeitstage, vier Zeiten pro Tag) etwa 30 Sekunden, das Schließen aber dann gute 1,5 Minuten. Das sollte maximal in <10 Sekunden sein. Auch der integrierte Datenbankanbindungstest dauert etwa 20-30ms, <1ms wäre normal. Ist ja alles auf dem einen Rechner unter dem einen Betriebssystem. Also Server = Client...
Werde mich auch morgen (wieder mal) an Lexware wenden, vielleicht haben die noch ein paar Ansätze übrig, die bisherigen waren nicht erfolgreich.

Ich freue mich über Ideen.

Bei der Hardware handelt es sich um einen nagelneuen DELL ProMaxTower T2 mit 32GB RAM und M2.SSD, Firmware ist die aktuellste installiert.

Vielen Dank im Voraus,

Besten Gruß, Anton
 
CPU type auf Host gesetzt? Überprüfe in der VM mal (Powershell):

systeminfo | findstr /i "hyper-v"

Falls sowas ausgegeben wird:

„A hypervisor has been detected“

solltest Du die CPU auf x86-64-v3 ändern. Ansonsten läuft Virtualisierung in Virtualisierung.
 
  • Like
Reactions: Browbeat, GMBauer, ThoSo and 1 other person
Ist erledigt, vielen Dank für die Info.
Kann man irgendwo nachlesen wofür x86-64-v3 und x86-64-v4 genau gut sind? Hab ein bisschen gestöbert und herausgefunden, dass bei Windows-Installationen wohl die v3 aktuell die bessere Wahl ist, aber mich interessiert, warum.
 
cwt said:
solltest Du die CPU auf x86-64-v3 ändern. Ansonsten läuft Virtualisierung in Virtualisierung.
Click to expand...
Wenn nach Umstellung des CPU-Typs der Windows 11 VM auf x86-64-v3 immer noch einer Hypervisor erkannt wird, was dann?
 
AWilan-IT said:
Kann man irgendwo nachlesen wofür x86-64-v3 und x86-64-v4 genau gut sind? Hab ein bisschen gestöbert und herausgefunden, dass bei Windows-Installationen wohl die v3 aktuell die bessere Wahl ist, aber mich interessiert, warum.
Click to expand...
Wie ausführlich mit wieviel Halbwissen darf es sein? ;)
Ich versuche mal an einen auf Halbwissen (also bitte mit Google/Doku gegenprüfen, hoffentlich korrigiert mich hier jemand, wenn ich einen zu großen Bock schieße...).

Grundsätzlich ist es ja so, dass neuere Prozessoren oft auch bestimmte Features enthalten, die in älteren Exemplaren nicht verfügbar sind, etwa in Hardwareunterstützung für bestimmte Verschlüsselungs- oder Komprimierungsverfahren, für die passende Instruktionen auf Prozessorebene mitgeliefert sind ( Disclaimer: So mein Verständnis, das beruht aber bestenfalls auf Halbwissen).

Wenn man in qemu (das ist die eigenliche Virtualisierungssoftware, auf der ProxmoxVE aufsetzt) eine neue VM aufsetzt, kann man dort nun eines der von qemu unterstützten Typen auswählen (welche es gibt und weitere Erklärungen auf Englisch unter https://manpages.debian.org/trixie/qemu-system-common/qemu-cpu-models.7.en.html). Im Normalfall will man da genau die CPU nehmen, die auch im Host verbaut ist, das gibt nämlich am meisten Performance ;) Genau das macht "host", es reicht alles direkt an die CPU weiter.
Darum steht das auch als Empfehlung in den best practices für Windows Gäste.
Blöderweise kann es aber Situationen geben, wo das zu Problemen führt. Ein Beispiel dafür wäre ein Cluster mit verschiedenen CPU-Modellen, da kann es dann passieren dass die eine CPU Unterstützung für bestimmte Instruktionen anbietet, die eine andere nicht hat. Wenn man nun zwischen den Hosts mit verschiedenen CPU-Modellen Vms migriert führt das zu Problemen, da die CPU am "neuen Standort" eben nicht die ist, mit der die VM mal gestartet wurde:
The hosts have CPUs from the same vendor with similar capabilities. Different vendor might work depending on the actual models and VMs CPU type configured, but it cannot be guaranteed - so please test before deploying such a setup in production.
https://pve.proxmox.com/pve-docs/pve-admin-guide.html#qm_migration
Click to expand...
Darum kann man verschiedene CPU-Modelle als "kleinsten gemeinsamen Nenner" auswählen, die den Codenamen von Amd/Intel der entsprechenden CPU-Linie entsprechen. Falls man nun aber selbst Amd und Intel CPUs mischen möchte/muss oder diese Codenamen nicht bekannt sind, gibt es auch noch generische Modelle für die jeweilige Generation der x64-Prozessorarchitektur, die wiederum bestimmten Features bei den Instruktionen entsprechen:

Click to expand...

Als Zwischending gibt es noch x86-64-v2-AES, der entspricht x86_v2, hat aber noch zusätzliches Features für die Hardwareunterstützung von Verschlüsselungskram, wenn ich das mit meinen Halbwissen richtig verstanden habe.

Mit anderen Worten: In einen Cluster will man im Idealfall überall den gleichen Prozessor haben und dann host nehmen oder den kleinsten gemeinsamen Nenner, weil diese Variante jeweils die beste Performance gibt. Um diesen zu bestimmen gibt es als third-party (also nicht vom Proxmox Team entwickeltes) OpenSourceTool ProxCLMC ( https://github.com/credativ/ProxCLMC ), was einen dann erzählt, welcher CPU-Typ der kleinste gemeinsame Nenner im Cluster ist, auch wenn der "Cluster" nur aus einen Knoten besteht.

Ein anderes Problem (darüber bist du gestolpert) mit host ist eigentlich ein Problem von Intel oder Amd: In den letzten Jahren sind wiederholt Sicherheitslücken im Prozessor bekannt geworden (https://de.wikipedia.org/wiki/Spectre_(Sicherheitslücke), https://de.wikipedia.org/wiki/Meltdown_(Sicherheitslücke). Als Abhilfe dagegen werden auf modernen Betriebssystemen sogenannte Microcode-Mitigations für diese Schwachstellen beim Booten aktiviert, die direkt auf der Ebene des BIOS oder UEFI greifen ( https://www.thomas-krenn.com/de/wiki/Intel_Microcode ). Im Falle von ProxmoxVE werden die also beim Starten des Hypervisors aktiviert. . Gleichzeitig gibt es in den Betriebssystemen auch noch oft eigene Mitigations, falls man die entsprechenden Microcode-Updates von Intel oder Amd nicht verfügbar hat, die gehen aber deutlich auf Kosten der Performance. Und genau das passiert ,wenn man host für Windows-VMs auswählt, der CPU-Typ wird direkt an Windows durchgereicht und Windows aktiviert dann die Mitigations, was er bei den generischen Typen nicht macht. Eine andere Möglichkeit den gleichen Effekt zu erzielen (der theoretisch auch eine bessere Performance bringen würde) wäre statt dessen host auszuwählen und bei den CPU-Flags "nested virtualization" zu deaktivieren, auch dann werden die Mitigations von Windows nicht ausgeführt. Man will also auch hier beim CPU-Typ den Typ auswählen, der der Realität am nächsten kommt, bzw. das entsprechende generische Modell. Praktischerweise kann man dafür auch ProxCLMC nehmen, selbst wenn der "Cluster" nur aus einen Knoten besteht.

Alle Klarheiten beseitigt?

Wo ich mir selbst gerade nicht sicher bin, wie das mit den Mitigations genau funktioniert. Ich habe es so verstanden, dass bei der Auswahl von einen der generischen Typen (bzw. deaktivierten nested virt) Windows bemerkt, dass es in einer VM läuft und sich darum auf die Mitigations des Betriebssystems des Hypervisors verlassen kann. Aber vielleicht habe ich da auch was durcheinander gebracht. Kann das bitte jemand anders bestätigen oder korrigieren? Gilt auch für den Rest dieses Postings, das ist aus sehr viel Halbwissen gespeist.
 
  • Like
Reactions: AWilan-IT and Browbeat
@Browbeat Dass systeminfo nen Hypervisor erkennt ist unter KVM normal, das wird immer angezeigt solang die VM unter nem Hypervisor läuft. Das ist aber nicht das Problem. Wichtig ist, dass Windows nicht seinen eigenen Hypervisor (Hyper-V/VBS) obendrauf startet. Check mal im Task-Manager unter Leistung → CPU ob da "Virtualisierung" steht, und schau in den Windows-Features ob Hyper-V deaktiviert ist.
 
  • Like
Reactions: Browbeat and Johannes S
@boisbleu

mit CPU-Typ "x86-64-v3" --> Virtualiserungsbasierte Sicherheit --> Nicht aktiviert
mit CPU-Typ "Host" --> Virtualiserungsbasierte Sicherheit --> Nicht aktiviert

Hatte ja auch immer Host als CPU-Typ gemäß Best Pratice gewählt und mich jetzt nur gefragt ob x86-64-v3 allgemein die bessere Wahl bei Windows 11 - Server 2025 wäre, oder halt nur bei Performanceproblemen...
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back