Win 11 VM nach migration von Win 10 lahm

A

antiager

Well-Known Member
Jan 15, 2020
206
12
58
64
61191 Rosbach vor der Höhe
Hallo Forum!

Das Thema gab es wohl schon öfter. Ein Win10 wird nach Win11 konvertiert und ist dann lahm.

Wie gesagt die Threads hier im Forum sowie die KI habe ich schon konsultiert. Nix hat geholfen.

Symptome die Win11 Gui reagiert zäh sowohl in Proxmox Konsole als auch mit Teamviewer.

Ein Backup in der VM mit DriveSnapshot auf ein Synology SMB-Share rödelt mit 7 MB vor sich hin.

Am virtio Netzwerktreiber habe ich schon geschraubt ebenso an den virtuellen HDs (die Laufen auf ZFS).

CPU steht im moment auf HOST.

Hat jemand von euch einen Tipp?

Danke für eure Hilfe!!
 
hi antiager,

probier mal VBS (Memory Integrity) in Win11 zu deaktivieren oder 'nested-virt' auf 'off' zu stellen in der CPU Konfiguration von der betroffenen VM.
 
Wenn mit dem Forum hier und der KI schon durch bist, dann geh mal deine installierten Programme und Treiber durch. Sieht man im Taskmanager mehr? Sind schon alle Updates im Windows 11 drin oder rödelt er daran?
 
Poste doch mal dein qm config <vmid>, sonst raten wir hier alle nur rum. Was mich stutzig macht: zähe GUI und lahmes SMB gleichzeitig riecht eher nach Host als nach Gast-Treiber. Was zeigt der IO-Delay im Node-Summary während DriveSnapshot rödelt, und was sagt zpool iostat -v 5 dabei? Wenn da schon der Pool ächzt, brauchst du am virtio gar nicht weiterschrauben.

Das mit VBS würd ich verifizieren statt umstellen und hoffen: msinfo32 im Gast, ganz unten steht "Virtualisierungsbasierte Sicherheit". Wenn da "Wird ausgeführt" steht, ist sie trotz Klick in der GUI noch aktiv, hängt dann meist an nem GPO/Reg-Key statt am Schalter.

Und nach nem In-Place-Upgrade lohnt ein Blick in den Gerätemanager, ob vioscsi und NetKVM noch die Versionen von vorher sind. Hatte ich schon, dass das Upgrade Treiber auf inbox zurückdreht und dann ist alles zäh. Ballooning aus? Und wieviel RAM hat der Host, beziehungsweise wieviel davon zieht die ARC gerade?
 
Der Mitigations-Verdacht lässt sich zum Glück messen, nicht raten: im Gast das PowerShell-Modul SpeculationControl installieren und Get-SpeculationControlSettings laufen lassen, auf dem Host lscpu und unten die Vulnerabilities-Zeilen anschauen. Welche CPU steckt denn überhaupt im Host? Bei was wirklich Altem ohne aktuelles Microcode landest du im Software-Fallback und das kostet dann quer über alles, nicht nur in einer VM.

Was ich bei dem Vorschlag von @fertig im Hinterkopf hätte: wenn der Wechsel auf x86-64-v2-AES tatsächlich was bringt, liegt das nicht an den Mitigations, sondern daran, dass dem Gast damit vmx fehlt und Windows VBS gar nicht erst hochziehen kann. Mit host sieht der Gast ja mehr Flags, spec-ctrl/ibpb inklusive. Probier es ruhig, aber vergleich danach nochmal den VBS-Status, sonst weißt du hinterher nicht welcher der beiden Effekte es war.
 
You must log in or register to reply here.
Top Bottom
Back