5
Hyper-V-Hosts frieren ein
Guten Morgen,
Vorweg die Beschreibung unserer Umgebung:
2x IBM X3650 M3 Server mit Windows 2012R2 als Hyper-V-Hosts in einem Failover-Cluster
1x IBM DS3524 Storage, angebunden per iSCSI
1x IBM X3550 4M als DC
Nachdem ich das Update KB4015553 auf die beiden Hyper-V-Hosts installiert hatte, sind diese alle 24 Stunden eingefroren.
Verlauf des Fehlers:
- Dienste auf den VMs wurden nicht mehr ausgeführt (z.B. Exchange)
- Keine Verbindung über RDP oder Hyper-V-Manager auf die VMs
- VMs reagierten aber auf Ping
- Vorhandene RDP-Session auf einem Host war für kurze Zeit noch aktiv, war aber kaum bedienbar (Befehle wurden nicht ausgeführt)
- Keine Verbindung über Remote-Session über das IMM
- Keine Bedienung über direkt angeschlossene Maus und Tastatur
- Nur ein Kaltstart über das IMM löste vorübergehend den fehlerhaften Zustand
- 24 Stunden später ging es wieder los....
Erst als ich das Update deinstallierte, trat der Fehler nicht mehr.
Hat Jemand ähnliche Erfahrungen gemacht und konnte das Problem "eleganter" lösen?
Gruß
Willi
Vorweg die Beschreibung unserer Umgebung:
2x IBM X3650 M3 Server mit Windows 2012R2 als Hyper-V-Hosts in einem Failover-Cluster
1x IBM DS3524 Storage, angebunden per iSCSI
1x IBM X3550 4M als DC
Nachdem ich das Update KB4015553 auf die beiden Hyper-V-Hosts installiert hatte, sind diese alle 24 Stunden eingefroren.
Verlauf des Fehlers:
- Dienste auf den VMs wurden nicht mehr ausgeführt (z.B. Exchange)
- Keine Verbindung über RDP oder Hyper-V-Manager auf die VMs
- VMs reagierten aber auf Ping
- Vorhandene RDP-Session auf einem Host war für kurze Zeit noch aktiv, war aber kaum bedienbar (Befehle wurden nicht ausgeführt)
- Keine Verbindung über Remote-Session über das IMM
- Keine Bedienung über direkt angeschlossene Maus und Tastatur
- Nur ein Kaltstart über das IMM löste vorübergehend den fehlerhaften Zustand
- 24 Stunden später ging es wieder los....
Erst als ich das Update deinstallierte, trat der Fehler nicht mehr.
Hat Jemand ähnliche Erfahrungen gemacht und konnte das Problem "eleganter" lösen?
Gruß
Willi
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: 337474
Url: https://administrator.de/contentid/337474
Ausgedruckt am: 25.11.2024 um 17:11 Uhr
5 Kommentare
Neuester Kommentar
Moin Willi,
hast Du Dir mal angesehen, was KB4015553 macht?
https://support.microsoft.com/de-at/help/4015553/windows-8-1-windows-ser ...
U.a. dies:
Behebung eines Problems, aufgrund dessen Hyper-V-Hosts abstürzen können, wenn inkrementelle Sicherungen mit aktivierter Change Block Tracking-Technologie (CBT) ausgeführt werden.
--> Läuft bei Dir eine entsprechende Sicherung, die einen Absturz verursachen könnte?
Das hier könnte auch zutreffen:
Behebung eines Problems, das zu Fehlern bei Sicherungen auf Hyper-V-Clustern mit aktivierten CSV-Volumen führte.
--> Auch hier ein Problem in Zusammenhang mit Datensicherung.
Welche Datensicherungssoftware verwendest Du? Ggf. auf den Hersteller mit Verweis auf die KB4015553 zugehen und nachfragen.
Gruß
hast Du Dir mal angesehen, was KB4015553 macht?
https://support.microsoft.com/de-at/help/4015553/windows-8-1-windows-ser ...
U.a. dies:
Behebung eines Problems, aufgrund dessen Hyper-V-Hosts abstürzen können, wenn inkrementelle Sicherungen mit aktivierter Change Block Tracking-Technologie (CBT) ausgeführt werden.
--> Läuft bei Dir eine entsprechende Sicherung, die einen Absturz verursachen könnte?
Das hier könnte auch zutreffen:
Behebung eines Problems, das zu Fehlern bei Sicherungen auf Hyper-V-Clustern mit aktivierten CSV-Volumen führte.
--> Auch hier ein Problem in Zusammenhang mit Datensicherung.
Welche Datensicherungssoftware verwendest Du? Ggf. auf den Hersteller mit Verweis auf die KB4015553 zugehen und nachfragen.
Gruß
Moin,
danke für die Antwort.
Wir verwenden Veeam Backup & Replication 9.5
Bei den Backup-Jobs ist CBT aktiviert.
Das Backup wird jeden Abend zur gleichen Zeit ausgeführt. Der Fehler tritt aber unabhängig von der Start oder Laufzeit des Backups auf. Es sind immer die 24 Stunden vom Reboot der Hosts entscheidend.
Ich werde deinen Rat umsetzen und bei Veeam anfragen.
danke für die Antwort.
Wir verwenden Veeam Backup & Replication 9.5
Bei den Backup-Jobs ist CBT aktiviert.
Das Backup wird jeden Abend zur gleichen Zeit ausgeführt. Der Fehler tritt aber unabhängig von der Start oder Laufzeit des Backups auf. Es sind immer die 24 Stunden vom Reboot der Hosts entscheidend.
Ich werde deinen Rat umsetzen und bei Veeam anfragen.
Moin,
konntest du den Fehler beheben ?
Ich habe gerade dass selbe Problem bei einem unserer Kunden (Hyper-V mit Windows Server 2016 & Veeam Backup & Replication 9.5).
Auch deine beschriebenen Symtome sind die selben, konnte dir der Veeam Support helfen ?
LG,
Chris
konntest du den Fehler beheben ?
Ich habe gerade dass selbe Problem bei einem unserer Kunden (Hyper-V mit Windows Server 2016 & Veeam Backup & Replication 9.5).
Auch deine beschriebenen Symtome sind die selben, konnte dir der Veeam Support helfen ?
LG,
Chris
Moin Chris,
ich musste das leider an einen Externen weiterreichen, da ich eine berufliche Auszeit bis September nehme.
Bis jetzt konnte er mir noch keine Lösung nennen, aber sobald ich was von ihm höre gebe ich bescheid.
Wir konnten beobachten, dass die Probleme bei den Updates KB4022726, KB4019215 und KB4015553 auftreten.
Gruß
Willi
ich musste das leider an einen Externen weiterreichen, da ich eine berufliche Auszeit bis September nehme.
Bis jetzt konnte er mir noch keine Lösung nennen, aber sobald ich was von ihm höre gebe ich bescheid.
Wir konnten beobachten, dass die Probleme bei den Updates KB4022726, KB4019215 und KB4015553 auftreten.
Gruß
Willi
Hi Willi,
sorry für die späte Rückmeldung, aber ich hatte ein paar Tage Urlaub und wollte ausnahmsweise mal entspannen
.
Aber ich konnte in meinem Fall das Problem lösen und kann mit Freuden berichten dass es kein Hardware-Defekt bei uns war sondern ein durch Microsoft verursachtes Problem. Aber nun einmal der Reihe nach.
Nachdem ich am vorletzten Wochenende einen Hardware-Defekt zu 90% ausschließen konnte (Mainboard & Netzteil getauscht), habe ich mich in der Folgewoche mit dem Veeam Support unterhalten.
Veeam war das Problem als solches bekannt bzw. die Symtome und man sagte mir dass das Problem durch diverse Windows Updates erzeugt wird (Leider haben Sie nicht alle Dokumentiert).
Eines dieser Updates hat wohl bewirkt dass das Betriebssystem mit fehlerhaften / im Wartezustand befindlichen iSCSI-Targets nicht zurecht kommt (In unserem Fall stand ein iSCSI-Target auf "Wird hergestellt"). Im besagten Fall hat Veeam versucht auf die verfügbaren bzw. auf die eingetragenen iSCSI-Targets zuzgreifen und jedes mal einen neuen RPC-Port benutzt.
Dadurch verbraucht das OS bzw. diverse andere Applikationen auch, nach und nach alle verfügbaren RPC Ports und gibt diese auch nicht wieder frei. Sobald nun alle RPC Ports verbraucht sind kommt es zu diesem unschönen Effekt dass das System "einfriert" und es nicht mehr remote Verwaltet werden kann.
Nach einem Neustart waren dann wieder genug RPC-Ports frei und das Spiel ging von neuem los.
Letztendlich habe ich das "fehlerhafte" iSCSI-Target über das entsprechende Snap-IN entfernt und seid dem läuft der Server (Uptime > 8 Tage :D )
Bei Bedarf kann ich auch einen Teil der E-Mail von Veeam posten, ich lasse es nun vorerst da ich mir nicht sicher bin ob ich damit gegen Forum-Regeln verstoße.
LG,
Chris
sorry für die späte Rückmeldung, aber ich hatte ein paar Tage Urlaub und wollte ausnahmsweise mal entspannen
.Aber ich konnte in meinem Fall das Problem lösen und kann mit Freuden berichten dass es kein Hardware-Defekt bei uns war sondern ein durch Microsoft verursachtes Problem. Aber nun einmal der Reihe nach.
Nachdem ich am vorletzten Wochenende einen Hardware-Defekt zu 90% ausschließen konnte (Mainboard & Netzteil getauscht), habe ich mich in der Folgewoche mit dem Veeam Support unterhalten.
Veeam war das Problem als solches bekannt bzw. die Symtome und man sagte mir dass das Problem durch diverse Windows Updates erzeugt wird (Leider haben Sie nicht alle Dokumentiert).
Eines dieser Updates hat wohl bewirkt dass das Betriebssystem mit fehlerhaften / im Wartezustand befindlichen iSCSI-Targets nicht zurecht kommt (In unserem Fall stand ein iSCSI-Target auf "Wird hergestellt"). Im besagten Fall hat Veeam versucht auf die verfügbaren bzw. auf die eingetragenen iSCSI-Targets zuzgreifen und jedes mal einen neuen RPC-Port benutzt.
Dadurch verbraucht das OS bzw. diverse andere Applikationen auch, nach und nach alle verfügbaren RPC Ports und gibt diese auch nicht wieder frei. Sobald nun alle RPC Ports verbraucht sind kommt es zu diesem unschönen Effekt dass das System "einfriert" und es nicht mehr remote Verwaltet werden kann.
Nach einem Neustart waren dann wieder genug RPC-Ports frei und das Spiel ging von neuem los.
Letztendlich habe ich das "fehlerhafte" iSCSI-Target über das entsprechende Snap-IN entfernt und seid dem läuft der Server (Uptime > 8 Tage :D )
Bei Bedarf kann ich auch einen Teil der E-Mail von Veeam posten, ich lasse es nun vorerst da ich mir nicht sicher bin ob ich damit gegen Forum-Regeln verstoße.
LG,
Chris
