mal wieder purple Screen

[lord_icon]

Moin,

mein neu aufgebauter Backup-Server hat sich mal wieder mit ein Lila-Screen verabschiedet.



So ganz schlau werde ich aber nicht aus diesen Output.
In Zeile 3 auf CPU11 wir eine meiner VM's aufgeführt (PRTG Backup_Server)
Ist das die VM die dieses Problem verursacht ?

Ich hatte mal ne Zeitlang einen Fehler direkt in vSphere Client angezeigt bekommen:
https://kb.vmware.com/selfservice/micro ... Id=2036543

Ich hab darauf hin aber die Kiste mit der neusten ESXi Version aufgesetzt... dann wurde dieser Fehler nicht mehr angezeigt.
Aber da im aktuellen Screen wieder CPU Meldungen auftauchen bin ich mir nicht ganz sicher, ob der Fehler nicht immer noch zugrunde liegt.

Welche Datei sollte ich mir denn mal runterziehen um den Fehler näher einzugrenzen ?

Danke

[Dayworker]

Wenn ich mir da Build numbers and versions of VMware ESXi/ESX (2143832) ansehe, ist das Build nicht die neueste Version. Die Frage ist jetzt, ob es noch Sinn macht, in dem älteren Build nach einer Lösung zu suchen. Deine VMware-KB paßt in meinen Augen leider nicht zu dem Problem, aber vielleicht hängt dein Problem auch mit der Meldung zum "image profile bypassing and acceptance level verification" zusammen.


[add]
Läuft der ESXi eigentlich auf dafür freigegebener HW oder ist das eine White-Box?

[JustMe]

Ich persoenlich denke mal, dass der aktuelle PSoD schon zu dem "aelteren" passt.

In meinen Augen das Entscheidende ist (neben der Build-Version) die zweite Zeile mit dem Hinweis bora/vmkernel/hardware/mce.c
Das duerfte der Machine Check Exception Handler sein, was auch bei "Recursive Panic on same CPU" mal vorkommt.

Somit ist auf jeden Fall Dayworker's Frage nach der Hardware zu beantworten, sowie natuerlich, ob diese Hardware erfolgreich gecheckt wurde.

Die *PCPU-Zeile mit Deiner PRTG-VM zeigt jedenfalls nur, auf welchem PCPU-Kern der MCE registriert wurde. Und dass die VM mit mindestens 4 vCPU konfiguriert ist.

Was genau bedeutet in diesem Zusammenhang "Backup-Server"? Dient der als Backup fuer einen anderen, produktiven? Oder fuehrt der Backup-Funktionen aus; womoeglich mit an VMs durchgereichter Hardware? Steht das PRTG fuer die Netzwerk Monitoring Software?

[lord_icon]

@Dayworker... ok. müsste ich mal checken. Ich hab das Ding kürzlich erst aufgesetzt. Da hab ich mir das image von VMWare runtergeladen.
Aktuell hab ich noch 41 Tage Testzeitraum. Muß wohl dann schon wieder ein neues Build drauss sein. Schau ich mir morgen mal an.

Nein. Keine zert. HW.
MB: X9DB3/iF
CPU: 2 x E5-2440
Raid: von Adaptec

ABER: Wenn es ein Backup-Server gibt, dann gibt es auch ein Main-Server
Und der hat genau das gleiche drin. Unterschied hier: Der RAM ist von einer anderen Firma.
Auch die ESXi Version (3620759) ist identisch. Und die Kiste hat kein Problem.

@JustMe
Backup-Server / Spielwiese. Ich will n bissel mit FT und so rumspielen. Drum hatte ich mir den gleichen Server nochmal zusammengestellt.
Produktiv ist der aktuell nicht wirklich... könnte diesen aber dringends gebrauchen, da mein RZ die IP Kreise ändert. Da muss ich auch noch sehn, wie ich das hinbekomme (aber das werd ich morgen versuhen rauszubekommen und ggf. in einen anderen Thread behandeln)

ICh hab mir unmittelbar nach den Ausfall (+reboot) die Logs über den vSphere gesichert. Sind gleich mal 331 MB (tgz).
In var/run/lo hab ich ja eeeeeeetliche Logs drin. Schafft esxi das beim Absturz überhaupt noch zu Protokollieren?
ICh poste mal die beiden errors aus der vpxa.log VOR dem Absturz. Die anderen Zeilen sind nur infos + verbose Meldunge


Auszug:

Code: Alles auswählen

2016-11-12T15:56:50.321Z error vpxa[FFDCDB70] [Originator@6876 sub=vpxaVmomi opID=HostSync-host-2089-af6a05e-ba] [VpxaClientAdapter::InvokeCommon] Re-throwing method-fault 'N3Vim5Fault13TooManyWrites9ExceptionE(vim.fault.TooManyWrites)' received while invoking syncConfiguration on vim.host.FirmwareSystem:ha-firmwareSystem

2016-11-12T15:56:50.321Z error vpxa[FFDCDB70] [Originator@6876 sub=vpxaInvtHost opID=HostSync-host-2089-af6a05e-ba] [VpxaInvtHost] Error syncing firmware configuration: N3Vim5Fault13TooManyWrites9ExceptionE(vim.fault.TooManyWrites)


[JustMe]

vpxa ist ja "nur" der Management Agent; in diesem Falle ist vmtl. das vmkernel.log interessanter.
Und den groessten Teil der MB macht wahrscheinlich ein Dump in var/core/ aus. Der wird uebrigens erst beim Wiederanlauf aus der dafuer reservierten Partition geladen.

Und dann: FT auf nicht unterstuetzter Hardware? Naja...

Kannst Du die Hardware mal ein wenig ESXi-unabhaengig stressen? So mit Prime95, Memory-Test, etc.pp.