16
Virtuelle Maschinen starten mit einer Verzögerung von mehreren Stunden
Hallo!
Wir haben ein Problem, welches wir bisher nicht lösen konnten. Zunächst aber die Eckdaten des Servers:
Wir haben auf diesem Server 9 virtuelle Maschinen: 2x Linux und 7x Windows Server 2016.
Problembeschreibung:
Nach einem Neustart des Serverrechners, starten die einzelnen virtuellen Maschinen mit einer mehrstündigen Verzögerung. Während dieser Zeit zeigt der Hyper-V-Manager lediglich in der Spalte Status „Wird gestartet...“. Die Anzeige in der Spalte Phase bleibt währenddessen auf „Aus“.
Nachdem nach Stunden die virtuellen Maschinen laufen, können diese wie gewohnt schnell und problemlos neu gestartet werden. Also es handelt sich definitiv um den ersten Start einer virtuellen Maschine nach einem Neustart des Host-Rechners.
Während der Wartezeit konnten wir im Ressourcenmonitor keine Datenträgeraktivitäten feststellen, die auf Hyper-V hinweisen könnten. Allerdings belastete „vmms.exe“ die CPUs mit konstant 3%, was uns als relativ hoch erscheint.
System-, Anwendungs- und Hyper-V-Protokolle zeigen keine Auffälligkeiten.
Zunächst lief alles wie gewohnt – schnell, stabil und ohne jegliche Probleme. Da wir sehr selten den Host neu starten, wissen wir nicht, seit wann das Problem besteht. Das erste Mal ist uns das Ende September 2019 (also vor mehr als einem Jahr) aufgefallen.
An der Startverzögerung kann es nicht liegen. Wir haben bereits alle Startverzögerungen komplett deaktiviert, die VMs alle heruntergefahren und den Server neu gestartet. Danach haben wir die Maschinen ohne Erfolg manuell gestartet – wir mussten wieder Stunden warten, bis diese gestartet wurden. Also dasselbe Verhalten.
Mehr Infos versuchen wir heute Abend zu liefern, denn auch zwischen den Jahren werden die Server gebraucht.
Kennt jemand dieses Verhalten und einen möglichen Lösungsansatz?
Im Voraus vielen Dank!
René
Wir haben ein Problem, welches wir bisher nicht lösen konnten. Zunächst aber die Eckdaten des Servers:
1 Intel Serverbarebone R2208WTTYSR
1 Intel Remote Management Module V4 Lite 2
2 CPU Intel XEON E5-2620v4/8x2.1 GHz/20MB
128 GB RAM
- 8x8GB: DDR4 REG 8GB/PC2400/ECC
- 4x16GB: DDR4 REG 16GB/PC2666/ECC (nachträglich eingebaut)
1 LG DVD±RW/±R Slim, SATA
2 SSD 2.5" 240GB Intel DC S3520 MLC, SATA3
RAID1, Systempartition, 100%
6 HD2.5" SAS3, 1.2TB, SGT ST1200MM0088/10k/512n
RAID5, Datenpartition, 100%
1 BC MegaRAID 9361-8i, PCIe x8, SAS 8 HDD sgl.
1 BC MegaRAID CV Modul 02 für 9361-4i/-8i
1 BC MegaRAID BBU-BRACKET-05 KIT
1 Windows Server 2016 Datacenter. 16CoreWir haben auf diesem Server 9 virtuelle Maschinen: 2x Linux und 7x Windows Server 2016.
Problembeschreibung:
Nach einem Neustart des Serverrechners, starten die einzelnen virtuellen Maschinen mit einer mehrstündigen Verzögerung. Während dieser Zeit zeigt der Hyper-V-Manager lediglich in der Spalte Status „Wird gestartet...“. Die Anzeige in der Spalte Phase bleibt währenddessen auf „Aus“.
Nachdem nach Stunden die virtuellen Maschinen laufen, können diese wie gewohnt schnell und problemlos neu gestartet werden. Also es handelt sich definitiv um den ersten Start einer virtuellen Maschine nach einem Neustart des Host-Rechners.
Während der Wartezeit konnten wir im Ressourcenmonitor keine Datenträgeraktivitäten feststellen, die auf Hyper-V hinweisen könnten. Allerdings belastete „vmms.exe“ die CPUs mit konstant 3%, was uns als relativ hoch erscheint.
System-, Anwendungs- und Hyper-V-Protokolle zeigen keine Auffälligkeiten.
Zunächst lief alles wie gewohnt – schnell, stabil und ohne jegliche Probleme. Da wir sehr selten den Host neu starten, wissen wir nicht, seit wann das Problem besteht. Das erste Mal ist uns das Ende September 2019 (also vor mehr als einem Jahr) aufgefallen.
An der Startverzögerung kann es nicht liegen. Wir haben bereits alle Startverzögerungen komplett deaktiviert, die VMs alle heruntergefahren und den Server neu gestartet. Danach haben wir die Maschinen ohne Erfolg manuell gestartet – wir mussten wieder Stunden warten, bis diese gestartet wurden. Also dasselbe Verhalten.
Mehr Infos versuchen wir heute Abend zu liefern, denn auch zwischen den Jahren werden die Server gebraucht.
Kennt jemand dieses Verhalten und einen möglichen Lösungsansatz?
Im Voraus vielen Dank!
René
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 636520
Url: https://administrator.de/contentid/636520
Printed on: April 18, 2024 at 05:04 o'clock
16 Comments
Latest comment
Hallo,
was zeigt der Gastbildschirm während der Zeit? Wird das OS überhaupt zeitnah angeschubst?
Gruß,
Jörg
was zeigt der Gastbildschirm während der Zeit? Wird das OS überhaupt zeitnah angeschubst?
Gruß,
Jörg
Der Gastbildschirm bleibt leer. Nicht einmal der "Hyper-V"-Schriftzug ist zu sehen. Es passiert einfach nichts.
Hallo,
Kopiere mal VHD Dateien bzw. Prüfe ob des da keine/n Problem/e gibt. Hat dein SAS Verbund Probleme? RAM ist OK?
Gruß,
Peter
Zitat von @temuco:
Nach einem Neustart des Serverrechners, starten die einzelnen virtuellen Maschinen mit einer mehrstündigen Verzögerung.
Sollen alle VMs zur gleichen Zeit Starten? Hintereinander?Nach einem Neustart des Serverrechners, starten die einzelnen virtuellen Maschinen mit einer mehrstündigen Verzögerung.
Kopiere mal VHD Dateien bzw. Prüfe ob des da keine/n Problem/e gibt. Hat dein SAS Verbund Probleme? RAM ist OK?
Gruß,
Peter
Eingestellt waren die VMs so, dass sie in einem Abstand von einigen Minuten hintereinander starten. Testhalber haben wir aber diese Startverzögerung deaktiviert inkl. dem automatischen Start, um eine einzelne Maschine manuell zu starten. Das Verhalten hat sich nicht geändert: Auch von Hand brauchte der Start ewig.
Der Server ist OK. Wir konnten keine sonstigen Fehler feststellen. Und wenn alle Maschinen laufen, funktioniert auch alles fehlerfrei. Wir können auch, nachdem die Maschinen endlich laufen, diese erneut starten – hier gibt es keine Warterei mehr.
Kopiere mal VHD Dateien bzw. Prüfe ob des da keine/n Problem/e gibt. Hat dein SAS Verbund Probleme? RAM ist OK?
Der Server ist OK. Wir konnten keine sonstigen Fehler feststellen. Und wenn alle Maschinen laufen, funktioniert auch alles fehlerfrei. Wir können auch, nachdem die Maschinen endlich laufen, diese erneut starten – hier gibt es keine Warterei mehr.
Hallo,
vCPUs uberbucht?
CPU defekz?>
Gruß,
Peter
Zitat von @temuco:
Eingestellt waren die VMs so, dass sie in einem Abstand von einigen Minuten hintereinander starten. Testhalber haben wir aber diese Startverzögerung deaktiviert inkl. dem automatischen Start, um eine einzelne Maschine manuell zu starten. Das Verhalten hat sich nicht geändert: Auch von Hand brauchte der Start ewig.
Und die Reihenfolge ändern?Eingestellt waren die VMs so, dass sie in einem Abstand von einigen Minuten hintereinander starten. Testhalber haben wir aber diese Startverzögerung deaktiviert inkl. dem automatischen Start, um eine einzelne Maschine manuell zu starten. Das Verhalten hat sich nicht geändert: Auch von Hand brauchte der Start ewig.
vCPUs uberbucht?
CPU defekz?>
Der Server ist OK. Wir konnten keine sonstigen Fehler feststellen. Und wenn alle Maschinen laufen, funktioniert auch alles fehlerfrei. Wir können auch, nachdem die Maschinen endlich laufen, diese erneut starten – hier gibt es keine Warterei mehr.
Entweder hast du Plattenfehler in einer/alle deiner VMs oder dein Host hat Plattenfehler oder sonstwas ist defekt wenn es nicht Konfigurationsprobleme sind. Prüfen und nicht vermuten.Gruß,
Peter
Hallo
unbedingt den Unterschied prüfen der VMs beim Neustart
- VM heruntergefahren
- VM Status gespeichert
und differenzierende Festplatte mit Fehler oder auf slow space ?
aber ich würde eine vm kopieren und auf einem anderen System anstarten um es zu vergleichen
nachsehen ob es 100derte snapshot Ketten gibt pro Datenträger weil das Backup beim VSS schlampt
VG
ulti
unbedingt den Unterschied prüfen der VMs beim Neustart
- VM heruntergefahren
- VM Status gespeichert
und differenzierende Festplatte mit Fehler oder auf slow space ?
aber ich würde eine vm kopieren und auf einem anderen System anstarten um es zu vergleichen
nachsehen ob es 100derte snapshot Ketten gibt pro Datenträger weil das Backup beim VSS schlampt
VG
ulti
Wie beschrieben: Auch wenn wir nach dem Serverneustart manuell einzelne VMs starten, haben wir das gleiche Verhalten.
vCPUs uberbucht?
Nein, das haben wir auch überprüft. Wir haben insgesamt 16 Kerne bzw. 32 logische – demnach sind die Ressourcen verteilt. Aber das passiert auch, wenn man nur die kleinste VM zum ersten Mal startet, während alle anderen heruntergefahren sind.
CPU defekz?
Es sind zwei (siehe Eingangsposting). Ausschließen kann ich das nicht, es fehlt mir aber schwer zu glauben, dass ein CPU-Fehler nur beim ersten Start von einer VM nach dem Rechnerneustart auftritt. Danach laufen Host und die 9 VMs Monate lang ohne Fehler und/oder Unterbrechungen. Wir werden aber auch das erneut überprüfen.
Entweder hast du Plattenfehler in einer/alle deiner VMs oder dein Host hat Plattenfehler oder sonstwas ist defekt wenn es nicht Konfigurationsprobleme sind. Prüfen und nicht vermuten.
Werden wir heute Abend nochmals einen Blick drauf werfen. Aber wie bereits beschrieben: Während des Wartens konnten wir bisher keine Datenträgeraktivitäten im Ressourcenmonitor feststellen, die auf Hyper-V hinweisen könnten.
Ich weiß nicht, ob es sich um Konfigurationsprobleme handelt. Keiner hat etwas umkonfiguriert, aber es könnte u. U. auch ein Windows-Update sein. Allerdings haben wir ausgiebig danach recherchiert, ohne etwas konkretes finden zu können.
Hallo,
dann würde ich als Nächstes gucken, ob alle Dienste auf dem Hyper-V Host zeitnah laufen / gestartet werden.
Vielleicht hält irgend etwas die Dateien offen? Ich habe durchaus schon Virenscanner auf Hyper-V Hosts gesehen und inzwischen würde ich den Dingern sogar zutrauen, stundenlang in den VHDX-Dateien herumzurühren (...und die Datei solange offenzuhalten).
Zusätzlich lohnt ein Blick in die Prozesse vom Hyper-V-Host.
Vielleicht könnte man den Server auch mal testweise ohne Netzwerk hochfahren? Vielleicht gibt es einen Konflikt mit MAC- oder IP-Adressen?
Nach aktuellem Kenntnisstand kann man halt nur raten...^^
Gruß,
Jörg
dann würde ich als Nächstes gucken, ob alle Dienste auf dem Hyper-V Host zeitnah laufen / gestartet werden.
Vielleicht hält irgend etwas die Dateien offen? Ich habe durchaus schon Virenscanner auf Hyper-V Hosts gesehen und inzwischen würde ich den Dingern sogar zutrauen, stundenlang in den VHDX-Dateien herumzurühren (...und die Datei solange offenzuhalten).
Zusätzlich lohnt ein Blick in die Prozesse vom Hyper-V-Host.
Vielleicht könnte man den Server auch mal testweise ohne Netzwerk hochfahren? Vielleicht gibt es einen Konflikt mit MAC- oder IP-Adressen?
Nach aktuellem Kenntnisstand kann man halt nur raten...^^
Gruß,
Jörg
Zitat von @ultiman:
unbedingt den Unterschied prüfen der VMs beim Neustart
- VM heruntergefahren
- VM Status gespeichert
unbedingt den Unterschied prüfen der VMs beim Neustart
- VM heruntergefahren
- VM Status gespeichert
Was meinst du mit "Unterschied"?
Auf jeden Fall werden die einzelnen Maschinen immer regulär heruntergefahren, wenn der Host neu gestartet wird.
und differenzierende Festplatte mit Fehler oder auf slow space ?
Wir verwenden VHDX mit fester Größe über den virtuellen IDE-Controller auf den beiden Linux-Maschinen. Alle anderen (Windows Server 2016) verwenden VHDX dynamisch erweiterbar über den virtuellen SCSI-Controller.
Das RAID-System hat noch 1TB frei.
aber ich würde eine vm kopieren und auf einem anderen System anstarten um es zu vergleichen
nachsehen ob es 100derte snapshot Ketten gibt pro Datenträger weil das Backup beim VSS schlampt
nachsehen ob es 100derte snapshot Ketten gibt pro Datenträger weil das Backup beim VSS schlampt
Schattenkopien sind auf dem Serverrechner deaktiviert. Auch Prüfpunkte für die einzelnen VMs sind deaktiviert. Gesichert wird mit "Veeam Backup & Replication". Hier muss ich aber meinen Kollegen konsultieren, weil er Veeam eingerichtet hat. Wenn ich mich richtig erinnere, es werden ständig Sicherungen auf einem Backup-Server erstellt, der als Repository fungiert und dieser steuert dann einen LTO-Wechsler mit 24 Bändern. Der Backup-Server ist über eine extra Netzwerkkarte mit dem Hyper-V-Host in einem anderen Netz verbunden. Aber mein Kollege kann vielleicht heute Abend mehr dazu sagen, wenn das für die Lösungsfindung wichtig ist.
Ja, man kann nur raten.
Mit der IP-Adresse gibt es keine Konflikte – das haben wir überprüft. Ob aber mit einer MAC-Adresse? Dann gehe ich gleich Lotto spielen!
Die Prozesse haben wir auch überprüft. Wir haben sogar diese mit einem anderen, ähnlichen System, welches bis auf die Hardware und die Anzahl VMs gleich konfiguriert ist, verglichen. Es laufen dieselben Prozesse und es wird dasselbe protokolliert. Wir konnten in der Hinsicht nichts Verdächtiges finden.
Das mit der offenen Datei müssen wir nochmals überprüfen, wobei ich mir das nicht vorstellen kann. Auf dem Server läuft lediglich der Windows Defender und bei ihm ist der Echtzeitschutz deaktiviert. Weißt du, ob er beim Rechnerstart etwas prüft, auch wenn der Echtzeitschutz deaktiviert ist?
Mit der IP-Adresse gibt es keine Konflikte – das haben wir überprüft. Ob aber mit einer MAC-Adresse? Dann gehe ich gleich Lotto spielen!
Die Prozesse haben wir auch überprüft. Wir haben sogar diese mit einem anderen, ähnlichen System, welches bis auf die Hardware und die Anzahl VMs gleich konfiguriert ist, verglichen. Es laufen dieselben Prozesse und es wird dasselbe protokolliert. Wir konnten in der Hinsicht nichts Verdächtiges finden.
Das mit der offenen Datei müssen wir nochmals überprüfen, wobei ich mir das nicht vorstellen kann. Auf dem Server läuft lediglich der Windows Defender und bei ihm ist der Echtzeitschutz deaktiviert. Weißt du, ob er beim Rechnerstart etwas prüft, auch wenn der Echtzeitschutz deaktiviert ist?
Hallo,
Naja, es gab da mal irgendwas von Sysinternals, womit man in offene Filehandles schauen kann. Sieht man auf dem Host denn gar nichts in der Zeit? Keine außergewöhnlichen Prozesse / Zugriffe / Auslastungen / Aktivitäten?
Wann starten die VMs denn? Immer nach Ablauf einer bestimmten Wartezeit (z.B. "3 Stunden")? Oder immer genau zu einem bestimmten Zeitpunkt?
Nö. Aber wenn es Windows Defender ist, schließe ich den eher als Ursache aus. So einen Schnitzer kriegt nicht mal Microsoft hin.
Gruß,
Jörg
Zitat von @temuco:
Das mit der offenen Datei müssen wir nochmals überprüfen, wobei ich mir das nicht vorstellen kann.
Das mit der offenen Datei müssen wir nochmals überprüfen, wobei ich mir das nicht vorstellen kann.
Naja, es gab da mal irgendwas von Sysinternals, womit man in offene Filehandles schauen kann. Sieht man auf dem Host denn gar nichts in der Zeit? Keine außergewöhnlichen Prozesse / Zugriffe / Auslastungen / Aktivitäten?
Wann starten die VMs denn? Immer nach Ablauf einer bestimmten Wartezeit (z.B. "3 Stunden")? Oder immer genau zu einem bestimmten Zeitpunkt?
Weißt du, ob er beim Rechnerstart etwas prüft, auch wenn der Echtzeitschutz deaktiviert ist?
Nö. Aber wenn es Windows Defender ist, schließe ich den eher als Ursache aus. So einen Schnitzer kriegt nicht mal Microsoft hin.
Gruß,
Jörg
Zitat von @117471:
Naja, es gab da mal irgendwas von Sysinternals, womit man in offene Filehandles schauen kann. Sieht man auf dem Host denn gar nichts in der Zeit? Keine außergewöhnlichen Prozesse / Zugriffe / Auslastungen / Aktivitäten?
Naja, es gab da mal irgendwas von Sysinternals, womit man in offene Filehandles schauen kann. Sieht man auf dem Host denn gar nichts in der Zeit? Keine außergewöhnlichen Prozesse / Zugriffe / Auslastungen / Aktivitäten?
Während der Wartezeit konnten wir im Ressourcenmonitor keine Datenträgeraktivitäten feststellen, die auf Hyper-V hinweisen könnten. Allerdings belastete „vmms.exe“ die CPUs mit konstant 3%, was uns als relativ hoch erscheint. Schließlich handelt es sich dabei um zwei Xeons mit jeweils 8 Kernen...
Guter Tipp, danke! Wir werden die offenen Filehandles nach dem Start überprüfen.
Wann starten die VMs denn? Immer nach Ablauf einer bestimmten Wartezeit (z.B. "3 Stunden")? Oder immer genau zu einem bestimmten Zeitpunkt?
Jetzt, im "fehlerhaften" Zustand, erst nach mehreren Stunden – das trifft auf jede VM. Also, es ist nicht so, dass wenn die erste endlich läuft, die anderen gleich losrennen. Laufen diese endlich, können sie beliebig und ohne Verzögerung neu gestartet werden – das Fehlverhalten tritt nicht mehr auf, solange der Host nicht neu gestartet wird.
Ob es genau drei Stunden sind, kann ich nicht genau sagen; es könnten auch "nur" 2,5 Stunden sein...
Weißt du, ob er beim Rechnerstart etwas prüft, auch wenn der Echtzeitschutz deaktiviert ist?
Nö. Aber wenn es Windows Defender ist, schließe ich den eher als Ursache aus. So einen Schnitzer kriegt nicht mal Microsoft hin.
Danke für den Lacher!
LG
René
1
Hallo René,
ich hatte ein solches Phänomen einmal auf einer Hyper-V 2016 Umgebung im Zusammenhang mit einer VM-Replikation über Veeam.
Hier sind bei jedem Replikationsdurchlauf sog. Reference Points in der Hyper-V Konfiguration angelegt worden, welche bei jedem VM-Start eingelesen werden mussten. Mit die Zeit waren das bei mir auch mehrere Tausend Stück, was zu diesen Startverzögerungen geführt hat.
Nach Beseitigung der Reference Points waren die Startverzögerungen auch beseitigt, seitdem läuft alles normal.
Nähere Infos dazu habe ich damals im Veeam Forum gefunden:
https://forums.veeam.com/microsoft-hyper-v-f25/guest-os-starting-up-is-v ...
Dort sind auch PowerShell-Skripte zum Auslesen der Anzahl der Reference Points zu finden.
Vielleicht hilft dir das ja weiter.
Viele Grüße & guten Rutsch
ich hatte ein solches Phänomen einmal auf einer Hyper-V 2016 Umgebung im Zusammenhang mit einer VM-Replikation über Veeam.
Hier sind bei jedem Replikationsdurchlauf sog. Reference Points in der Hyper-V Konfiguration angelegt worden, welche bei jedem VM-Start eingelesen werden mussten. Mit die Zeit waren das bei mir auch mehrere Tausend Stück, was zu diesen Startverzögerungen geführt hat.
Nach Beseitigung der Reference Points waren die Startverzögerungen auch beseitigt, seitdem läuft alles normal.
Nähere Infos dazu habe ich damals im Veeam Forum gefunden:
https://forums.veeam.com/microsoft-hyper-v-f25/guest-os-starting-up-is-v ...
Dort sind auch PowerShell-Skripte zum Auslesen der Anzahl der Reference Points zu finden.
Vielleicht hilft dir das ja weiter.
Viele Grüße & guten Rutsch
Vielen Dank! Ein guter Hinweis, denn wir verwenden Veeam. Wir werden danach schsuen und hier nochmals berichten.
LG und einen guten Rutsch!
René
LG und einen guten Rutsch!
René
Frohes Neues!
Welche Konfigurationsversion haben die betroffenen Maschinen? Älter als 5.0? Dann aktualisiere die mal (Rechte Maustaste auf Maschine -> Konfigurationsversion upgraden...) Vorher aber Backup machen.
Just my 2c,
ipzipzap
Welche Konfigurationsversion haben die betroffenen Maschinen? Älter als 5.0? Dann aktualisiere die mal (Rechte Maustaste auf Maschine -> Konfigurationsversion upgraden...) Vorher aber Backup machen.
Just my 2c,
ipzipzap
Hallo in die Runde und erstmal ein frohes neues Jahr.
Ich habe jetzt keine Lösung, aber einen Tip :
Ich hatte das Problem ähnlich, allerdings nicht für Stunden. Eher so für 30-45min.
Dabei ist aufgefallen, dass in der Spalte "Status" die Info "Wird zusammengeführt xx%" steht.
Es sah so aus, als ob Snapshots zusammengeführt wurden - was allerdings, wenn man es provoziert nicht annähernd so lange dauert.
Ich habe testweise automatische Snapshots deaktiviert und das Problem war weg.
Trotzdem etwas mulmig...
Grüße
Mike
Ich habe jetzt keine Lösung, aber einen Tip :
Ich hatte das Problem ähnlich, allerdings nicht für Stunden. Eher so für 30-45min.
Dabei ist aufgefallen, dass in der Spalte "Status" die Info "Wird zusammengeführt xx%" steht.
Es sah so aus, als ob Snapshots zusammengeführt wurden - was allerdings, wenn man es provoziert nicht annähernd so lange dauert.
Ich habe testweise automatische Snapshots deaktiviert und das Problem war weg.
Trotzdem etwas mulmig...
Grüße
Mike
