ESX Host verliert Konfiguration

[rprengel]

Hallo,

ich habe in meinem IBM Balde das Problem das Blades sporadisch bei einem reboot die komplette Konfiguration verloren haben.
Gefunden habe ich:
https://blogs.itacs.de/Consulting/Lists ... f21d&ID=62
https://www.zeeb-network.com/wmware-esx ... ei-reboot/

Hat kemand weiter Tips was da ggf. passiert?
Wir nutzen das IBM ESX Image zum installieren und installieren auf Festplatten, nicht auf USB Sticks etc..

Gruss
Ralf

[JustMe]

Was genau bedeutet "verliert die Konfiguration"?

Gehen beim Reboot die Aenderungen seit dem letzten Start verloren, oder ist alles weg inkl. Kennwort usw.?

Gibt's vielleicht in vmkernel.log oder vmkwarning.log irgendwelche Hinweise zum Bootdatentraeger, so z.B. 1x pro Stunde? Werden ueberhaupt aktuelle Loginformationen geschrieben, und falls ja, wohin?

An was fuer einem "Controller" haengt die Bootfestplatte?

Ebenso waere "sporadisch" vielleicht ein wenig praeziser zu fassen...
- Tritt das Problem hauptsaechlich bei EINEM Blade auf, oder sind alle betroffen?
- Tritt das Problem 1x bei 1000 Reboots auf, oder eher 1x bei EINEM Reboot (je Blade gerechnet, selbstverstaendlich)?

[rprengel]

Was genau bedeutet "verliert die Konfiguration"?

Gehen beim Reboot die Aenderungen seit dem letzten Start verloren, oder ist alles weg inkl. Kennwort usw.?

Gibt's vielleicht in vmkernel.log oder vmkwarning.log irgendwelche Hinweise zum Bootdatentraeger, so z.B. 1x pro Stunde? Werden ueberhaupt aktuelle Loginformationen geschrieben, und falls ja, wohin?

An was fuer einem "Controller" haengt die Bootfestplatte?

Ebenso waere "sporadisch" vielleicht ein wenig praeziser zu fassen...
- Tritt das Problem hauptsaechlich bei EINEM Blade auf, oder sind alle betroffen?
- Tritt das Problem 1x bei 1000 Reboots auf, oder eher 1x bei EINEM Reboot (je Blade gerechnet, selbstverstaendlich)?

Hallo,
danke für die Rückfragen
1)
die komplette Konfiguration ist weg aber das Kennwort passt noch.
Die kompletten Konfigurationen wie z.B. Netzwerk, NFS Shares, ADS Server und registrierte VMs sind weg.
2)
Logfiles werde ich durchschauen
3)
Die Bootplatten sind aufd en Bladekarten direkt eingesetzt.
Den genauen Controller muss ich auslesen.
4)
Sporadisch meint das mein Kollege bei der Installation auch immer mal wieder bemerkte das seine Konfiguration bei einem reboot verloren gingen.
5)
Ich finde keine Einträge die besagen das die Konfiguration geschrieben wurde. Wie müsste so ein Eintrag im Logfile aussehen?
6)
Das Problem tauchte bisher nur imemr mal wieder aber verteilt auf alle Bladekarten auf.

Gruss

[rprengel]

Was genau bedeutet "verliert die Konfiguration"?

Gehen beim Reboot die Aenderungen seit dem letzten Start verloren, oder ist alles weg inkl. Kennwort usw.?

Gibt's vielleicht in vmkernel.log oder vmkwarning.log irgendwelche Hinweise zum Bootdatentraeger, so z.B. 1x pro Stunde? Werden ueberhaupt aktuelle Loginformationen geschrieben, und falls ja, wohin?

An was fuer einem "Controller" haengt die Bootfestplatte?

Ebenso waere "sporadisch" vielleicht ein wenig praeziser zu fassen...
- Tritt das Problem hauptsaechlich bei EINEM Blade auf, oder sind alle betroffen?
- Tritt das Problem 1x bei 1000 Reboots auf, oder eher 1x bei EINEM Reboot (je Blade gerechnet, selbstverstaendlich)?

Noch ein Nachtrag:
Es handelt sich um ein ausgesondertes Blade da ich jetzt in unserer Testumgebung nutze um Test-Vms zur betreiben. Also nichts unternehmenskrittisches sondern eher Resteverwertung.

Ich suche auch noch eine Seite mit IBM Updates fü ESX. Bisher habe ich nur die Seite mit den customized Isos gefunden.
Gruss

[rprengel]

Was genau bedeutet "verliert die Konfiguration"?

Gehen beim Reboot die Aenderungen seit dem letzten Start verloren, oder ist alles weg inkl. Kennwort usw.?

Gibt's vielleicht in vmkernel.log oder vmkwarning.log irgendwelche Hinweise zum Bootdatentraeger, so z.B. 1x pro Stunde? Werden ueberhaupt aktuelle Loginformationen geschrieben, und falls ja, wohin?

An was fuer einem "Controller" haengt die Bootfestplatte?

Ebenso waere "sporadisch" vielleicht ein wenig praeziser zu fassen...
- Tritt das Problem hauptsaechlich bei EINEM Blade auf, oder sind alle betroffen?
- Tritt das Problem 1x bei 1000 Reboots auf, oder eher 1x bei EINEM Reboot (je Blade gerechnet, selbstverstaendlich)?

Noch ein Nachtrag:
Es handelt sich um ein ausgesondertes Blade da ich jetzt in unserer Testumgebung nutze um Test-Vms zur betreiben. Also nichts unternehmenskrittisches sondern eher Resteverwertung.

Ich suche auch noch eine Seite mit IBM Updates fü ESX. Bisher habe ich nur die Seite mit den customized Isos gefunden.
Gruss

Nachtrag 2:
Ich hatte ein ähnliches Probelm schon früher das mir dann aber vom Zettel gerutscht ist:
http://vmware-forum.de/viewtopic.php?t=31321&highlight=
Ich werde das jetzt über die Tage erst mal systematisch untersuchen.
Im ersten Schritt installier ich mal mit einem Vmware-Standard-Iso.

Gruss

[JustMe]

Es handelt sich um ein ausgesondertes Blade

Ich bin jetzt nicht soo IBM-fest, aber bedeutet "Blade" hier ein einzelnes betroffenes ServerBlade neben weiteren fehlerfreien in einem gemeinsamen Chassis, oder ist hier mit "Blade" ein solches komplettes Chassis mit mehreren ServerBlades drin gemeint, die alle dasselbe Problem aufweisen?

Eine Meldung, dass die stuendliche Konfigsicherung erfolgreich war, faellt mir direkt jetzt so nicht ein. Aber Du kannst ja mal z.B. hier und hier schauen, wie das im Allgemeinen ablaeuft, und von Zeit zu Zeit mal pruefen, ob entweder die beschriebenen Dateien aktualisiert wurden, oder manuell das backup.sh anstossen.

Wenn aber Schreibfehler auftreten, sollten diese Fehler in den genannten Dateien vmkernel.log bzw. vmkwarning.log zu finden sein.

Ist es denn so, dass in der Tat eine Reihe von Reboots erfolgreich ablaufen ohne Konfigverlust, und dann irgendwann der Fehler unvermittelt zuschlaegt?

Je nach tatsaechlicher Ursache koennten sich evtl. auch Hinweise in der boot.gz auftreiben lassen, falls nicht das Konfigschreiben verantwortlich sein sollte, sondern das Konfiglesen beim Boot...

[rprengel]

Hallo,
danke für die Links.
Ich werde Montag berichten.
Jetzt ist erst mal Wochenende.

Gruss

[~thc]

Wenn jedenfalls - wie in deinem älteren Beitrag beschrieben - die Symlinks ins Leere zeigen, dann ist irgendwie das Bootmedium abgehängt und dann kann die Konfiguration auch nicht gespeichert werden.

[Dayworker]

So wie ich dich kenne, wirst du uns wohl wieder keine Logs anbieten können.
Wenn jedoch die Config zurückschreiben fehlschlägt, sollten sich Meldungen über einen nichtreagierenden Datenträger finden lassen. Wenn ich das, ohne direkt danach mal gesucht zu haben, richtig mitbekommen habe, taucht die Meldung über einen fehlerhaften Boot-Datenträger genau einmal auf und der ESXi speichert ab dann weder seine Config noch gibt er weitere Meldungen zu diesem Problem. Einen fehlender Boot-Datenträger läßt sich wohl auch daran festmachen, ob man noch die Tools installieren oder VMs in ihrer Config ändern kann.

[rprengel]

So wie ich dich kenne, wirst du uns wohl wieder keine Logs anbieten können.
Wenn jedoch die Config zurückschreiben fehlschlägt, sollten sich Meldungen über einen nichtreagierenden Datenträger finden lassen. Wenn ich das, ohne direkt danach mal gesucht zu haben, richtig mitbekommen habe, taucht die Meldung über einen fehlerhaften Boot-Datenträger genau einmal auf und der ESXi speichert ab dann weder seine Config noch gibt er weitere Meldungen zu diesem Problem. Einen fehlender Boot-Datenträger läßt sich wohl auch daran festmachen, ob man noch die Tools installieren oder VMs in ihrer Config ändern kann.

Yeap,
keine Logfliles.
Ich werde Montag auf einem System schauen ob das Sicherungsscript einen Fehler wirft.
Wenn das Blade mit der Origina-Iso Installation sauber läuft muss ich halt über die Tage mal fix alles umhängen. Die Vms laufen ja alle auf einem zentralen Storage.
Aus dem Zustand der Links und der Rückmeldung müsste man doch auch ein nettes Monitoring-Plugin bauen können um so Probleme ggf. sofort zu erkennen.
Gruss

[rprengel]

Wenn das Blade mit der Origina-Iso Installation sauber läuft muss ich halt über die Tage mal fix alles umhängen. Die Vms laufen ja alle auf einem zentralen Storage.
Aus dem Zustand der Links und der Rückmeldung müsste man doch auch ein nettes Monitoring-Plugin bauen können um so Probleme ggf. sofort zu erkennen.
Gruss

Tja,
aktuell ahbe ich wohl kein Blade mehr das ein Problem hat.

/bin # ./auto-backup.sh
/bin # echo $?
0
/bin #

sieht ja erst mal gut aus.
Ich werde mal schauen wie sich das darstellt wenn das Problem wieder auftaucht.

Gruss

[rprengel]

Wenn das Blade mit der Original-Iso Installation sauber läuft muss ich halt über die Tage mal fix alles umhängen. Die Vms laufen ja alle auf einem zentralen Storage.
Aus dem Zustand der Links und der Rückmeldung müsste man doch auch ein nettes Monitoring-Plugin bauen können um so Probleme ggf. sofort zu erkennen.
Gruss

Tja,
aktuell ahbe ich wohl kein Blade mehr das ein Problem hat.

/bin # ./auto-backup.sh
/bin # echo $?
0
/bin #

sieht ja erst mal gut aus.
Ich werde mal schauen wie sich das darstellt wenn das Problem wieder auftaucht.

Gruss

Ok,
das Problem wird schräg.
Auf meinem neu aus dem Original-Iso installierten Blade sind unter /var die Links auf /scratch/core und /scratch/var/tmp rot, also defekt. Die anderen Ordner sind ok. Auf anderen PCs mit ESX ist die Installation auch ok.
Ich spiele auf dem Blade jetzt mal alle aktuellen Patches ein.
Gruss

Nachtrag:
Reboot Testbalde mit aktuellesten Updates, alle Ornder unter /var/ und /var/log sind da. Ich werde jetzt die Karte mehrfach booten und mal mit ein paar Systemen unter Last setzen.

Gruss

[rprengel]

Wenn das Blade mit der Original-Iso Installation sauber läuft muss ich halt über die Tage mal fix alles umhängen. Die Vms laufen ja alle auf einem zentralen Storage.
Aus dem Zustand der Links und der Rückmeldung müsste man doch auch ein nettes Monitoring-Plugin bauen können um so Probleme ggf. sofort zu erkennen.
Gruss

Tja,
aktuell ahbe ich wohl kein Blade mehr das ein Problem hat.

/bin # ./auto-backup.sh
/bin # echo $?
0
/bin #

sieht ja erst mal gut aus.
Ich werde mal schauen wie sich das darstellt wenn das Problem wieder auftaucht.

Gruss

Ok,
das Problem wird schräg.
Auf meinem neu aus dem Original-Iso installierten Blade sind unter /var die Links auf /scratch/core und /scratch/var/tmp rot, also defekt. Die anderen Ordner sind ok. Auf anderen PCs mit ESX ist die Installation auch ok.
Ich spiele auf dem Blade jetzt mal alle aktuellen Patches ein.
Gruss

Nachtrag:
Reboot Testbalde mit aktuellesten Updates, alle Ornder unter /var/ und /var/log sind da. Ich werde jetzt die Karte mehrfach booten und mal mit ein paar Systemen unter Last setzen.

Nachtrag 2
Im Logfile sehe ich das nach einiger Zeit zu vollen Stunde die bootbank nicht mehr erreichbar ist.

Nachtrag 3
https://www-947.ibm.com/support/entry/p ... gr-5094127
mal schauen ob das eine Spur wird.

Gruss

[rprengel]

Wenn das Blade mit der Original-Iso Installation sauber läuft muss ich halt über die Tage mal fix alles umhängen. Die Vms laufen ja alle auf einem zentralen Storage.
Aus dem Zustand der Links und der Rückmeldung müsste man doch auch ein nettes Monitoring-Plugin bauen können um so Probleme ggf. sofort zu erkennen.
Gruss

Tja,
aktuell ahbe ich wohl kein Blade mehr das ein Problem hat.

/bin # ./auto-backup.sh
/bin # echo $?
0
/bin #

sieht ja erst mal gut aus.
Ich werde mal schauen wie sich das darstellt wenn das Problem wieder auftaucht.

Gruss

Ok,
das Problem wird schräg.
Auf meinem neu aus dem Original-Iso installierten Blade sind unter /var die Links auf /scratch/core und /scratch/var/tmp rot, also defekt. Die anderen Ordner sind ok. Auf anderen PCs mit ESX ist die Installation auch ok.
Ich spiele auf dem Blade jetzt mal alle aktuellen Patches ein.
Gruss

Nachtrag:
Reboot Testbalde mit aktuellesten Updates, alle Ornder unter /var/ und /var/log sind da. Ich werde jetzt die Karte mehrfach booten und mal mit ein paar Systemen unter Last setzen.

Nachtrag 2
Im Logfile sehe ich das nach einiger Zeit zu vollen Stunde die bootbank nicht mehr erreichbar ist.

Nachtrag 3
https://www-947.ibm.com/support/entry/p ... gr-5094127
mal schauen ob das eine Spur wird.

Gruss

Tja,
ESX 6 hat das gleiche Problem.

[JustMe]

Trotz der vielen verschlungene Quotes bist Du uns die Antwort auf die Frage nach dem genauen Controller-Typ noch immer schuldig...

Im anderen Thread erwaehntest Du mal

Code: Alles auswählen

eigene Sata-Platte auf ser Blade-Karte fürs System.

Hast Du mal geschaut, ob die Platte vielleicht langsam den Geist aufgibt? (Thema: Smartinfo)
Oder mal eine andere eingebaut?

Gibt's vielleicht Firmware-Updates fuer die IBM-Blades, die noch nicht eingesetzt sind?

PS:

Im Logfile sehe ich das nach einiger Zeit zu vollen Stunde die bootbank nicht mehr erreichbar ist.

Im anderen Thread hatte ~thc genau dieses doch schon vermutet...

[rprengel]

Trotz der vielen verschlungene Quotes bist Du uns die Antwort auf die Frage nach dem genauen Controller-Typ noch immer schuldig...

Im anderen Thread erwaehntest Du mal

Code: Alles auswählen

eigene Sata-Platte auf ser Blade-Karte fürs System.

Hast Du mal geschaut, ob die Platte vielleicht langsam den Geist aufgibt? (Thema: Smartinfo)
Oder mal eine andere eingebaut?

Gibt's vielleicht Firmware-Updates fuer die IBM-Blades, die noch nicht eingesetzt sind?

PS:

Im Logfile sehe ich das nach einiger Zeit zu vollen Stunde die bootbank nicht mehr erreichbar ist.

Im anderen Thread hatte ~thc genau dieses doch schon vermutet...

Hallo,

die Platten sind neu.
Ich wühle mich gerade durch die sehr lange und unübersichtliche Liste von Updates bei IBM. Das Problem taucht auf allen Blades in allen Slots auf.

Hier die IDs
Machine Type/Model: 88524YG
BLADE (HS21 XM (Type 7995))

Gruss

[rprengel]

Trotz der vielen verschlungene Quotes bist Du uns die Antwort auf die Frage nach dem genauen Controller-Typ noch immer schuldig...

Im anderen Thread erwaehntest Du mal

Code: Alles auswählen

eigene Sata-Platte auf ser Blade-Karte fürs System.

Hast Du mal geschaut, ob die Platte vielleicht langsam den Geist aufgibt? (Thema: Smartinfo)
Oder mal eine andere eingebaut?

Gibt's vielleicht Firmware-Updates fuer die IBM-Blades, die noch nicht eingesetzt sind?

PS:

Im Logfile sehe ich das nach einiger Zeit zu vollen Stunde die bootbank nicht mehr erreichbar ist.

Im anderen Thread hatte ~thc genau dieses doch schon vermutet...

Hallo,

die Platten sind neu.
Ich wühle mich gerade durch die sehr lange und unübersichtliche Liste von Updates bei IBM. Das Problem taucht auf allen Blades in allen Slots auf.

Hier die IDs
Machine Type/Model: 88524YG
BLADE (HS21 XM (Type 7995))

Gruss

Ich habe jetzt auf einem Blade einen anderen Festplattentyp verbaut.
Zumindestestens in den letzten 30 Minuten ist noch nichts passiert.
Gruss

[Dayworker]

Soweit mir bekannt ist, führt auch IBM eine HW-Kompatibililililitätsliste. Von der Warte muß die Platte nicht mal SMARTINFO-technisch ihren Geist aufgegeben haben...

[rprengel]

Soweit mir bekannt ist, führt auch IBM eine HW-Kompatibililililitätsliste. Von der Warte muß die Platte nicht mal SMARTINFO-technisch ihren Geist aufgegeben haben...

Hallo,
ist halt Resteverwertung. Wenn die Platten einfach inkompatibel sind soll mir das recht sein. Neue Platten 2,5 Zoll 250 GB kosten nicht die Welt.

Gruss

[Dayworker]

Das mit der Resteverwertung war mir aufgrund aller bisherigen Postings schon klar.

[rprengel]

Das mit der Resteverwertung war mir aufgrund aller bisherigen Postings schon klar.

Gut.
Und nein ich schaue heute nicht mehr per VPN nach ob die andere Platte noch sauber läuft. Es juckt schon in den Fingern aber irgendwann ist auch mal gut.
Gruss

[rprengel]

Das mit der Resteverwertung war mir aufgrund aller bisherigen Postings schon klar.

Gut.
Und nein ich schaue heute nicht mehr per VPN nach ob die andere Platte noch sauber läuft. Es juckt schon in den Fingern aber irgendwann ist auch mal gut.
Gruss

Ok,
Stand 06:00 der Fehler der sonst nach Minuten schon da war ist bisher nicht zu sehen.
Alle Ordner sind noch da.
Ich werde jetzt einige Testsysteme auf das Blade ziehen und mal Last auf das System erzeugen. Aber das sieht erst mal gut aus.

[Dayworker]

Ich bewundere ja immer wieder, wieviel Engagement du an den Tag legst, damit du irgendwelche HW weiternutzen kannst.

[rprengel]

Ich bewundere ja immer wieder, wieviel Engagement du an den Tag legst, damit du irgendwelche HW weiternutzen kannst.

Hallo,
im Center stecken 7 Karten mit 40 bis 96 GB Ram.
Das wirft man mal nicht eben alles weg. Unsere Tester und Entwickler die auf Datenbanken entwickeln brauchen nicht wirklich Perfomance aber RAM und Plattenplatz.
Abgesehen davon ist es für die Geschäftszahlen nicht schädlich altes Material weiter zu verwenden und meine Prämien hängen nicht unerheblich an dem was wir unter dem Strich erwirtschaften.
Weiter macht es ja auch Spass und bei 150 VMs kann man eine Menge mit Monitoring und automatisierter Installation "spielen" .
Jetzt geht es bis 12.00 noch mal an die Schaufel.
Gruss und ruhige Tage bzw. schöne Weihnachten.

Ralf

[rprengel]

Ich bewundere ja immer wieder, wieviel Engagement du an den Tag legst, damit du irgendwelche HW weiternutzen kannst.

Hallo,
im Center stecken 7 Karten mit 40 bis 96 GB Ram.
Das wirft man mal nicht eben alles weg. Unsere Tester und Entwickler die auf Datenbanken entwickeln brauchen nicht wirklich Perfomance aber RAM und Plattenplatz.
Abgesehen davon ist es für die Geschäftszahlen nicht schädlich altes Material weiter zu verwenden und meine Prämien hängen nicht unerheblich an dem was wir unter dem Strich erwirtschaften.
Weiter macht es ja auch Spass und bei 150 VMs kann man eine Menge mit Monitoring und automatisierter Installation "spielen" .
Jetzt geht es bis 12.00 noch mal an die Schaufel.
Gruss und ruhige Tage bzw. schöne Weihnachten.

Ralf

Hallo,
die Bladekarte mit der anderen Festplatte hat bis jetzt keine Verzeichnisse verloren.
Ich habe in einer alten inaktiven Qnap ss-839 noch 2.5 Zool Platten.
Mit etwas Glück sind die Platten geeignet.
Gruss