11
Seit Update KB4512508 sind die Win 10 VM extrem langsam bis nicht mehr ansprechbar
Moin.
Wir lassen auf einem 2012 R2 Hyper-V (neben einigen Server-VM) vier nahezu identische Win 10 VM laufen, bisher ohne jedes Problem.
Seit gestern jedoch sind drei VM so gut wie nicht mehr ansprechbar. Remote kommt man gar nicht mehr drauf, per Hyper-V-Manager dauert ein Einloggen an die 10 Minuten, danach bricht die Verbindung ab. Nicht einmal herunterfahren kann man die Maschinen noch. So konnte ich leider auch nicht nachschauen, was da passiert. Ich nahm aber an, es handelte sich um ein Update. Kurioserweise lag die Auslastung aller betroffenen VM bei exakt 12%.
Ich habe dann von zwei VM ein Backup wiederhergestellt und diese laufen auch zuerst einwandfrei. Doch sobald das Update eingespielt wurde, schlägt die Verbindung wieder fehl. "Lokal" (also per Manager) ist ein Login nach dem ersten Reboot noch möglich, per VPN kommt ein Timeout. Kurz darauf ist auch eine lokale Verbindung nicht mehr möglich, das Login bricht wieder nach 10 Minuten ab.
Die Auslastung liegt wieder bei 12%.
Ich habe einen ganzen Tag gewartet, aber es tritt keine Besserung ein. Ich habe das Update jetzt im WSUS verboten und probiere es noch einmal mit den Backups.
Hat Jemand ähnliche Erfahrungen gemacht?
Viele Grüße
Thomas
Wir lassen auf einem 2012 R2 Hyper-V (neben einigen Server-VM) vier nahezu identische Win 10 VM laufen, bisher ohne jedes Problem.
Seit gestern jedoch sind drei VM so gut wie nicht mehr ansprechbar. Remote kommt man gar nicht mehr drauf, per Hyper-V-Manager dauert ein Einloggen an die 10 Minuten, danach bricht die Verbindung ab. Nicht einmal herunterfahren kann man die Maschinen noch. So konnte ich leider auch nicht nachschauen, was da passiert. Ich nahm aber an, es handelte sich um ein Update. Kurioserweise lag die Auslastung aller betroffenen VM bei exakt 12%.
Ich habe dann von zwei VM ein Backup wiederhergestellt und diese laufen auch zuerst einwandfrei. Doch sobald das Update eingespielt wurde, schlägt die Verbindung wieder fehl. "Lokal" (also per Manager) ist ein Login nach dem ersten Reboot noch möglich, per VPN kommt ein Timeout. Kurz darauf ist auch eine lokale Verbindung nicht mehr möglich, das Login bricht wieder nach 10 Minuten ab.
Die Auslastung liegt wieder bei 12%.
Ich habe einen ganzen Tag gewartet, aber es tritt keine Besserung ein. Ich habe das Update jetzt im WSUS verboten und probiere es noch einmal mit den Backups.
Hat Jemand ähnliche Erfahrungen gemacht?
Viele Grüße
Thomas
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 485470
Url: https://administrator.de/contentid/485470
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
11 Kommentare
Neuester Kommentar
Moin,
kann es sein, das das Update einfach noch am laufen ist?
Ich solch ein Phänomen schon mit einem nicht sonderlich performanten Server 2016.
Die CPU Auslastung war dabei ebenfalls nicht viel höher und die Platte hat sich auch gelangweilt.
Gruß
Spirit
kann es sein, das das Update einfach noch am laufen ist?
Ich solch ein Phänomen schon mit einem nicht sonderlich performanten Server 2016.
Die CPU Auslastung war dabei ebenfalls nicht viel höher und die Platte hat sich auch gelangweilt.
Gruß
Spirit
Lies mal RDP auf Win10 1903 - XDDM vs. WDDM
Das ist dein Problem, jede Wette, denn VMs werden auch über den RDP-Bus bedient.
Somit: GPO setzen, Rechner neu starten, fertig. Oder jedesmal sauber abmelden.
Das ist dein Problem, jede Wette, denn VMs werden auch über den RDP-Bus bedient.
Somit: GPO setzen, Rechner neu starten, fertig. Oder jedesmal sauber abmelden.
Danke für den Hinweis.
Leider scheint das GPO keine Abhilfe zu bringen. Ich habe es auch danach noch erlebt, dass sich die VM aus unbekannten Gründen verabschiedet hat und dann hart per Manager ausgeschaltet und neu gestartet werden musste, um sie wieder zu erreichen.. Die Kollegen melden sich auch jedes Mal korrekt ab, das habe ich ihnen schon vor Monaten eingebläut.
Nunja, immerhin weiß ich jetzt, dass ich die VM "nur" hart neu starten muss, damit sie wieder arbeiten können. Die Ausfälle sind trotzdem sehr nervig, aber werden dann wohl maximal beim Schichtwechsel oder einem Absturz auftreten.
Viele Grüße
Thomas
Leider scheint das GPO keine Abhilfe zu bringen. Ich habe es auch danach noch erlebt, dass sich die VM aus unbekannten Gründen verabschiedet hat und dann hart per Manager ausgeschaltet und neu gestartet werden musste, um sie wieder zu erreichen.. Die Kollegen melden sich auch jedes Mal korrekt ab, das habe ich ihnen schon vor Monaten eingebläut.
Nunja, immerhin weiß ich jetzt, dass ich die VM "nur" hart neu starten muss, damit sie wieder arbeiten können. Die Ausfälle sind trotzdem sehr nervig, aber werden dann wohl maximal beim Schichtwechsel oder einem Absturz auftreten.
Viele Grüße
Thomas
Ich kann mir nicht vorstellen, dass es nicht daran liegt. Hast Du die VMs mal nach der GPO neu gestartet? Der RDP-Dienst muss neu gestartet werden, damit die GPo zieht.
Nochmal aufgerollt:
Lass mich raten: der Host hat 8 Kerne und die VM hat nur einen oder zwei Kerne?
Sollte das zutreffen, dann teste bitte auf einer VM im Fehlerzustand Folgendes:
-Zugriff von deinem PC aus per psexec oder Remote Powershell, dann per Befehl
auflisten der angemeldeten Nutzer, um zu sehen, ob tatsächlich alle abgemeldet sind.
-ebenso per remote shell mittels Befehl
den vermeintlichen Schuldigen abschießen und im Hyper-V-Management nachsehen, ob die Last runtergeht.
Nochmal aufgerollt:
Kurioserweise lag die Auslastung aller betroffenen VM bei exakt 12%.
Das bedeutet, dass aus Sicht des Hypervisor-Hosts 12% (1/8 der Kerne) für diese VM benutzt werden.Lass mich raten: der Host hat 8 Kerne und die VM hat nur einen oder zwei Kerne?
Sollte das zutreffen, dann teste bitte auf einer VM im Fehlerzustand Folgendes:
-Zugriff von deinem PC aus per psexec oder Remote Powershell, dann per Befehl
qwinsta -ebenso per remote shell mittels Befehl
TASKKILL /F /IM dwm.exe
1
Ich hatte einen kleinen Fehler gemacht. Kaum macht mans richtig, schon gehts. 
Der Tag ist gerettet.
Danke für die Hilfe.
Viele Grüße
Thomas
Der Tag ist gerettet.Danke für die Hilfe.
Viele Grüße
Thomas
Du konntest es mit der GPO heilen?
Wir hatten das gleiche Problem. Leider hat es nichts gebracht den WDDM Grafiktreiber über die GPO zu deaktivieren.
Erst wenn das Funktionsupdate KB4512508 deinstalliert ist, verhält sich auch die CPU wieder normal, nachdem die RDP Sessions getrennt wurden.
Habt ihr noch eine andere Lösung die funktioniert?
Erst wenn das Funktionsupdate KB4512508 deinstalliert ist, verhält sich auch die CPU wieder normal, nachdem die RDP Sessions getrennt wurden.
Habt ihr noch eine andere Lösung die funktioniert?
@staybb
Hast Du dwm.exe als Ursache ausmachen können?
Hast Du überprüft, ob die GPO angewenset wurde?
Hast Du danach den Remotedesktopdienst an der betroffenen Maschine neu gestartet?
Hast Du dwm.exe als Ursache ausmachen können?
Hast Du überprüft, ob die GPO angewenset wurde?
Hast Du danach den Remotedesktopdienst an der betroffenen Maschine neu gestartet?
Es hat doch funktioniert mit der WDDM GPO.
Ja, die war immer bei permanent 15% Auslastung pro getrennte Benutzer-Session
Es hat direkt funktioniert nach dem ich den WDDM Treiber deaktiviert habe ohne Systemneustart.
Ich musste mich einfach neu per RDP verbinden, dann war die Auslastung weg nach dem die Sitzung getrennt wurde.
Ja, die war immer bei permanent 15% Auslastung pro getrennte Benutzer-Session
Hast Du überprüft, ob die GPO angewenset wurde?
Hast Du danach den Remotedesktopdienst an der betroffenen Maschine neu gestartet?
Hast Du danach den Remotedesktopdienst an der betroffenen Maschine neu gestartet?
Es hat direkt funktioniert nach dem ich den WDDM Treiber deaktiviert habe ohne Systemneustart.
Ich musste mich einfach neu per RDP verbinden, dann war die Auslastung weg nach dem die Sitzung getrennt wurde.
Jepp, klappte bei allen VM. Die Auslastung geht zwar seltsamerweise immer noch hoch, aber man kann sich problemlos wieder verbinden.
Das ist auch meine Beobachtung. Also: Teilfix, der jedoch die Performance jeder VDI-Umgebung, wo Nutzer sich trennen, gnadenlos zerschießt.
