HOST für 20 sek. weg, wo nachschauen?

[mangold]

moin,
ich weiß nicht ob es eigentlich ein VC oder ein ESX Problem ist, tippe aber auf den Host...
Unser VC verliert immer wieder mal die Verbindung zu einem unserer Hosts (von insgesamt neun Stück), der Verbindungsabbruch dauert lt. VCenter 10 bis max. 20 Sekunden. Dabei laufen die VMs weiter. nach 20 Sek. ist der Spuk dann wieder vorbei.

Nun suche ich nach der Ursache, das vCenter Log ist leider extrem unergiebig. In den Logs auf dem Host kann ich aber auch nichts erkennen. Welche sind denn genau die lokalen Logs, die ich durchforsten sollte?

/var/log/messages - nichts
vmkernel - nichts
vmkwarning - nichts
hostd-1.log - nichts

habe ich noch irgendwelche Logs übersehen, die hilfreich sein könnten?

Netzwerkprobleme schließe ich auch aus, die Console hängt an einem separaten vSwitch mit zwei pNics an 2 verschiedenen pSwitchen. Die NICs versorgen ausschließlich die Console, vm und vmotion Netzwerk laufen über separate dedizierte nics.

Fünf weitere Hosts hängen identisch konfiguriert am selben Netzwerk ohne diese Erscheinungen.

[UrsDerBär]

Ist es möglich, dass einer der Nics probleme macht? Kannst ja mal einen um den anderen deaktivieren und ne weile gucken obs mit beiden klappert. Müsste zwar wohl in den Logs erscheinen, aber ein versuch isses ja wert.

[mangold]

der Gedanke ist mir auch schon gekommen! Wobei nichts auf defekte Netzwerkkarten hindeutet, nichts davon zu sehen, dass eine einzelne NIC den Link verliert, auch nicht aus dem Netzwerk Bereich. Ausserdem sollte das Teaming das ja abfangen...

Hab schon eine der NICs auf Standby geschickt, falls es generell mit dem Teaming Probleme gibt (inkompatible Treiber) aber das hat auch nichts gebracht.

Wär ja interessant zu wissen WO bzw. in welchen LOGs ausser der schon oben erwähnten man noch nachschauen könnte, viell. ist mir ja nur etwas entgangen.

[Tschoergez]

beobachte doch mal mit top auf der console, ob evtl. prozesse da für hohe auslastung sorgen, dass er ESX zwar erreichbar, aber nicht schnell genug beim antworten ist.

Im vmkernel-log, siehst Du, wenn eine der Nics nen link verliert. Wenns aber im Switch probleme gibt (evtl. wegen unpassender Spanning-Tree-Einstellungen oder so), dann kriegt das der ESX nicht mit.

Lass doch auch mal nen ping auf die service console nebenher laufen....

viele grüße,
jörg

[mangold]

guter Ansatz, leider tritt das Problem selten auf und meistens dann, wenn man es nicht erwartet, z.B. Nachts

[Tschoergez]

zu ner regelmäßigen Uhrzeit? Dann wäre evtl. ein Backup-Agent in der Service Console der hauptverdächtige...

Du kannst auch mal schauen, ob irgendwelche cron-jobs evtl. Probleme machen, oder der logrotate beim rotieren der logdateien für "Schluckauf" sorgt.

viele grüße,
jörg

[mangold]

Backup Agent hatte ich auch gedacht, habe aber schon verglichen, konnte keinen zeitlichen Zusammenhang erkennen, nicht in einem einzigen Fall. Ausserdem erklärt es nicht, warum es i.d.R. nur mit diesem einen Host passiert. I.D.R. bedeutet, dass ich das auf zwei weiteren Host schon mal beobachtet habe, aber das viell. einmal im Monat vorkommt, bei diesem Host sicherlich 3-4 mal in der Woche.

Also zusammen gefasst: 9 Host, 1 hat regelmäßig das Problem, 2 nur sehr selten, bei den restlichen 6 habe ich das noch nie beobachtet.

Wie gesagt, meine Ursprüngliche Frage war, welche LOG Dateien ich noch durchsuchen kann, außer den anfangs von mir genannten? Ich bin nicht der Linux Freak und deshalb im "Durchwühlen" von Linux / ESX Logs nicht so bewandert und ich gehe einfach davon aus, dass mir irgendwas durch die Lappen geht. Hardware Fehler die nur sporadisch auftreten, z.B. bei den pNics oder beim Raid Controller der lokalen Platten auf dem die Console läuft usw.

Ach so CRON Jobs laufen von mir keine, welche gibt es denn, die Standardmäßig auf einem ESX HOST laufen?

[Tschoergez]

Hm, die log-Dateien stehen alle unter /var/log . Die, die Du genannt hast, sind eigentlich die wichtigsten. Die werden automatisch rotiert, sodass Du evtl. auch in älteren logfiles nachschauen musst.

Auf dem vCenter gibts ja auch logfiles, die sind aber recht "ausführlich". Da müsstest Du halt die Zeiten von den "Host not responding"-Einträgen in den Task & Events im vSphere Client mit den Einträgen im vpxd.log vergleichen.

viele grüße,
jörg

[mangold]

danke nochmal, werde mir die vCenter Logs lokal noch mal anschauen, darauf war ich noch nicht gekommen. Die Einträge im Client selbst "verschwinden" ja recht schnell, meist reicht di Historie nicht mal einen ganzen Tag (kann man das ändern?)....und selbst wenn die Einträge noch vorhanden sind, sind sie im vCenter Client nicht wirklich informativ, ausser dass es wieder mal vorgefallen ist erkennt man nicht...

[UrsDerBär]

Könntest ja etwas scripten, das jede Sekunde überprüft ob der Host da ist und falls nein, sobald er wieder verfügbar ist, alle Logs wegkopiert. Wenn dies ja pro Woche/Monat teilweise mehrfach vorkommt, müsste es ja möglich sein einen solchen Moment zu erfassen.

[mangold]

nach langer Zeit wollte ich ein Update hier reingeben. Trotz langer Recherche bin ich nicht dahinter gekommen was die Fehlermeldungen auslöste. Scheinbar waren es wirklich nur "Fakes" denn in der Funktionalität des Servers konnte ich keine Probleme erkennen. Da es auch nur bei einigen Hosts auftrat, konnte ich ein VC Problem ausschließen.

Deshalb bin ich den Weg des geringsten Widerstandes gegangen, und habe die betreffenden ESX Host einfach neu installiert. Da unsere Host bis auf die HP Sim Agenten nur eine standard Konfig haben und auch das Netzwerk nur aus ca. 10 VLANs besteht ist das inkl. Updates eine Sache von 1 Stunde gewesen.

Seit dem ist das Problem auch verschwunden.