VMware-Forum

Moin,

wir haben 3 Windows Server 2016 mit jeweils Exchange 2016 installiert.
Diese laufen zusammen mit rund 60 anderen Windows & Linux VMs auf unserem VMWare vSphere 6.5 Cluster (bestehend aus 4 Hosts und als Storage betreiben wir vSAN)

Nun haben mir NUR mit den 3 Exchange Servern das Problem das sie in der letzten zeit mind. einmal durch einen Fehler neugestartet sind.
Den MINIDUMP habe ich natürlich ausgewertet, daraus geht nur folgendes hervor:



Wie gesagt auf allen 3 Servern das selbe, alle anderen laufen Problemlos... nun habe ich in die logs der VM geschaut, dort steht folgendes...
Das seltsame ist, stunden davor wurde nix geloggt....



Der letzte Logeintrag vor ist:


Ich habe grade keine Idee wonach ich noch schauen kann um die Ursache zu beheben ... Noch jemand eine Idee für mich?

edit: angepasst, falsche uhrzeit geschaut daher falsche logs kopier ....


Gruß
Tobias

Genau das ist das Problem mit gekürzten Logs. Wenn ich nämlich nach "WinBSOD: Synthetic MSR[0x40000103]" suche, lande ich unter anderem im VMTN-Thread WinBSOD Code decipher und dieser offenbart ein fehlschlagendes CPU-Microcodeupdate. Sieht für mich danach aus, daß die Win-Server bezüglich Meltdown & Spectre aktiv werden und die entsprechenden M$-Updates ausrollen.



[edit]
Falls ich damit Recht habe, hat "mbreidenbach" im Thread Massive-Luecke-in-Intel-CPUs-erfordert-umfassende-Patche bereit seinen Weg für Winserver2k12R2 beschrieben.

mhhh das war auch einer meiner gedanken ... aber von Microcode steht im log nix. Würde mich bei den Zeiten auch wundern, da wir Updates manuell einspielen und nicht automatisch installieren lassen....

Auffallend ist halt die Lücke in den logs, die sich übrigens auch in den Windows Logs wiederspiegelt.

Ich hab das log mal von 2 der betroffenen Server bei uns hochgeladen, ist leider zu groß für PasteBin oder für einen Anhang:
Server 1: https://cloud.bs.fraunhofer.de/index.ph ... adcDL5KcSf
Server 2: https://cloud.bs.fraunhofer.de/index.ph ... nYz4MWtTzF


Bei beiden treten die WinBSOD Fehler auf, bei Server 2 sogar mehrfach.

Zuerst einmal: Solche (Text-)Log-Dateien lassen sich vortrefflich komprimieren. Dann klappt's auch mit dem hoch- (und runter-) laden besser. Z.B. mit Info-ZIP 3.0 verbleiben dann nur noch 3.637.722 Bytes statt 38.799.651 zu transferieren.

Dann:
Die Nummern in Klammern hinter "MSR" sind wohl nur Index-Nummern des Registers. Erst die Werte RECHTS der schliessenden Klammer werden interessant. Und da ist im VMTN-Artikel von einem Stop 0x9E zu lesen, waehrend hier (immer wieder, wie bereits angemerkt) ein Stop 0x1A auftritt.

Was mir persoenlich auffaellt ist, dass die VM-Abstuerze alle auf "vSphere-02" passieren. Kannst Du das mal mit den anderen evtl. vorliegenden Faellen verifizieren?

Wegen der indizierten Memory_Management Problematik wuerde ich deshalb vielleicht auch mal die HW-Logs dieses Hosts pruefen.

Dann bin ich etwas erstaunt, dass der abgebende Host 192.168.10.14 am 2017-10-26T08:38:33.782Z noch Build 6765664 hatte, aber um 15:48:52.255Z auf Build 7388607 lief. Habt Ihr da automatische Updates konfiguriert? Falls ja, und auch sonst: Warum laeuft der vSAN-Member vSphere-02 am 30.3. immer noch mit dem alten Build?

Ich bin noch nicht wirklich dazu gekommen, mir die Logs umfassend anzusehen, aber zur Upload-Funktion muß ich ein paar Worte verlieren und daher:


Der Upload ist auf wenige Dateiformate, eine bestimmte Dateigrösse und ausserdem auf eine maximale Anzahl von Dateianhängen beschränkt. Die momentan konfigurierte, maximal zulässige Grösse ist in meiner Signatur ersichtlich und somit deutlich kleiner als das komprimierte Log-2.
Mir sind ehrlich gesagt externe Verlinkungen weiterhin lieber, als die Uploads hier im Forum, weil die Daten dann gefühlt weiter unter alleiniger Kontrolle des Uploaders bleiben und auch der Platzverbrauch bzw genauer der Freie Speicherplatz auf dem Server irrelevant ist. Falls man zudem auch noch an anderen Stellen nachfragt, spart man sich weitere Uploads und nicht nur ich habe vermutlich meine Uploads gerne alle an einer Stelle beisammen.

JustMe hat geschrieben:Dann:
Die Nummern in Klammern hinter "MSR" sind wohl nur Index-Nummern des Registers. Erst die Werte RECHTS der schliessenden Klammer werden interessant. Und da ist im VMTN-Artikel von einem Stop 0x9E zu lesen, waehrend hier (immer wieder, wie bereits angemerkt) ein Stop 0x1A auftritt.

Was mir persoenlich auffaellt ist, dass die VM-Abstuerze alle auf "vSphere-02" passieren. Kannst Du das mal mit den anderen evtl. vorliegenden Faellen verifizieren?

Alle 3 Exchange laufen auf vSphere-02 (unglücklich und sollte so eigentlich auch nicht sein)... Aber es laufen noch zahlreiche andere VMs auf diesem Host die keine Probleme machen.

Wegen der indizierten Memory_Management Problematik wuerde ich deshalb vielleicht auch mal die HW-Logs dieses Hosts pruefen.

Leider existieren von dem Datum keine VMkernel Logs mehr ....

JustMe hat geschrieben:Dann bin ich etwas erstaunt, dass der abgebende Host 192.168.10.14 am 2017-10-26T08:38:33.782Z noch Build 6765664 hatte, aber um 15:48:52.255Z auf Build 7388607 lief. Habt Ihr da automatische Updates konfiguriert? Falls ja, und auch sonst: Warum laeuft der vSAN-Member vSphere-02 am 30.3. immer noch mit dem alten Build?

Wir haben angefangen die Hosts zu patchen, dabei sind jedoch bei manchen Hosts Probleme mit dem UpdateManager aufgetreten. Dazu ist aktuell noch ein Fall bei VMware Offen... daher die unterschiedlichen Stände.

Wenn ihr eh schon einen Case bei VMware offen habt, würde ich die Reboots auch dem Support vor die Füsse werfen und dabei erwähnen, daß bei Euch die Produktion stillsteht. Des weiteren dürfte es sehr hilfreich sein, alle unternommenen Schritte schriftlich zu dokumentieren.

joa ich bin zwar kein Fan vom VMware Support aber ich hab da bereits ein Case aufgemacht...
allerdings nicht als komplett crash da ich über die Ostertage nicht sicherstellen kann das ich immer telefonisch erreichbar bin

Die Exchange Server haben wir die Woche wieder zusammengeflickt .... die haben durch die Fehler ziemlich gelitten und mochten ihre Datenbanken nicht mehr

Sorry, kleiner Interpretationsfehler meinerseits: Der 192.168.10.14 hatte im Oktober letzten Jahres (!) noch die alte Version. Aber der "DAG-01" ist laut Log (auch?) am 26.03.2018 von diesem Host gekommen.

Dann eine kleine Korrektur in der anderen Richtung: mit "HW-Logs" sind NICHT die vmkernel.logs gemient, sondern (H)ard(w)are Logs.
Das aber nur pro forma; ein echter Hinweis in dieser Richtung ist das "Memory Management" Problem im Windows des Gastes eigentlich nicht.

Drei Knoten einer Exchange DAG auf einem einzelnen Host, und dann auch noch ein vSAN darunter? Ihr muesst echt einen sehr guten Draht zu Eurer bevorzugten Gottheit unterhalten...

Oder die Group erstreckt sich noch auf etliche weitere Lokationen, und dann ware die Frage, wo ueberall genau die Abstuerze zu sehen sind bzw. waren.

Der Support von VMware wird hier vmtl. nur erst einmal auf die Best Practices verweisen

PS: Und das ist die Bestaetigung des obig geschriebenen

JustMe hat geschrieben:Sorry, kleiner Interpretationsfehler meinerseits: Der 192.168.10.14 hatte im Oktober letzten Jahres (!) noch die alte Version. Aber der "DAG-01" ist laut Log (auch?) am 26.03.2018 von diesem Host gekommen.

Dann eine kleine Korrektur in der anderen Richtung: mit "HW-Logs" sind NICHT die vmkernel.logs gemient, sondern (H)ard(w)are Logs.
Das aber nur pro forma; ein echter Hinweis in dieser Richtung ist das "Memory Management" Problem im Windows des Gastes eigentlich nicht.

Also die Hardware Logs sind sauber, da ist nix drin.

JustMe hat geschrieben:Drei Knoten einer Exchange DAG auf einem einzelnen Host, und dann auch noch ein vSAN darunter? Ihr muesst echt einen sehr guten Draht zu Eurer bevorzugten Gottheit unterhalten...

Oder die Group erstreckt sich noch auf etliche weitere Lokationen, und dann ware die Frage, wo ueberall genau die Abstuerze zu sehen sind bzw. waren.

Wir haben 2 Cluster, ein vSAN Cluster und dann noch ein Cluster mit iSCSI Storage.
Der Plan ist eigentlich das mind. ein DAG Knoten auch auf dem iSCSI Cluster laufen soll.
Da haben wir grade eine Storage Erweiterung bekommen damit ein Exchange dort noch ein Plätzchen bekommt
Das aktuell alle Exchange auf einem Host laufen ist nicht beabsichtigt... da hat scheinbar jemand nicht aufgepasst

Das klingt so als wenn du von vSAN nicht so angetan bist

Mr.Schrotti hat geschrieben:Das klingt so als wenn du von vSAN nicht so angetan bist

Das dürfte weniger mit dem Produkt an sich sondern viel eher mit der eigentlich - sorry klingt hart - unsinnigen Ausrollung zu tun haben.

Exchange mit mehreren DAG's ist gemacht für eine Verteilung auf möglichst unabhängige Hardware mit gleichem Datenstand. vSAN macht - im weitesten Sinne - ungefähr das gleiche wenn auch auf eine andere Art und auf einer anderen Ebene. Damit es stimmig wäre, müsste pro DAG ein eigenes vSAN her.

Fazit: Du nimmst eine komplexe Technologie zur Auftrennung der Abhängigkeiten von gemeinsamer Hardware (DAG), führst den Kram auf Dateisystemebene mit einer zweiten sehr komplexen Technolgie wieder zusammen (vSAN) diese wiederum verteilt ihre Daten auf mehrere Hosts. Das ganze komplettierst Du mit einer weiteren komplexen Technologie - der Virtualisierung - auf dem gleichen Host.