Hyper-V: VMs und Host hängen sich auf; kein Netzwerkping außerhalb der eigenen VM

WindowsNervendes Problem, welches die Woche von einem Blog-Leser an mich heran getragen wurde – ich stelle es hier mal ein, um das Schwarmwissen der Leserschaft anzuzapfen. Ein Leser kämpft seit November 2022 damit, dass seine Hyper-V-Lösung massive Probleme bereitet. Sowohl die virtuellen Maschinen mit dem Gast-Betriebssystem als auch der Host hängen sich auf. Dann ist kein Netzwerkping außerhalb der eigenen VM mehr möglich, schreibt der Nutzer.


Anzeige

Ein Hilferuf aus der Leserschaft

Blog-Leser Mike hat sich die Woche per Mail gemeldet und auf meine Nachfragen dann noch einige ergänzenden Informationen geliefert. Ich stelle es einfach mal hier ein, was er mir schrieb.

Hallo Herr Born,

ich schreibe sehr ungern eine E-Mail um Ihnen ihre kostbare Zeit zu rauben, aber dieses Serverproblem ist das schlimmste in meiner lebenslangen PC Laufbahn.

Ich kämpfe seit ca. Okt.-Nov/22 mit einem gravierenden Problem (bis heute). Selbst der Microsoft Support ist seit 11/22 bis heute aktiv und ratlos mit mehreren Teams.

Fujitsu (HW) Support scheint ebenso bemüht, aber dennoch recht ratlos. Da der Server bzw. einzelne VMs von mir fast jeden Tag, teils mehrfach neugestartet werden müssen, gehe ich langsam aber sicher auf dem Zahnfleisch.

Vielleicht haben Sie hier eine Idee?

Eine Idee habe ich nicht, mir ging nur "nicht unterstützte Hardware" durch den Kopf und ich hatte Mike auf den Artikel Why is Hyper-V freezing my host's networking when I run Server 2016 for a while? verwiesen. Trifft es aber vermutlich nicht genau.

Mehr Details zum Problem

Ich hatte Mike nach Details zum Host (Modell, ein oder mehrere Hosts betroffen, Patchstand, BIOS-Stand, Betriebssystem) gefragt. Dazu schrieb mir Mike folgendes:

Es ist ein Host von Fujitsu. Typ Primergy, Dual CPU, Patchstand ist aktuell – Genaue Versionsnummern müsste ich raussuchen, aber ob die Zahl interessant ist? Updates erfolgen über BMC+Agentless Services mehr oder weniger automatisch.

OS Windows Server 2016

Mehrere VMs darauf, alle gleiches OS.

Zusätzlich habe ich noch eine NVM/Treiber von Intel eingespielt, die neuer ist, als die letzte offizielle Herstellerfreigabe.

Das scheint zwar grundsätzlich förderlich, aber ob dies die Lösung ist, ist fraglich.

Zwischenzeitlich gab es vom BMC auch mal die Fehlermeldung bezüglich der 2. CPU. Dies kann an der CPU liegen, oder daran, dass sie die PCIe Slots der NIC kontrolliert.

Es gibt viele Artikel über SR-IOV etc. Aber auch ohne SR-IOV ohne VMQ, ohne RSS Switch, ohne Offloading scheint es Probleme zu geben.

Aktiviert man die CPU-Kompatibilität in Hyper-V scheint es auch leicht länger zu klappen.

Mike schloss mit dem Satz "Aber das sind alles so vage Aussagen, das ist einfach schrecklich zu beschreiben".

Was alles probiert wurde

In seiner ersten Mail hatte Mike noch skizziert, was die in seiner Umgebung bereits versucht und getestet haben. Hier der entsprechende Abriss zur Information.

Wir haben schon fast alle Varianten durch.. anfänglich vermutete ich Probleme mit lsass/netlogon/kerberos durch das Update.

Diese könnten zwischenzeitlich schon durch neue Patchdays behoben worden sein, denn anfangs war das Problem auf vmDC1 (PDC) begrenzt. Diese VM "hing" immer wieder. Login war erst nach luafv Deaktivierung (auch lokal) möglich.

Ansonsten ging weder bei Exchange noch sonst einem Server (mangels DC) irgendwas bezüglich Authentifikation. Microsoft lies mich dann sehr viele und teils fragwürdige Dinge ausprobieren. Letztendlich dachte  ich, durch die Patchdays sei das Problem gelöst.

Jetzt hängen sich gelegentlich einzelne VMs derart auf, dass sie sich nur noch selbst anpingen können, jedoch nicht mehr raus oder rein (außerhalb der eigenen VM).

Dazu hängt Host-seitig öfters mal die Aufzählung (Enumeration) der Hyper-Vs sowohl in der GUI, als auch PS-Shutdown klappt nicht mehr. PS-Direct kommt auch nur bis zum login.

Selbst Veeam auf dem Host (egal ob v11 oder v12, egal ob MSSQL Express oder Postgres), hängt dann oft, weil die vms/vmss nicht mehr reagiert.

Nach einem Neustart der VM ist meistens für eine kurze Weile Ruhe, am besten hilft ein Neustart des Hosts. Meist jedoch nicht länger als ca. 12 stunden oder einen Tag.

Was Mike sonst noch an Maßnahmen probiert hat, beschreibt er wie folgt:

  • NIC wurde schon getauscht, div, aktuelle und alte Treiber und NVMs etc. durchprobiert, alles mit Fujitsu Freigabe/Vorschlag.
  • Schiebe ich die VMs auf die Onboard LOM (LAN onboard) tritt das Problem eher noch viel schneller auf.
  • SR-IOV hatte ich testweise deaktiviert, Offloading, VMQ, etc. Bios-Reset, Kondensatoren entladen, etc.

und schließt mit "Leider weiß absolut keiner woran es liegen könnte. Ich vermute evtl. noch einen CPU/Mainboarddefekt? Alternativ Treiber/FW/SW-Probleme." und fragt, ob ich vielleicht irgendeine Idee habe, wie man hier weiter vorgehen könnte? Eine Prüfung mit Dism und sfc etc. hat er auch erfolglos ausprobiert. Aktuell versucht er noch folgendes zu testen:

PCIe NIC X710-T4 Slot 8 (CPU2) -> Slot 6 (CPU1)

CPU2 disabled in Bios + LOM update aktualisiert

Von Microsoft kam noch der Vorschlag zum Export und Import der VM, was Mike aber noch skeptisch sieht – wird er wohl noch testen. Zudem will er noch den Intel NIC gegen QLOGIC tauschen. Sofern jemand aus der Leserschaft ggf. das Problem und eine Lösung kennt oder noch Vorschläge zur weiteren Diagnose hat, kann er ja einen Kommentar hinterlassen.


Anzeige


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Störung, Virtualisierung, Windows abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

86 Antworten zu Hyper-V: VMs und Host hängen sich auf; kein Netzwerkping außerhalb der eigenen VM

  1. Simon sagt:

    Ich würde mir einen Leihserver bestellen. Von AFB oder so. Und dort einen neuen hyper-v aufsetzen und dann die vms rüber schieben. Dann könnte man schon mal rausbekommen ob es an der Hardware liegt.

    • itchy sagt:

      Moin
      Hilft nun nicht weiter, i know, aber: Ein Server ist KEIN Server ;-)
      Sehe ich wie Simon. Reserve – Leihkiste, VMs rüberschaufeln, weitermachen.
      Defekten Host komplett überarbeiten, Kühlung /Temperaturen kontrollieren, Batterien tauschen, RAM test, Bios Updates, ME Updates, BMC Updates, Controller FW Updates usw usw. – Raid neu aufbauen, OS installieren 2012R2, 2019 oder 2022 (fav) aber – kein 2016. Nie wieder. ;-)
      Viel Erfolg!
      Gruss
      Itchy

      • Mike sagt:

        Mag sein, aber genau alles neu zu installieren sollte eben noch ein paar Jahre geschoben werden.
        2016 schon vor Supportende rauszuwerfen um dann alles mühevoll auf 2022 neu einzurichten ist fraglich.
        In ein paar Jahren kommt wieder ein Nachfolger..

  2. anon sagt:

    Hatte einen ähnlichen Fall. Dort lag es an dem Hyper-V-Switch. Nach einem Windows Update kommunizierte der vSwitch nur noch intern, bzw. nur noch mit der virtuellen Netzwerkkarte der VM. Ich habe den betreffenden vSwitch einmal entfernt und neu eingerichtet. Das hat das Problem (bis jetzt) behoben. Vielleicht hifts… Siehe auch hier:
    Hyper-V funktioniert nicht mehr nach Windows Update

    • Dat Bundesferkel sagt:

      Darauf tippe ich auch. Kommt auch bei Hyper-V 2019 vor. Da würfelt das OS manchmal die Indexe der Netzwerkkarten durcheinander, knallt einen internen Switch rein und legt die Bindungen auf diesen.

      Mein Vorschlag:
      – VMs sauber herunterfahren
      – virtuelle Netzwerkkarten der VMs entfernen
      – Netzwerktreiber der NIC am Server aktualisieren
      – am Server "netcfg /d" eingeben und neustarten (ohne vm)
      – vEthernet neu einrichten (extern), Bindungen an die reale NIC prüfen
      – nochmal neustarten, Konfiguration prüfen
      – VMs den neuen Switch zuweisen

      Ist ein MS Problem und hängt mit dem Default Switch Desaster aus Windows 10 zusammen, welches auch beim Server Pendant vorkommt.

      Bitte KEIN "Datacenter-Optimierungsscript" drüber laufen lassen!

      • Paul sagt:

        Netcfg /d
        Löscht wirklich alles was mit Netzwerk in der registry steht und setzt es auf default.
        Das kann unerwünschte Effekte auslösen.
        Am sonsten ein schöner Befehl zum Aufräumen.

        • Dat Bundesferkel sagt:

          Das ist richtig. Leider bei 2016/2019 Hyper-V manchmal eine Notwendigkeit, besonders wenn zu Beginn der garstige Default-Switch nicht eingerichtet wurde und im Nachhinein "aus dem Nichts" auftaucht und das Netzwerk verunstaltet.

          Hauptproblem sind dann die Zuweisungen und Bindungen. Besonders nervig: Der Anzeige-Name des ehemals externen virtuellen Switches wird dann 1:1 auf den auf interne Verbindungen kopiert.
          Man wundert sich bei den VMs dann, weshalb 2 vEthernets mit gleichem Namen zur Auswahl stehen und darf dann (vorzugsweise via PowerShell) Informationen zu den verbauten / vorhandenen Netzwerkadaptern auflisten, nebst deren Index-Nummer und dessen gegenwärtige Bindungen.

          Geräte-Manager zum Löschen der Netzwerkadapter: Absolutes No-Go, da bleibt die Hälfte bestehen und das Problem kehrt immer und immer wieder.

          Hatte das Abenteuer auch vor knapp einer Woche bei einem frischen Server 2019. Was für ein Geraffel. Zum Glück ist und bleibt der Server die einzige Ausnahme.

          Aber ich freue mich schon auf die nächsten Windows Updates* und habe die nötigen Powershell-Werkzeuge bereits vorbereitet.

          *Freude deshalb, weil es bei vielen Updates die zuvor eingespielt wurden, wieder von vorne begann.

  3. Stefan T sagt:

    Habe das gleiche Problem seit Nov bei mehreren VMware Kunden. Selbst verschieben auf einen anderen Host bringt nichts. VM wird extrem langsam, bis zum quasi Freeze. protokolliert wird nichts. Sehr unbefriedigend für den Kunden und uns.

  4. Firebalde sagt:

    Ich hatte gelegentlich auch das Problem. Bei uns lag es an einer von VMWare auf Hyper-V migrierten VM der Generation 1. Seit dem diese VM nicht mehr auf dem System läuft sind die Probleme mit Host und Cluster nicht mehr aufgetreten.
    Vielleicht gibt es da ja ein Problem?!

  5. Christian sagt:

    Hi, ich hatte den Fall auch. Bei mir sind die ausgefallenen Nics für die ISCSI Verbindungen zum SAN genutzt worden. Dabei habe ich mir mehrfach LUNs zerschossen und hatte Spass beim Recover. Das Problem verursacht haben die X710. Sowohl Fujitsu als auch MS haben 6 Monate an meinem Problem untersucht. Als Server hatte ich einen Primergy 2540M4 mit Windows 2016 und Microsoft zertifizierten Komponenten im Einsatz.
    Ersetze den Intel NIC Mist und das Thema ist erledigt.

  6. Mike sagt:

    Netzwerkkarten wurden bereits mehrfach gelöscht (inkl. Treiber) und neuinstalliert.
    Auch ebenso die vSwitches.

    • Mike sagt:

      netcfg /d habe ich noch nicht probiert, ich hatte über den Gerätemanager die ausgeblendeten Geräte, sowie die installierten Geräte gelöscht.
      Bringt hier netcfg /d mehr?

      In den VMs die Netzwerkkarten habe ich bisher nur einmal gelöscht.
      Wie ist da die Erfahrung bei Aktivierung, Deaktivierung von SR-IOV etc.
      Ändert ihr was IN der VM am Treiber? Installiert ihr neu? Oder werft ihr die virtuelle Hardware gleich komplett raus? (bisher nur einmal probiert).

      • Paul sagt:

        Von jeder Netzwerk Karte behält Windows eine Kopie des Settings. .
        Sieht es die Karte wieder, nimmt es die alte Konfig und den alten Namen.
        Verteilt man Images, so ist in jedem Image das Setting der Karten im Goldenen Image drin. Sysprep löscht die alten unnützen Einträge widerwarten nicht.Es stört ja normalerweise nicht.
        Man erkennt es daran, das die Nummerierung nicht mjt ethernet sondern mit ethernet5 beginnt.
        Netcfg /d löscht das alles weg.
        Wie bei einem neuen System.
        Baut man neue Karten ein und konfiguriert diese und
        Baut man die alten Karten wieder ein, laufen die mit der Alten Config und dem alten Namen/lfd. Nummer.
        Einen anderen Befehl um die Config einer Karte komplett zu löschen kenne ich nicht.
        Das Gedächtnis gibt ein Problem, wenn ein NIC einen speziellen Namen haben muß. Dann ist dieser schon belegt, und man kann nur noch in der Registry löschen.
        HTH

  7. Mike sagt:

    Eine Migration fand nicht statt. Der Server ist seit Neuinstallation der VMs gleich.
    iSCSI ist nicht in Verwendung. Alle Komponenten sind zertifiziert, wie Christian schreibt. Die Idee alles auf einen Ersatzsteuer umzuziehen ist sicherlich interessant, wenn man wüsste, dass es damit behoben ist, wäre der schon längst bestellt ;-)
    Wir befinden uns noch im vollen Herstellersupport.
    Bezüglich der Intel NIC X710 hatte ich anfangs auch vermutet, dass sie die schuldige sei. Jedoch scheint das Problem auch zu bestehen, wenn sie nur eingebaut ist und das LOM genutzt wird. Aktuell läuft der Test mit nur einem Prozessor.
    Frage an die Leserschaft: QLOGIC statt Intel? Oder lieber bei der Intel bleiben, wenn es nicht daran liegen sollte? Intel war bisher immer sehr gut, wenn sie nicht gerade ihre Ausreißer wie den P4/Atom hatten.

    • Christian sagt:

      ja, unbedingt. Nimm die X710 raus. Es ist egal ob ISCSI oder nicht…ist ja auch nur IP.

      Gruß Christian

      • Paul sagt:

        man sollte nicht vergessen, das MS ja neulich am TCP Stack rumgeschaubt hat, und eine deep Package Inspektion eingebaut hat. Also ganz erheblich am Timing gedreht hat.
        Aber warum tritt das nur hier zutage?

      • Paul sagt:

        Gib es im Event log wirklich keine Einträge der NIC?
        Da muss zu mindestenst was drin stehen daß das man einen Ethernet connect hat oder diesen verloren.
        Wenn das nicht drin steht hat jemand das Loggen dieser / solcher Meldungen ausgefiltert.
        Man will ja ein leeres Log haben.
        Gerade bei zu Event 23/32 gibt es im Netz den Rat diese Events wegzufiltern, wenn man keine neue Firma /Treiber bekommt.

    • Olli sagt:

      >>> Die Idee alles auf einen Ersatzsteuer umzuziehen ist sicherlich interessant, wenn man wüsste, dass es damit behoben ist, wäre der schon längst bestellt ;-)

      Gleich bestellen, weil zum Virtualisieren sowieso zwei Server sinnvoll sind. Also braucht ihr den sowieso…

      • Mike sagt:

        Ich bin ja gerne bereit immer das Beste vom Besten zu kaufen, möglichst viel Redundanz einzubauen und auch zu übertreiben.
        Aber zwei Server wären in dieser Größenordnung mehr als atypisch.
        Trotzdem finde ich die Idee langsam auch interessant, weil man schneller umschalten kann…
        Aber gerade Redundant bedeutet wieder viel mehr Wartungsaufwand.

  8. Stiller Leser sagt:

    Hi
    Nur ins leere geschossen. Die vms liegen auf dem hyperv seit okt/nov auf einem refs volume?
    Hatte mal vms auf hyperv die das Netzwerk fast täglich einstellte und hier war der gemeinsame Nenner refs Luns aber auch refs Partition in der vm.
    In meiner Konstellation spielte auch noch Veeam, hyperv HA eine Rolle. Fehler trat aber nicht während Backup auf, sondern auch außerhalb des Backupfensters. Vm move auf anderen Mode half dann meistens für 0,5-1tag. Nach downgrade auf ntfs alles super..
    Vg

    • Mike sagt:

      Nein alles NTFS. Klassisch lokal SAS HW-RAID SATAs.
      Der Fehler tritt auch im normalen Betrieb "irgendwann" auf.
      Nur Vorzugsweise nach längerer Laufzeit und bei Last.
      Wobei es sicherlich daran liegt, dass man bei Last eher was bemerkt.

    • Mike sagt:

      Durchsatz ist nicht das Problem, es geht ohne Last nichtmals ein Ping durch.
      Auch diverse NIC Funktionen wurden bereits deaktiviert.
      Aktuell läuft der Server auf 1 CPU und die X710 steckt jetzt auf CPU1 lanes.
      Wenn das funktioniert könnte man es eingrenzen. Der Fehler tritt leider nicht zuverlässig und nicht zeitnah auf.

  9. jup sagt:

    X710 …
    Komplett ausbauen …
    Ich hab die Erfahrung mit "hohldrehender" HW gemacht, das ein "disable" im Gerätemanager bzw. Treiber deinstallieren NICHT hilft !
    Erst ein pysisches entfernen bringt Ruhe rein.

    • Mike sagt:

      Okay darauf könnte es bei den nächsten Tests hinauslaufen.
      Die On-Board X722 LOMs kann ich jedoch nur in Windows deaktivieren.
      Das BIOS sieht dies nicht vor. Solche Probleme sollte es bei zertifizierter Hardware eigentlich nicht geben…

  10. Blupp sagt:

    Nur ein Geadanke weil uns Instabilitäten vor 20 Jahren graue Haare bescherten, wir saßen fast zwei Monate an dem Problem. Nach ewiger Testerei war es damals ein Netzteil. Es lieferte stabile Spannungen und ausreichend Leistung, aber auch Spannungsspitzen die für Chaos sorgten.

    • Mike sagt:

      Wäre sicherlich auch ein Gedanke.
      Laut BMC alles okay und die Netzteile sind redundant.
      Man könnte im Wechsel mal eins entfernen.
      Die To-"Try" Liste wird immer länger ;-)

    • Paul sagt:

      Aber hier geht es doch um fast neue Fujitsu Server.
      Nicht um 8 Jahre alte Mähren.

      • Blupp sagt:

        Das Alter ist es nicht immer, die Workstation damals, ein P-pro kurz vor der Jahrtausendwende, war nur etwas über ein Jahr alt und solche Probleme sollten nicht auftreten. Die Kiste war zu neu.
        Es hing immer der SCSI-Controller und keiner konnte sich ein Netzteil als Verursacher vorstellen. Manchmal ist's komisch.

  11. Paul sagt:

    Es gibt's keinerlei (ungewöhnliche) Einträge im Event Log?
    Ein Hardware Fehler würde m.E.n. auch mal andere Probleme triggern.

    Trivial:
    Wann genau lief der Server das letztemal nachweislich korrekt?
    Wann genau trat der erste Ausfall auf?
    Was wurde dazwischen geändert?
    (Dazu zählt auch wechsel im Personal, Standort, nicht nur Updates.)
    Was ist bei dem befallenem Geräten anders als bei den tausenden anderen, die wahrscheinlich funktionierten?

    Das manche Netzwerk Karten Probleme entwickeln und einfach die Arbeit einstellen ist bekannt. Intel hat das Problem, daß sie seht oft verwendet werden, weil sie einen guten Ruf haben (statistische Verzerrung).. Auch gibt es ganze Chips die Buggy sind und sich bei bestimmten Umständen festfressen.
    Eine Zeit lang gab es überhaupt keine Karten am Markt.
    Nicht auszuschließen daß das Karten mit den Buggy Chips recycelt wurden

    Aber der Server lief doch schon?

    Natürlich kann eine Karte auch das PCIe stören.
    Gab es Mal bei den ersten PCIe Karten, die einfach nur eine Bridge hatten, die PCI auf PCIe umsetzen. Leider war dieser Chip Buggy.
    .
    Aber man darf auch nicht auf den Effekt "Betrunkener, der unter der Laterne seinen Schlüssel sucht, weil da halt besseresLicht ist" reinfallen.

    Ich würde Mal gucken wollen, was denn das Letzte ist, was über die Karte rein/raus gegangen ist. Evtl. ist es immer das Gleiche.
    Aber irgendwie glaube ich nicht an einen Hardware Fehler.

    • Mike sagt:

      a) Die NIC wurde bereits durch eine neue, gleiche ersetzt.
      d.h. wenn sind es entweder mehrere Fehler oder ein Design/Treiberfehler von Intel.
      b) Wenn es nicht die NIC betrifft bzw. nur ein Zusammenspiel, dann würde ich auf den Novemberpatchday von Microsoft tippen.
      Dies war die letzte große Änderung, bis zu der es definitiv noch keine Probleme gab. Ansonsten hat sich nahezu nichts verändert.
      Mit 100% Sicherheit war im September 2022 noch alles i.O.

      Anfänglich war das Problem auf das "DC-Hang" Problem einzugrenzen, bis sich später auch andere Maschinen nach und nach daran beteiligten.
      Es ist nicht auszuschließen, dass die anfänglichen Microsoft Patchdayfehler die anfängliche Ursache waren, und danach noch etwas verändert wurde.
      Jedoch war auch der "DC-Hang" nicht typisch 100% wie in den known issues von MS beschrieben.

      Als der DC hing war es wie folgt:
      Login über Hyper-V Manager im erweiterten Modus oder RDP nicht möglich.
      Login über "Konsole" möglich, jedoch dauerte die Benutzeranmeldung scheinbar endlos.
      Nach Deaktivierung von luafv durch MS-Rat, war ein Login möglich. Das Problem sonst aber unverändert.
      Da es nur einen DC gibt, ging natürlich auch sonst nicht mehr viel.
      Btw: Der VM Host ist kein Domänenmitglied.

      • Paul sagt:

        Ich habe noch eine perverse Idee.
        Es gibt inzwischen ja auch 5 Gigabit für USB.
        Wenn der Server nicht wirklich am Rand läuft.
        Könnte man mal die NICs tauschen.
        Aber ich vermute, das das ein Software Problem ist.
        Hast Du mal die Pakete mitschreiben lassen?
        In den Tieren von netsh gibt's es eine Art TCP Dump.
        Da muss man nichts installieren.
        Einen Switch mit mirror wäre auch ne Möglichkeit.
        Mal gucken, was denn die Letzten Pakete waren.
        Das würde auch bei Software Problemen helfen.
        Was ist an den Servern bei euch so anders?
        Was ist nach September geändert worden?
        Es muß nichts großes gewesen sein.

        Achso:
        Das mit dem ewigen Warten auf Login habe doch schon mal gelesen. Das kann aber Folge der fehlenden DNS Auflösung sein…

        • Mike sagt:

          Fehlerhafte DNS Auflösung am DC halte ich für unwahrscheinlich da Loopback. DNS & DC => 1 VM

          Sniffen könnte ich am Switch, aber ich vermute das Problem eher auf Treiber/vSwitch/VM Ebene. Mir fällt auf anhieb aber nichts ein, was mir das weiterhelfen könnte.
          Wäre aber auch noch eine Option im Notfall.

          Oktober/November Microsoftupdates, ggf. noch BIOS/Microcode Updates etc. was Fujitsu mitausliefert.
          Aber so genau lässt sich das auch nicht mehr feststellen.
          Mit der Zuordnung zum Windowspatch day Okt oder Nov war ich mir eigentlich sicher.

          • Paul sagt:

            Guck doch mal nach, wann das mit der restarterei angefangen hat. Server fährt man ja nicht eigentlich nicht so oft runter.
            Darum fragte ich ja die blöde Frage, seit wann genau es nicht mehr ging.
            Vielleicht lässt sich ja das mit Updates korrelieren.

            Und ebend was ist bei euren Servern so anders ist als bei vielen vielen anderen.
            Software Fehler haben die Eigenschaft, sich auf mehreren Maschinen auswirken zu können.
            Hardware Fehler eher nicht (darum ja die Schrauberei mit den NICs)

            Also ein Leihserver, Platten und NIC tauschen und mak gucken ob es am Kuchen Blech liegt.

            Ich wäre auch durchaus dabei eine nicht zertifizierte Karte einzubauen. Dann kann man zwar nicht mehr viel Support erwarten, aber die Kiste läuft (vielleicht).dauerhaft. (Ich kenne Deine Anforderungen nicht, aber vielleicht reichen ein paar USB Ethernet Stick s Weiß aber nicht, inwieweit damit Bündelung etc funktioniert)

            Aber wie gesagt :
            Wenn das Problem seit dem November Update auftritt, haf MS da was vermasselt. Irgendwie ein Zähler im TCP Stack läuft über oder so.
            Du kannst auch mal ein Dauer ping machen um den genauen Zeitpunkt festlegen zu können.
            Vielleicht ist das immer wenn ein Kollege sich anmeldet, oder wer die Schranktur zumacht.

            Es ist herum gestochere, weil niemand weiß was MS geändert hat.

        • Mike sagt:

          NIC raus und nur On-Board nutzen wäre auch eine Option. 1 GbE würde erstmal reichen.

          Aber dann probiere ich erstmal die QLOGIC.
          Die X710 scheint hier keine Freunde zu haben.
          Und das obwohl Intel meistens sehr gut ist..

  12. Daniel sagt:

    Hi,

    nimm definitiv die x710 raus. Habe damals massivste Probleme damit gehabt. Auch CPU Fehler und NMI ERRORS. Link flapping, Abstürze vSwitch usw. usw. IBM/Lenovo wussten auch nicht weiter, ist sogar bis zum Produktspezialisten in USA/Asien eskaliert und die Hälfte vom Server wurde getauscht und eingeschickt. Nach monatelangen Untersuchungen wurde die Karte gegen eine Mellanox getauscht. Danach war Ruhe. Kurze Zeit später nahm Lenovo die Karte ersatzlos sogar aus dem Sortiment.

    So viel zum Thema x710.

    Viel Glück.

  13. der bug ist das ziel sagt:

    komplexitaet killt alles. mal so viel zum mainstream plattform dieses planeten. seit monaten probleme? sogar direkte spezialisten bei den grossen anbietern? und damit koennt ihr dann leben usw? bloss weils noch in der garantie ist? also kosten leistung erscheint mir da ueberhaupt nicht.

    aber vielleicht sind ja die prozesse darauf nicht so teuer bzw deren ausfall nicht so teuer. wer weiss das schon.

    kann ich nicht verstehen :)
    cheers.

    • Mike sagt:

      Es funktioniert ja alles einwandfrei, wenn man je nach wechselnder Auftrittshäufigkeit 1x am Tag neustartet.
      Und da die Maschine nur zu normalen Arbeitszeiten gebraucht wird ist es natürlich relativ leicht mittels ständigen Reboots dies zu behoben.
      Blöd ist einzig und allein, wenn der Fehler im laufenden Betrieb den Reboot (max 1. pro Tag) erzwingt.

      Sicherlich nicht angenehm, nur bringt ein Austausch der Hardware nicht mit Zuversicht die Lösung.
      Im schlimmsten Falle müssen alle VMs neu aufgesetzt werden.
      Dafür benötigt es aber sehr viel Zeit. Gegen Ende des Jahres mag das eine Option sein. Aktuell aber möglichst nicht.
      Wenn ich wüsste, dass der komplette Hardwaretausch die Lösung ist, dann wäre die Hardware schon lange da.
      Nur wenn es ein Softwarefehler innerhalb der VM ist, wird es sicher nicht helfen. Aber definitiv einer der letzten Optionen, wenn nichts mehr hilft.
      Nur wenn man bei jedem IT Problem vorsorglich die Hardware komplett tauschen würde, dann würde sich die Industrie freuen ;-)

      • Paul sagt:

        Ich habe mal einen Server bei einem Kunden gesehen, der wurde jede Nacht neu gestartet.
        Die User hatten sich schon so an das Hängen der Anwendung gewöhnt, das sie einfach was anderes machten, wenn due Anwendung abgestürzt war:
        Sie riefen keinen Service, wußten sue doch, dass sie am nächsten Morgen wieder arbeiten können werden.
        Wozu der Stress mit der Hotline.

        Es geht also.
        Man muß die Menschen immer gut trainieren..

        • Mike sagt:

          Solche Kommentare bringen natürlich nichts.
          Natürlich ist das so kein haltbarer Zustand.

          • Paul sagt:

            Ja klar geht das so nicht. Der Konsultant der die Geniale Idee mit dem Auto matischen Nächtlichen Reboot hatte war auch nicht mehr lange da. Zumal das Backup inzwischen so lange Dauerte, das man nicht kurzmal ein Reboot fahren konnte.

      • Paul sagt:

        Du sollst nicht die Hardware tauschen.
        Du solltest in die Cloud…
        Chefffle könnte dann auch Deinen Job outsouren…
        Wenn man denn dem ms Marketing glaubt…
        SCNR

        • Mike sagt:

          Sicher ein schlimmer Trend unserer Zeit.
          Gut dass ich mir nur um Qualität, Zuverlässigkeit und Sicherheit sorgen machen muss.
          Budget und Cloud ist daher "don't care" ;-)

  14. Bob sagt:

    Ich hatte schonmal Probleme an nem Hyper-V-Host, die von der Backupsoftware verursacht wurden.
    Würde mal alle Backup-Jobs vorübergehend deaktivieren und schauen ob das Problem weg ist.
    Ansonsten schließe ich mich den Kommentaren an, die für einen zweiten Host plädieren, auf den man die VMs mal rüber zieht, um das Problem einzugrenzen.
    Außerdem kann die Verteilung über NUMA-Knoten Ärger machen. Da sollte man auch mal unterschiedliche Konfigurationen austesten. Aber Sie probieren ja derzeit schon mit nur einer CPU, wenn ich das richtig gelesen habe.

    • Mike sagt:

      Ja, probiere nur mit einer CPU und NUMA Einstellung war MS Default.
      Hatte bisher immer gut geklappt.

      Intel verweist auf den Hersteller.
      Veeam habe ich auch eingeschaltet, die schauen jetzt auch mal drüber.
      Denke Veeam ist in Sachen Hyper-V und Netzwerk schon recht spezialisiert.

      • Paul sagt:

        Ich weiß jetzt nicht ob Fujitsu oder der Karte hersteller die Firmware oder das Parameter NVRAM neu füllt.
        Das da X710 auf dem Chip steht sagt ja nix welche Firmware drin ist.
        In Linux gibt es Befehle, diese Speicherbereiche auszu lesen und ändern. Vielleicht sind da Karten verbaut worden, die nicht dem Standard entsprechen.

        Aber ich glaube nicht das das Hardware ist.
        Kann Fujitsu das Problem denn rekonstruieren?
        Wenn nein, wie wollen Sie Dir helfen?

      • Paul sagt:

        Da Dir im Fehlerfall der Wartungs Zugang auch wegfällt.
        Wie wäre es, wenn Du einen USB Ethernet Adapter für den Wartungs Zugang konfigurierst?
        Der USB benutzt andere PCI planes, so das von da auch kein Problem kommen kann.
        Andere Treiber hat es so wie so.

    • Blacky Forest sagt:

      Kenne ich auch, gab bei uns damals Probleme mit Broadcom-Netzwerkkarten.
      Bei Snapshots ist Hyper-V durcheinandergekommen und die Maschinen konnten nicht mehr neu gestartet werden, der komplette Host musste neu gestartet werden. Kurioserweise drei baugleiche Hosts mit identischem Firmware-/Treiberstand, aber unterschiedlichem Verhalten.

  15. Werner sagt:

    Das würde ich als Erstes ausprobieren – ev. ist es wirklich der Fehler:

    Workaround
    Gehen Sie in den Windows Device Manager -> Netzwerkadapter -> Intel (R) Ethernet Controller X710 für 10-GbE SFP + -> Erweitert -> Rss-Lastausgleichsprofil und ändern Sie den Wert für alle Ports auf' NUMAScalingStatic.
    X710 Optionen (81Y3520 und 94Y5200) sind im System installiert.

    Zusätzliche Informationen
    Dieses Problem tritt auf, weil die Standardeinstellung für das RSS-Lastausgleichsprofil auf "ClosestProcessor" gesetzt ist. In dieser Einstellung wird ein Kern für den gesamten Netzwerkverkehr mit der Option nan X710 verwendet und überlastet. In diesem Fall wird die Netzwerkverbindung vorübergehend unterbrochen. Durch Ändern des RSS-Lastausgleichsprofils in 'NUMAScalingStatic' wird die Last auf alle Kerne verteilt.

    Ein aktualisierter Gerätetreiber setzt die Standardeinstellung des RSS-Lastausgleichsprofils auf 'NUMAScalingStatic'.
    https://www.ibm.com/support/pages/intel-x710-nic-has-intermittent-link-drop-under-heavy-load-windows-lenovo-system-x3950-x6-6241

    • Mike sagt:

      Auch diesen Artikel habe ich schon (direkt von Intel) durch.
      Durch die Neuinstallation aktueller Treiber sollte der default-Wert dieses Problem umschifft haben.
      Abgesehen davon tritt es nur bei hoher Last auf.
      Die 10 GbE NIC wird aktuell NIE stark ausgelastet!
      Einziger Zweck ist die schnelle Übetragung bei Updates/Sicherungen etc.
      Das Problem tritt aber weit außerhalb dieser Zeiten aus (Wochen).

      Leider ergeben die Tests am Wochenende selten zeitnahe Resultate, aber ich vermute aktuell stark ein Problem bzgl. zweiter CPU ggf. iVm. NIC.

  16. Frank sagt:

    NIC Teaming aktiv?

  17. Martin sagt:

    Hi,
    Also ein ähnliches, nicht identisches Problem hatte ich mal mit einem Dell Poweredge R840.
    Hyper-V 34x neuinstalliert, kein Spaß die Zahl stimmt, verschiedenste VMS freezten und nur per Glück bekam man mal nen BSOD. Eregnisanzeige an Host und VM so gut wie leer. Dell Prosupport kam immer wieder zu dem Punkt "Hyper V neu installieren". Endergebnis vom Lied, die komplette Maschine wurde gewandelt. Da die Kiste 4 CPUs hatte und DELL nicht alle CPUs tauschen wollte, war dies wohl der günstigere Weg für Dell. Aber das hat nerven ohne Ende und eben 6 Monate gedauert. Mein Vorteil war das ich eine zweite, identische, Maschine im Cluster hatte. Dadurch konnte ich belegen dass die VMS an sich in Ordnung waren. Aber trotzalledem ließen sie mich 34x die Büchse neuinstallieren. Kannste dir nicht ausdenken.
    Ich bin immer noch der Meinung das eine oder mehrere CPUS nen Schuss hatten. Da der Case bereits offen war, konnte ich aber nicht mehr soviel quer testen wie ich wollte…

    Achja sämtliche CPU Tests liefen fehlerfrei durch. Und das Problem trat meist dann auf wenn die Kiste Richtung Idle gegangen ist. Bedeutet in der Nacht wenn keiner gearbeitet hat. Unter stetiger Last, lief es einigermaßen.

  18. squat sagt:

    Ich hatte so Probleme durch einen Spanning Tree Fehler auf HPE und Mikrotik switches.
    Wie redet denn der Hyper V mit dem Netz?

  19. Olli sagt:

    Schon mal eine komplett frische VM installiert, ohne Domain Join usw. usf. – Out of the Box – keine Patches nichts? Friert die dann auch ein oder nicht?

  20. oli sagt:

    Hab aktuell bei einem Kunden das Problem, dass SR-IOV beim Veeam-Backup ausfällt. Verbaut sind Intel X722-NICs glaube (Terra Wortmann Server) und installiert ist Windows Server 2022. Hab jetzt schon die neuesten Intel Treiber auf dem Hyper-V Host sowie die neuesten VirtualFunction-Treiber in den VMs installiert. Bricht nach einigen Wochen problemlosen Laufens und mehrere täglichen Sicherungen irgendwann bei einer Sicherung mit Veeam ab.

    Im Hyper-V Manager steht dann auch unter Netzwerk, dass die Netzwerkkarte "heruntergestuft" wurde und SR-IOV nicht bereit sei. Auf die VMs kommt man dann nur noch per Hyper-V Manager (kein Netzwerk mehr vorhanden) und im Gerätemanager der VM steht dann auch ein Ausrufezeichen unter dem vFunction-Netzwerkkarteneintrag. Hab jetzt SR-IOV erstmal auf allen vNICs deaktiviert (Sicherungen laufen ja nachts wo es keiner mitbekommt und morgens kann dann keiner arbeiten :x).

    Achso, die statische NUMA-Zuweisung hab ich im Hyper-V Manager aktiviert (bzw die dynamische Zuteilung deaktiviert), falls das relevant sein sollte. Vlt hat ja wer ein Plan, woran das liegt.

    • Mike sagt:

      Auch die Deaktivierung von SR-IOV hat in meinem Fall nicht geholfen.
      Laut den Intel Release Notes gab es etliche Bugs, die mit neuerer NVM (Firmware) und Treiber behoben wurden. Schau da mal auf der Intel Downloadseite nach.
      SR-IOV sollte auch mit dem Microsoft Standard VM Treiber funktionieren.

  21. Mike sagt:

    Das war tatsächlich der letzte Rat von Microsoft. (frische VM parallel)
    Aber nein, das habe ich noch nicht getestet.
    Es gibt so viele Dinge die man ausprobieren kann, da wollte ich erstmal die logischeren bzw. einfacheren Dinge ausprobieren.
    Mit einer CPU läuft er bisher gut. Abwarten…

    Fujitsu hat eine zertifizierte QLOGIC vorab herausgeschickt, damit ich diese tauschen kann. Der Hersteller ist also sehr bemüht – nicht, dass da der falsche Eindruck entsteht. Andere Hersteller hätten vielleicht schon wg. vermeindlichen Softwarefehlern abgewunken.

    Also brauche ich gar keine USB Experimente einzugehen.

    Next Steps wenn es so klappt:
    Nach ca. 1-2 Wochen Laufzeit CPU2 wieder aktivieren.
    Tritt das Problem dann auf: NIC tauschen.
    Tritt es immernoch auf: CPU/Board tauschen?
    Aber der Entscheidungsbaum ist noch zu verzweigt.. ich Berichte demnächst!
    Leider dauert es bedingt durch die Eigenart des Fehlverhaltes immer eine Weile.

    • Günter Born sagt:

      Ich ziehe mal ein wenige Feedback aus Facebook-Gruppen nach hier:

      #1: Oftmals hatte bei uns ein Neustart des RDS-Dienstes (remote über Computerverwaltung) geholfen, zur Not ein Neustart per shutdown.exe oder radikal am VMM. Seit Abschaltung von RemoteFX haben wir keine Probleme mehr.

      #2: Wie wurden die Installationen denn durchgeführt? Per originaler Microsoft-CD bzw. -ISO oder einer ROK-Version von Fujitsu? Sollte zwar keinen Unterschied machen, aber vielleicht gibt es da ja eine Gemeinsamkeit.
      #2a: §s ist aber auch unglaublich was FJS alles als default auf so eine Kiste bügelt. Mit guter Performance merkt man es vielleicht nicht so krass, aber bei „kleinen" oder alten Kisten ist das gruselig

      #3: … er müsste ja über das iRMC dem Hängen bleiben zuschauen können…
      Zumindest direkt auf den Hypervisor. Systemzeit beachten – dann merkt man ja wenn und wann er hängen geblieben ist..
      #4: Leihserver besorgen, VMs migieren. Den alten Server neu aufsetzen und eine oder 2 hinkopieren und schauen, ob er danach besser läuft. Sonst ist es n Hardwaredefekt. Vielleicht ist es der VM Switch oder RAM oder auch das Netzteil.
      #5: Mit Fujitsu habe ich im letzten Jahr schon so einiges erlebt: PCs wachen nicht mehr aus dem Standby auf, USB Ports wurden abgeschaltet. Ergebnis: BIOS Update und Mainboard Tausch.

      Fujitsu Laptop und PortReplicator: konnte die angeschlossen LG Bildschirme nicht auf die gleiche Auflösung einstellen, mit Asus Bildschirmen ging es. Natürlich wurden zuvor BIOS upgedatet, Kabel getauscht, Techniker hat das Mainboard getauscht. So mache Fujitsu Hardware hat mich zum verzweifeln gebracht. Mein Ratschlag: zum Testen mal nen HP oder Dell Server nehmen.

      #6: OS Array und VM Array sind ja getrennt und performant? Mindestens R5, R10 oder besser und keine Mirror?

  22. rpr sagt:

    Unabhängig vom konkreten Them ist es ja bekannt das MS seinen Hyper V nicht gerade priorisiert.
    Man kann sich sicherlich über Vmware streiten und das Broadcom im Spiel ist macht es auch nicht besser aber eine Alternative sollte man langsam aber sicher in der Schublade haben.

  23. rpr sagt:

    Vielleicht noch als Hinweis für den einen oder anderen:
    Immer die KVM Optionen von Servern nutzen und wenn möglich auf ein eigenes Netz legen, Löst zwar nicht direkt das Problem spart aber ggf. Stunden auf der Autobahn.
    Es gibt auch externe Geräte zum anschliessen über die Schnittstellen von z.B. Lindy.
    Gruß

  24. M.D. sagt:

    Nachdem schon vieles probiert wurde und die NICs immer irgendwo im Zentrum des Verdachts stehen: was ist den mit den Kabeln und der an die NICs angeschlossenen Gegenstelle? Wurden schon andere LAN-Kabel getestet, evtl. auch auf anderem Weg verlegte LAN-Kabel? Was ist mit dem Switch am anderen Ende der Kabel? 10G-T gilt allgemein als ziemlich anspruchsvoll und empfindlich hinsichtlich Kabeln, Steckverbindern und Kabelverlegung. Vielleicht kommt aus unerwarteter Richtung irgend eine seltsame Störung ins System, die das komplette Netzwerk im System beeinträchtigt und runter reißt.

    • Mike sagt:

      Kabel sind Cat 8.x, und das Switch sollte auch meckern, wenn da etwas nicht stimmt.
      Natürlich kann man dort seltene Probleme auch nicht ausschließen, aber dann sollten sie nur ein Port betreffen.
      Auch die Umschaltung auf 1 GbE LOM bei Nichtnutzung (aber nicht Deaktivierung) der eingebauten NIC führt zu Problemen.
      Grundsätzlich wäre es aber denkbar mal ein Switch mit Kabeln direkt hinter den Server zu stellen um auch das auszuschließen. Dennoch, der Host bleibt ja normal stets per IP erreichbar, egal ob er an 10 GbE hängt oder nicht.
      Nur die VMs eben nicht – soweit man das nachvollziehen kann.

      Warten wir diese Woche mal ab, ob die 1 CPU Lösung stabil läuft.
      Ich denke dann können wir deutlich besser eingrenzen.

      • M.D. sagt:

        Cat 8.1 müsste das dann sein, wegen der Stecker; 8.2 hat etwas andere, die nicht in den NIC passen dürften. Allerdings ist das laut vieler Fachbeiträge im Netz ein eher ungewöhnlicher Einsatzzweck, deren Tenor nach wird Cat 8 eher bei 25G, 40G und 100G zwischen Routern/Switches im Rack-Bereich eingesetzt, als günstiger LWL-Ersatz. Bei 10G sind Cat 6a und Cat 7 vollkommen ausreichend, Cat 8 eher überdimensioniert, was natürlich nicht heißt, dass es prinzipiell nicht geht, denn der HV antwortet ja auf ping, wenn die VMs nicht erreichbar sind.

        Jedenfalls toi toi toi, nichts strapaziert die Nerven mehr als ein Server, der aus obskuren Gründen regelmäßig Probleme bereitet.

      • rpr sagt:

        Das Problem hatte ich so wie du es beschreibst auch mal unter Vmware aber genau umgekehrt. Host nicht erreichbar aber VMs "weg". Hilft natürlich nicht direkt weiter aber in dem Fall haben wir es durch den Wechsel der Netzwerkarten in den Griff bekommen.
        Will sagen die Anlagen sind mittlerweile so komplex das man manche Effekte einfach nur durch simples Austauschen eingrenzen kann. Ist aufwendig und kostet Geld aber manchmal der einzige zielführende Ansatz.

  25. 1ST1 sagt:

    Sehe ich richtig, dass in dem Netz nur ein DC ist? Unbedingt einen Zweiten mitlaufen lassen, vielleicht sogar einen physischen parallel zur VM!!!

  26. Ron sagt:

    Moin in die Runde!

    Wir hatten hier fast ein Jahr auch diverse Probleme und keiner wusste zu helfen.
    Schlussendlich habe ich mal jegliches Teaming aufgelöst und den Hyper-V Switch neu gemacht und seitdem ist Ruhe im Schiff.

    • anon sagt:

      Würde ich auch so machen. Teaminig auflösen (und nicht wieder neu konfigurieren) und den vSwitch neu aufsetzen. Mit Teaming hatte ich bereits mehrfach schlechte Erfahrungen.

      Im Übrigen @Mike: Da die Maschine eine Weile läuft bevor die Störungen auftreten, hast du mal versucht, auf ein Speicherleck zu prüfen? Ich würde das einmal tun und mit dem Performance Monitor den Speicher überwachen und aufzeichnen, bis die Kiste auf den/die Fehler läuft. Falls tatsächlich ein Leck vorliegt, kannst du zumindest das Problem genauer eingrenzen.

  27. n8c sagt:

    Setz mal (auf dem HV) die Transmit und Receive Buffers auf 2048 und starte neu.
    Ändert sich was?

  28. bon-go sagt:

    Bei einem unserer Kunden trat genau dieses Problem letztens erst auf. Zwei HP Server Windows 2019, div. VM, der eine legt den Switch nachts immer lahm. Das Problem trat reproduzierbar beim Veeam Backup auf.
    Unsere HV (Server und VM) NIC und Switch Skripte laufen lassen sowie netcfg -d und Switch auch neu erstellt – kein Erfolg.
    Veeam deinstalliert bzw. ausgesetzt – funktioniert.
    Das Problem wurde temporär durch Umzug der Veeam VM – bei dir wohl nicht möglich – auf die andere Maschine gelöst.

    • Mike sagt:

      Das alte Veeam 11 oder neue 12?
      Hatte beide Versionen im Einsatz ohne Änderung diesbezüglich.
      Veeam VM? Läuft Veeam nicht auf dem Host sondern in der VM?
      Es kommt zwar oft vor, dass es nach der Sicherung nicht mehr geht, aber nicht unbedingt deswegen. Es gibt teilweise auch Einschränkungen bei Snapshots und SR-IOV. Aber wo der Artikel stand weiß ich nicht mehr. Konnte diesbezüglich aber nichts feststellen. Mit nur einer CPU scheinbar gut.

  29. Mike sagt:

    So also aktueller Stand:
    Bei deaktivierter CPU2 und NIC auf PCIe Slot der CPU1 scheint es keine Probleme mehr zu geben. Weiterhin wurde die RC Firmware/Treiber auch im LOM installiert.

    Jetzt bleibt zu überlegen:
    Intel raus, QLOGIC rein und damit weitertesten oder nochmal annähern..

    Bericht folgt!

  30. Mike sagt:

    Nach erstem Resultat zu urteilen scheint auch die QLOGIC Karten nichts gebracht zu haben. (erstmal ohne QLOGIC eigene Treiber in der VM).
    Das Problem besteht bei einer VM auf dem 1GbE LOM und gleichzeitig auf einer VM auf 10GbE NIC.

    Hat jemand eine Idee, warum es mit nur einer CPU funktioniert?

    • Mike sagt:

      Mit der QLOGIC Karte gibt es keinerlei Verbesserung.
      Nächster Test: Intel wieder rein, diesmal aber auf Slot 6@CPU1 während beide CPUs aktiv bleiben.
      Erinnerung: Mit nur einer CPU auf Slot 6 hat es problemlos geklappt.
      Jetzt soll herausgefunden werden, ob die Zuordnung zur 2ten CPU das Problem ist, oder die Multiprozessoreigenschaft.

      • Mike sagt:

        Auch in PCIe Slot 6 mit zwei CPUs aktiv tritt das Problem auf.
        Also liegt es an irgendeiner Kombination bezüglich Mainboard/Multiprocessor/NIC.

        Hat jemand Erfahrung bzgl. defekter CPU/Board in dieser Hinsicht? Oder Softwareprobleme?

  31. Mike sagt:

    Hallo!
    Gibt es noch jemand der diesen Artikel mit Interesse verfolgt?

    Es fehlt zwar noch der Langzeittest, aber bisher scheint es so, als hätte der Tausch von CPU2+Mainboard für Abhilfe gesorgt.
    Wenn dem so ist, wäre es zwar gut, dennoch ein total merkwürdiger Fehler und sehr schwer zu diagnostizieren.
    Wenn noch jemand weitere Infos zu diesem Thema mag, bitte um kurze Antwort.
    Demnächst mehr..

    • Mike sagt:

      Bisher stimmt mich alles zuversichtlich, der Langzeittest wird es zeigen.
      Ich bin sehr erfreut über die Hilfestellung und den unkomplizierten Hardwaretausch durch Fujitsu.
      Ich greife optimistisch mal vorweg (unter Vorbehalt des Langzeittests):
      Auch wenn solche Hardwarefehler natürlich nicht auftreten sollten, so hat der Tausch das Problem scheinbar behoben. Wegen der hohen Kosten für CPU2+Mainboard wäre es hier sonst zu einem Servertausch gekommen.
      Besonders hervorzuheben ist, dass es seitens Fujitsu kein Diskussionen und Verschiebungen der Zuständigkeiten z. B. auf die Softwareseite gab. Hier ist man oft anderes gewöhnt. Auch wenn der Server jetzt wohl – zum Glück – nicht sofort ersetzt werden muss, so kann ich ruhigen Gewissens wieder zu Fujitsu raten. Wäre es anders ausgegangen, wäre stets ein bitterer Beigeschmack geblieben – oder man hätte das Problem vielleicht sogar außerhalb der Garantie diagnostiziert und den Server somit entsorgen können.
      Es mag sicherlich einige Leser geben, die den Zeitaufwand (Kosten/Nutzen) bemängeln, aber im Endresultat – wenn es dabei bleibt – bin ich sehr zufrieden mit der Garantieabwicklung und Lösung.
      Trotzdem würde ich bei einem gleichartigen Problem jetzt viel eher einen kompletten Hardwaretausch in Erwägung ziehen, wenngleich die Eintrittswahrscheinlichkeit dieses Defektes sehr gering sein mag.
      Aber irgendwann kommt es immer mal zu seltenen Ereignissen.
      "Wenn du das Unmögliche ausgeschlossen hast, muss das, was übrig bleibt, die Wahrheit sein – wie unwahrscheinlich es auch ist"A.C.Doyle

  32. Achim sagt:

    Moin Mike,
    auf der Suche nach einer Lösung bei gleichem/ähnlichem Problem bin ich hier gelandet.
    Finde mich in deiner Fehlerbeschreibung wieder. Unterschied ist die Hardware und das BS:
    – Supermicro X11SCL-F
    – 1 x XEON E-2236
    – 64GB
    – Avago 9460 8i
    – Server 2022 aktueller Patchstand
    – 2 VMs 2022 (1 DC, 1 RDS)

    Problem mit dem Aufhängen tritt sporadisch alle 1 – 2 Tage ohne Zutun auf. Es gibt außerdem eine Synology die eine VM-Backup zieht. Und hiermit forciert man den Ausfall. Man bekommt kein Backup fertig, da er mittendrin stecken bleibt und keine externe LAN-Kommunikation mehr stattfindet. Erst eine Neustart per ICMP-Schnittstelle bringt das System wieder zum Laufen.
    Ich habe auch hierfür noch keine Lösung.
    Gruß, Achim

  33. Mike sagt:

    Hallo!

    Dies wird wahrscheinlich und hoffentlich der letzte finale Kommentar zu diesem Thema sein.

    Ich fasse zusammen:
    – Austausch von Mainboard + CPU2 hat geholfen (siehe oberes Post von mir).
    – QLogic statt Intel hat eher noch mehr Probleme verursacht.
    – Die Intel NIC ist weiterhin verbaut, auch wenn diese baugleich ebenfalls neu ist.

    Rat falls jemand dieses Problem hat:
    CPU2 bzw. 1 im Wechsel im BIOS deaktivieren und NIC umstecken um zu prüfen ob das Problem damit behoben ist.
    Falls ja CPU2 bzw. 1 und Mainboard ggf. tauschen.

    Natürlich ist dieses Problem sehr selten und nicht sehr wahrscheinlich.
    Weiterhin ist zu beachten, dass der Patchday das "DC Hang" Problem zusätzlich mit eingeführt hat.
    Somit war ein Softwareupdatefehler seitens MS und ein Hardwaredefekt zur nahezu gleichen Zeit das Problem.

    Weiterhin wurde die Gelegenheit genutzt alles mittels DISM/SFC zu bereinigen.
    Hierzu fand ich interessante berichte, um nicht erfolgreiche DISM wiederherstellungen selbst zu beheben. Hier mussten die CAB Update-Files manuell entpackt und verwendet werden.
    Eigentlich ein Vorgang, den Microsoft mittels Windows-Update selbst durchführen könnte…

    Und noch was zum Veeam Agent: Nach dem Mainboardtausch erkennt der Agent den vmHOST als neu, da die BIOS GUID sich verändert hat.
    Veeam zwingt einen dann dazu, den Host neu anzulegen. Eine leichtere Übernahme wäre hier wünschenswert und ist bei Veeam als Wunsch eingereicht.

    Wahrscheinlich werde ich in diesen Nachrichtenverlauf nicht mehr reinschauen.
    Wenn jemand etwas wichtiges hat, vielleicht einen Wink an den Webmaster zur Weiterleitung ;-)

    Weiterhin Danke für all die reichlichen Vorschläge zur Lösungsfindung!

    • Mike sagt:

      Nach fast einem Jahr läuft alles einwandfrei.
      Es gab hier auch scheinbar keinen neuen Kommentar zu der Sache.

      Vielleicht eine Angregung an Günter für einen Artikel:
      CPU Selektion nach der Produktion
      Erst wird produziert, dann wird mittels Tests festgestellt wie "gut" sie geworden ist. Danach wird dann "freigeschaltet", welche Bereiche benutzt werden. Scheinbar wurde hier entweder nicht gut getestet, oder es war zu grenzwertig bezüglich der Zuverlässigkeit, oder aber ein interner Defekt ist eingetreten. Ich denke den meisten Lesern sind solche Dinge nicht bewusst.
      Vielleicht will Günter hierzu mal ein kleines Fass aufmachen ;-)
      P.S. Auch der MS Cloud-Key-Datenschutzskandal wurde imho in der Presse total heruntergespielt, anstelle ihn als Super-GAU aufzuziehen um Cloud infrage zu stellen.
      (solche Artikel gibt es sicherlich schon, aber zu wenig präsent)

Schreibe einen Kommentar zu rpr Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.