moin, am wochenende hat einer unserer esx server (hp dl 380g5) einen reboot ausgelöst. gottseidank war zu dem zeitpunkt keine vm auf ihm aktiv.
ein hardwaredefekt ist nicht zu erkennen. die hp insight management seite sagt, das ein automatischer reboot durchs asr ausgelöst wurde.
hier noch etwas zum asr:
http://kb.vmware.com/selfservice/micros ... Id=1010842
habt ihr asr aktiv? oder deaktiviert?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
jemand erfahrung mit asr (automatic system recovery) von hp?
Hihi der KB reflektiert den Glaubenskrieg darüber. ASR funktioniert über HP IPMI Treiber, den nativen Watchdog Timer Funktionen des OS und der ILO (aufgebohrter IPMI CHIP).
Das Ding ist ein Teufelchen was munter rückwärts zählt und bei 0 den Reset Knopf drückt - ob es zu schnell runtergezählt hat - oder die Situation sich selbst repariert hätte weis man nie so recht. Der Treiber kann genauso sich weghängen ohne das der Hypervisor aufhört zu funktionieren.
Wie die Römer sagen "panta rei" - alles fliest - und so schwankt auch die Rate in der ein ASR ein "false positive" ist über verschiedene HP Agenten, ESX Kernel und ILO2 FW Versionen.
Wenn man jetzt überlegt was ein ASR abfangen soll dann kommt man leicht zu einer Entscheidung :
- einfrierende Systeme
- PSODs
Beides sind in ESX Versionen recht selten und man will den PSODs sehr schnell auf die Schliche kommen. Also lässt man ASR aus - bis man wirklich mit einer PR Nummer bis zum nächsten Patchrelease in der Luft hängt und ständig mit PSODs rechnen muss oder bis seine HW "gereift" ist und man lieber sich gegen einen vergessenen Hänger absichert - man weis das man mit der jetzigen Build zufrieden sein kann und das Firmware mässig nichts mehr zu erwarten ist.
Auf Windows Systemen mit NOCH mehr Parteien die ständig Treiber nachliefern macht der ASR mehr Sinn - ABER Windows hat seit 2003 sein eigenes ASR Feature und würde jeden BSOD vernünftig abfangen, also ASR beim ersten Bluescreen ausschalten und nach beheben desjenigen wieder an um ggf einen Freeze abfangen zu können.
Übrigends bei installierten Agenten auf ESX kann man den ASR live deaktivieren per "hplog -a DISABLE" und mit "hplog -a STATUS" prüfen.
Das Ding ist ein Teufelchen was munter rückwärts zählt und bei 0 den Reset Knopf drückt - ob es zu schnell runtergezählt hat - oder die Situation sich selbst repariert hätte weis man nie so recht. Der Treiber kann genauso sich weghängen ohne das der Hypervisor aufhört zu funktionieren.
Wie die Römer sagen "panta rei" - alles fliest - und so schwankt auch die Rate in der ein ASR ein "false positive" ist über verschiedene HP Agenten, ESX Kernel und ILO2 FW Versionen.
Wenn man jetzt überlegt was ein ASR abfangen soll dann kommt man leicht zu einer Entscheidung :
- einfrierende Systeme
- PSODs
Beides sind in ESX Versionen recht selten und man will den PSODs sehr schnell auf die Schliche kommen. Also lässt man ASR aus - bis man wirklich mit einer PR Nummer bis zum nächsten Patchrelease in der Luft hängt und ständig mit PSODs rechnen muss oder bis seine HW "gereift" ist und man lieber sich gegen einen vergessenen Hänger absichert - man weis das man mit der jetzigen Build zufrieden sein kann und das Firmware mässig nichts mehr zu erwarten ist.
Auf Windows Systemen mit NOCH mehr Parteien die ständig Treiber nachliefern macht der ASR mehr Sinn - ABER Windows hat seit 2003 sein eigenes ASR Feature und würde jeden BSOD vernünftig abfangen, also ASR beim ersten Bluescreen ausschalten und nach beheben desjenigen wieder an um ggf einen Freeze abfangen zu können.
Übrigends bei installierten Agenten auf ESX kann man den ASR live deaktivieren per "hplog -a DISABLE" und mit "hplog -a STATUS" prüfen.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 11 Gäste