24
Hyper-V-Host rebootet - einige wenige Gäste haben danach Ping-Zeiten von über 400ms!
Moin an alle Hyper-V Admins!
Hat jemand außer mir schon einmal Folgendes erlebt?
Hyper-V auf Server 2019. Server startet neu, Maschinen suspendieren und resumen - dies funktioniert seit ca. einem Jahr tadellos.
Letzten Monat jedoch waren direkt nach dem Neustart 2 VMs kaum noch ansprechbar.
Die Ursache war schnell gefunden: Ping-Zeiten von ca. 400 Millisekunden.
Lösung: VMs neu gestartet - Problem behoben.
Nun, einen Monat später, wieder den Hypervisor neu gestartet - dieses Mal ist es eine andere VM, aber mit den gleichen Symptomen. Lösung ebenso gleich.
Also: wir haben hier
Hatte jemand das schon mal?
Hat jemand außer mir schon einmal Folgendes erlebt?
Hyper-V auf Server 2019. Server startet neu, Maschinen suspendieren und resumen - dies funktioniert seit ca. einem Jahr tadellos.
Letzten Monat jedoch waren direkt nach dem Neustart 2 VMs kaum noch ansprechbar.
Die Ursache war schnell gefunden: Ping-Zeiten von ca. 400 Millisekunden.
Lösung: VMs neu gestartet - Problem behoben.
Nun, einen Monat später, wieder den Hypervisor neu gestartet - dieses Mal ist es eine andere VM, aber mit den gleichen Symptomen. Lösung ebenso gleich.
Also: wir haben hier
- einen Host, der keinerlei Ressourcenknappheit hat.
- verschiedene Gastsysteme (Server 2012 R2 und 2016), die währenddessen keine Ressourcenknappheit haben
- keinerlei Meldungen in den Eventlogs von VMs und Host
- keinerlei Veränderungen am Host
- eine NIC, die bei allen gleich ist, jedoch bereitet diese bei anderen VMs zur selben Zeit keine Probleme (Ping <1 ms)
Hatte jemand das schon mal?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 514103
Url: https://administrator.de/forum/hyper-v-host-rebootet-einige-wenige-gaeste-haben-danach-ping-zeiten-von-ueber-400ms-514103.html
Ausgedruckt am: 02.04.2025 um 23:04 Uhr
24 Kommentare
Neuester Kommentar
Hi,
was für apps laufen darauf und was heisst keine Ressourcenknappheit? (jeder definiert das anders)
was für apps laufen darauf und was heisst keine Ressourcenknappheit? (jeder definiert das anders)
Switch ist i.O?
Hi,
hast du in den VMs bei "Startup Action" ein "Startup-Delay" konfiguriert? Ich setze da immer je nach Maschine passende Delays, so das nicht alle gleichzeitg "Resumed" werden, das kann je nach Anzahl von VMs und Abhängigkeiten sonst schon mal Probleme bereiten.
c.
hast du in den VMs bei "Startup Action" ein "Startup-Delay" konfiguriert? Ich setze da immer je nach Maschine passende Delays, so das nicht alle gleichzeitg "Resumed" werden, das kann je nach Anzahl von VMs und Abhängigkeiten sonst schon mal Probleme bereiten.
c.
Moin.
@certifiedit.net
Ping-Zeiten haben nichts mit Apps zu tun. Ich verstehe den Gedankengang nicht. Es sind 1x Exchange, 1x WSUS und gestern 1 Domänencontroller.
Keine Ressourcenknappheit heißt völliges Idlen. Viel RAM, keine CPU-Last, keine IO.
@Stefan - die selbe NIC ist doch wie gesagt in diversen anderen VMs drin, welche zur selben Zeit 0 Probleme haben. Auch wird ein Reboot einer VM einen vermeintlich defekten Switch nicht beeindrucken.
@certifiedit.net
Ping-Zeiten haben nichts mit Apps zu tun. Ich verstehe den Gedankengang nicht. Es sind 1x Exchange, 1x WSUS und gestern 1 Domänencontroller.
Keine Ressourcenknappheit heißt völliges Idlen. Viel RAM, keine CPU-Last, keine IO.
@Stefan - die selbe NIC ist doch wie gesagt in diversen anderen VMs drin, welche zur selben Zeit 0 Probleme haben. Auch wird ein Reboot einer VM einen vermeintlich defekten Switch nicht beeindrucken.
@141815
Ein Startup-Delay wird nicht benutzt. Der Resume-Prozess ist sehr schnell abgeschlossen, da das Storage sehr performant ist. Ich sehe auch hier keinen Zusammenhang, da die Ping-Zeiten damit (aus meiner Sicht) nichts zu tun haben.
Ein Startup-Delay wird nicht benutzt. Der Resume-Prozess ist sehr schnell abgeschlossen, da das Storage sehr performant ist. Ich sehe auch hier keinen Zusammenhang, da die Ping-Zeiten damit (aus meiner Sicht) nichts zu tun haben.
Zitat von @DerWoWusste:
Ich sehe auch hier keinen Zusammenhang, da die Ping-Zeiten damit (aus meiner Sicht) nichts zu tun haben.
Versuch macht kluch, bei Hyper-V wundert mich ehrlich gesagt nichts mehr.Ich sehe auch hier keinen Zusammenhang, da die Ping-Zeiten damit (aus meiner Sicht) nichts zu tun haben.
Moin @dww,
das mit dem Delay würde ich mir auch ansehen. Dein Problem kenne ich so nicht, hatte aber unter 2012R2 folgendes:
Starteten 2 bestimmte VM's zur selben Zeit, dauerte der Resume, immer mal wieder, viele Minuten. Ein Delay von gerade einmal 3 Sekunden eingetragen und das Problem ist nicht wieder aufgetreten.
Gruß
das mit dem Delay würde ich mir auch ansehen. Dein Problem kenne ich so nicht, hatte aber unter 2012R2 folgendes:
Starteten 2 bestimmte VM's zur selben Zeit, dauerte der Resume, immer mal wieder, viele Minuten. Ein Delay von gerade einmal 3 Sekunden eingetragen und das Problem ist nicht wieder aufgetreten.
Gruß
Was deutet auf denn auf Probleme mit dem Delay (von 0) hin?
Ich probier das ja gerne, würde aber eher Dinge testen, die etwas mit der virtuellen NIC / dem virtuellen Switch, der ja offenbar zickt zu tun haben.
Ich probier das ja gerne, würde aber eher Dinge testen, die etwas mit der virtuellen NIC / dem virtuellen Switch, der ja offenbar zickt zu tun haben.
Zitat von @DerWoWusste:
Was deutet auf denn auf Probleme mit dem Delay (von 0) hin?
Ich probier das ja gerne, würde aber eher Dinge testen, die etwas mit der virtuellen NIC / dem virtuellen Switch, der ja offenbar zickt zu tun haben.
Naja wenn mir schon zwei Leute den selben Hinweis geben dann würde ich dem zumindest schon mal Bedeutung schenken. Was da intern im Switch und oder den Treibern schief läuft weiß wohl nur MS oder ein Spezi mit WinDBG und ist vermutlich einer Race-Condition geschuldet, z.B. Aufruf einer Treiberfunktion die in der VM zu einem Loop führt oder einen Bufferoverflow erzeugt oder ähnliches, möglich ist vieles.Was deutet auf denn auf Probleme mit dem Delay (von 0) hin?
Ich probier das ja gerne, würde aber eher Dinge testen, die etwas mit der virtuellen NIC / dem virtuellen Switch, der ja offenbar zickt zu tun haben.
Hi @DerWoWusste
hast du mal am Hardwareswitch geschaut um zu dem Zeitpunkt irgendwelche Events z.B. STP auftauchen? Wir hatten das, allerdings mit VMWare 5.5, das die Switche sich z.T. schwer damit getan haben eine passende Verbindung aufzubauen.
Dann stellt sich die Frage, ist das Latenzproblem nur wenn du von deinem Rechner pingst/RDP machst oder auch zwischen den VMs auf dem gleichen Hyper-V Host (also auf ein und der selben Maschine)?
Gruß
@clSchak
hast du mal am Hardwareswitch geschaut um zu dem Zeitpunkt irgendwelche Events z.B. STP auftauchen? Wir hatten das, allerdings mit VMWare 5.5, das die Switche sich z.T. schwer damit getan haben eine passende Verbindung aufzubauen.
Dann stellt sich die Frage, ist das Latenzproblem nur wenn du von deinem Rechner pingst/RDP machst oder auch zwischen den VMs auf dem gleichen Hyper-V Host (also auf ein und der selben Maschine)?
Gruß
@clSchak
Naja wenn mir schon zwei Leute den selben Hinweis geben dann würde ich dem zumindest schon mal Bedeutung schenken
Du, das mach ich doch auch und teste es gerne, nur wüsste ich gern, wieso Ihr darauf kommt. Ich teste auch gerne, den Neustart ab jetzt nicht zwischen 3 und 4 Uhr zu machen, sondern zwischen 4 und 5, weil es hier schon 2 Leute so machen und keine Probleme haben, aber dennoch wüsste ich gerne, wo Ihr da einen Zusammenhang seht, wenn es schon nicht aus eigener Erfahrung zu stammen scheint.@clSchak:
Keine Auffälligkeiten am Switch. Latenzprobleme von überall zu diesen VMs in diesem Zustand - auch von VMs am selben virtuellen Switch.
ich kann es dir nicht sagen. Mein Gefühl sagt mir, dass es Probleme gibt, wenn zu selben Zeit 2 virtuelle Netzwerkkarten aktiviert werden.
Ich hatte den Hinweis damals auch nach Stundenlangem googlen gefunden. Da das funktioniert hat und gerade mal 3 Sekunden kostet, habe ich das Problem nicht weiter verfolgt.
Ich hatte den Hinweis damals auch nach Stundenlangem googlen gefunden. Da das funktioniert hat und gerade mal 3 Sekunden kostet, habe ich das Problem nicht weiter verfolgt.
Ich hatte den Hinweis damals auch nach Stundenlangem googlen gefunden
Aber dein Problem war doch ein ganz anderes, oder hattest Du auch diese dauerhaft schlechten Pings nach dem Resume?
Servus. Warum Resume ?
Ich lasse 14VMs runterfahren und dann mit wenigen Sekunden Delay zueinander (5-10) wieder starten. Reboot hat Windowskisten noch nie geschadet.
Zeitmässig merke ich keinen Unterschied. Selbst ein Ex2016 hat seine 50GB DB 20 Sekunden nach Start wieder online.
Henere
Ich lasse 14VMs runterfahren und dann mit wenigen Sekunden Delay zueinander (5-10) wieder starten. Reboot hat Windowskisten noch nie geschadet.
Zeitmässig merke ich keinen Unterschied. Selbst ein Ex2016 hat seine 50GB DB 20 Sekunden nach Start wieder online.
Henere
Habe gerade eine kurze Testreihe beendet:
Hypervisor 4x neu gestartet, ohne dabei die Konfig zu ändern.
->eine einzige Maschine zeigte Pingzeiten, die über 1 ms waren, (etwa bei 50ms dies Mal), aber nur bei einem der 4 Durchläufe.
Einzige Erkenntnis: es war wieder die selbe NIC!
Sehr rätselhaft. Wenn es so selten auftritt, ist es auch schwer, eine Lösung zu finden.
Morgen kommen dann 4 Durchläufe mit der Konfigänderung.
Hypervisor 4x neu gestartet, ohne dabei die Konfig zu ändern.
->eine einzige Maschine zeigte Pingzeiten, die über 1 ms waren, (etwa bei 50ms dies Mal), aber nur bei einem der 4 Durchläufe.
Einzige Erkenntnis: es war wieder die selbe NIC!
Sehr rätselhaft. Wenn es so selten auftritt, ist es auch schwer, eine Lösung zu finden.
Morgen kommen dann 4 Durchläufe mit der Konfigänderung.
Moin,
ich hatte das tatsächlich nur mal mit einer Ubuntu Server VM, welche nach einem reboot ähnlich reagiert hat.
Da lag es tatsächlich am DNS. Die Maschine konnte ihren eigenen Hostname einige Zeit nicht auflösen.
Ein weitere Neustart hat das Thema behoben.
Dauerhaft hat es geholfen den Namen in der Hosts Datei einzutragen.
Aber wie gesagt, mit Windows VMs auf dem gleichen Hosts gab es keine Probleme.
Sind die MAC-Adressen fest eingetragen?
Gruß
Spirit
ich hatte das tatsächlich nur mal mit einer Ubuntu Server VM, welche nach einem reboot ähnlich reagiert hat.
Da lag es tatsächlich am DNS. Die Maschine konnte ihren eigenen Hostname einige Zeit nicht auflösen.
Ein weitere Neustart hat das Thema behoben.
Dauerhaft hat es geholfen den Namen in der Hosts Datei einzutragen.
Aber wie gesagt, mit Windows VMs auf dem gleichen Hosts gab es keine Probleme.
Sind die MAC-Adressen fest eingetragen?
Gruß
Spirit
Sind die MAC-Adressen fest eingetragen?
Gruß
Spirit
Switched Hyper-V MAC-Adressen bei Reboot? Das wäre ja ein absolutes No-Go, denke eher nicht das Hyper-V so etwas macht.
Zitat von @clSchak:
Sind die MAC-Adressen fest eingetragen?
Gruß
Spirit
Switched Hyper-V MAC-Adressen bei Reboot? Das wäre ja ein absolutes No-Go, denke eher nicht das Hyper-V so etwas macht.
Sind die MAC-Adressen fest eingetragen?
Gruß
Spirit
Switched Hyper-V MAC-Adressen bei Reboot? Das wäre ja ein absolutes No-Go, denke eher nicht das Hyper-V so etwas macht.
Ich habe das Verhalten mit der Dynamischen MAC Zuweisung noch nicht ganz verstanden.
Ein Wechsel ist aber durchaus möglich wie ich festgestellt habe.
So, Testreihe 2 beendet.
Resultat ernüchternd. Auch wenn alle VMs einzeln starten, kommt es dennoch gelegentlich (wieder bei 1 von 4 Hypervisor-Reboots) zu diesem Effekt.
Tja. hoffen auf den nächsten Patch (so eben installiert). Bis dahin Workaround: Pingzeiten monitoren und VM ggf. neu starten.
Resultat ernüchternd. Auch wenn alle VMs einzeln starten, kommt es dennoch gelegentlich (wieder bei 1 von 4 Hypervisor-Reboots) zu diesem Effekt.
Tja. hoffen auf den nächsten Patch (so eben installiert). Bis dahin Workaround: Pingzeiten monitoren und VM ggf. neu starten.
Macht es einen Unterschied ob Du die VM resumest oder neustartest ?
Nicht getestet bislang. Ich werde nach und nach diverse Dinge testen.
Habe tüchtig weiter getestet und es bleibt bizarr. Ich hatte zuletzt nur noch die Treiber der Netzwerkkarten aktualisiert - keine Änderung, etwa jeder 4 Reboot haut meist eine, manchmal sogar 2 Maschinen ping-technisch total aus dem Tritt.
Aber nun kommt's:
-pingt der Host selbst die Maschine an, ist der Ping bei <1ms und sofort wird auch der Ping von allen anderen Maschinen im Netz zu dieser VM hin schnell! Bitte, was für ein Bug ist das denn?
-auch getestet wurde im Fehlerfall einfach die virtuelle NIC einmal disconnecten und re-connecten - sofort läuft der Ping schnell.
Da ich auf weitere Tests langsam keinen Bock mehr habe, wird nun einfach Folgendes umgesetzt:
Der Host bekommt per Task den Auftrag, nach dem Start aller Maschinen einen Ping an alle abzusetzen und fertig.
Aber nun kommt's:
-pingt der Host selbst die Maschine an, ist der Ping bei <1ms und sofort wird auch der Ping von allen anderen Maschinen im Netz zu dieser VM hin schnell! Bitte, was für ein Bug ist das denn?
-auch getestet wurde im Fehlerfall einfach die virtuelle NIC einmal disconnecten und re-connecten - sofort läuft der Ping schnell.
Da ich auf weitere Tests langsam keinen Bock mehr habe, wird nun einfach Folgendes umgesetzt:
Der Host bekommt per Task den Auftrag, nach dem Start aller Maschinen einen Ping an alle abzusetzen und fertig.
sieht nach einer "Pathfinding Problematik" aus? Möglich, dass du dich verroutet hast?
Verroutet? Es werden keine Routen benutzt.
