Seite 1 von 1

VMkwarning verkleinern?

Verfasst: 10.12.2014, 09:42
von No.
Mahlzeit,

heute habe ich beim Migrieren von einer VM auf ein anderes Storage folgende Meldung bekommen:

---------------------------
Fehler
---------------------------
Ein allgemeiner Systemfehler ist aufgetreten: Failed to create journal file providerFailed to open "/var/log/vmware/journal/1418200887.25" for write
---------------------------
OK
---------------------------

Also erstmal geschaut was da los ist und da war die "vmkwarning" auf 1,2 Gbyte angeschwollen!!!!! Natürlich war die Partition dadurch gleich voll.

Jetzt ist die Frage: Wie bekomme ich diese verkleinert? Klar im Endeffekt könnte ich auf die Rotation warten, aber wo kann man sehen wann diese ist?

Gruß

Verfasst: 10.12.2014, 11:02
von JustMe
No. hat geschrieben:Jetzt ist die Frage: Wie bekomme ich diese verkleinert?

Loeschen vielleicht?
Und dafuer sorgen, dass nicht mehr so viele Meldungen geschrieben werden muessen, indem die Ursache der vielen Meldungen beseitigt wird?

Letztlich ist die vmkwarning.log nur ein "Auszug" von vmkernel.log, naemlich fuer die Warnungen...

Ich hab' schon lange keinen ESX mehr bedienen muessen, aber fuer die Log-Verwaltung in der ESX-ServiceConsole ist wahrscheinlich Controling log file rotation and working around the lack of a /var partition immer noch hilfreich. Um selber mal zu schauen, wann die Logrotation ausgefuehrt wird (mal getippt: stuendlich), muss man vmtl. die cron-Jobs durcharbeiten.

Verfasst: 10.12.2014, 11:10
von No.
Die kann man einfach so löschen?

Kann man sich die Logs auf der Kommandozeile ansehen? Gibt es da einen Editor oder dergleichen? sowas wie nano, jedit oder vi?

Das komische ist halt auch das einige vmkernel-dateien um die 300MB sind.

Entschuldigung für die komischen Fragen... aber ich hab das jetzt vorgesetzt bekommen und muss mich darum kümmern.

Verfasst: 10.12.2014, 13:07
von JustMe
:roll: *seufz*...

Mal ganz ehrlich: Was soll denn wohl passieren, wenn man auf der Kommandozeile einfach mal nano + Enter oder vi + Enter eingibt? Der explodiert schon nicht...

Den vi gibt's bei ESX und bei ESXi; den nano nur bei ESX.

Und selbst wenn's keine lesbaren Dateien waeren, koennte man die sich immer noch (z.B. blockweise) mit hexdump bzw. noch mehr 'basic' mit dd anschauen.

"Komisch" ist es jedenfalls nicht, dass die vmkernel.logs mehrere 100MB gross sind.
Das ist pauschal erst einmal nicht ungewoehnlich, aber untersuchen koennte man das schon.

No. hat geschrieben:...aber ich hab das jetzt vorgesetzt bekommen und muss mich darum kümmern.
Dann waer's mAn vielleicht aber sinnvoller, sich mal erst mit jenen 'Basics' auseinanderzusetzen, als gleich die Logrotation (Symptome) untersuchen (bzw. unbearbeitet beseitigen) zu wollen, ohne ueberhaupt zu wissen, was in den Logs drinsteht (Ursachen)...
...vielleicht kann man sich dann alles andere sparen, weil die Buechse sowieso in ein paar Wochen/Stunden/Sekunden den Geist aufgibt.

Aber ok: Chacun a son gout (die Franzosen moegen mir bitte verzeihen)

Verfasst: 10.12.2014, 21:09
von bla!zilla
JustMe hat geschrieben:"Komisch" ist es jedenfalls nicht, dass die vmkernel.logs mehrere 100MB gross sind. Das ist pauschal erst einmal nicht ungewoehnlich, aber untersuchen koennte man das schon.


Also ich finde das schon ungewöhnlich... Die Dateien sollten rotiert werden. Wenn der ESXi auf einem USB Stick oder einer SD Card läuft, dann sollte ein Scratchverzeichnis konfiguriert sein.

Verfasst: 11.12.2014, 08:59
von No.
Bisher hab ich nur Zeugs in vCenter gemacht oder habe Vmware nur als einzelnen Host betrieben (privat oder in kleinen Umgebungen), da ich eigentlich aus der HyperV-Ecke komme.

Ich hab gestern einfach per WinSCP die Dateien mal rüber gezogen. Hab dann versucht diese zu öffnen... aber die ist so gigantisch, dass es nicht mal ein Core-i7 schafft. Aber die einiges konnte ich raus lesen. Er hatte einfach ein vorher verbundenes Target nicht mehr gefunden, und in jeder Minute einen Eintrag produziert... irgendwie schon lustig.

Verfasst: 11.12.2014, 12:23
von JustMe
bla!zilla hat geschrieben:Die Dateien sollten rotiert werden.

Dem wuerde ich glatt zustimmen. Aber wenn schon zur Journal-Dateiverwaltung keine Dateien mehr angelegt werden koennen, vermute ich einfach mal, dass das periodische Aufrollen auch keine Chance fuer die Liebe mehr hat.

No. hat geschrieben:...so gigantisch, dass es nicht mal ein Core-i7 schafft

Mit was fuer einem Editor versuchst Du Dich denn an der Datei? Winword? MS Write? :grin:

Aber trotzdem hm. Bei einem Eintrag pro Minute muesste der Fehler ja doch schon eine ganze Weile bestehen, um auf Gigabyte-grosse Dateien zu kommen. (1GB=1073741824 Bytes, angenommene mittlere Zeilenlaenge 150 Zeichen, heisst 7158278,8... Eintraege. Geteilt durch 60 Minuten und 24 Stunden ergibt das 4971 Tage bzw. 13,6 365er Jahre, d.h. Schaltjahre nicht mitgerechnet...)

Anyway: Wenn die Fehlerursache identifiziert und beseitigt sein sollte, kommen nicht mehr so viele Eintraege, und nach einem Reboot sollte fuer die naechste Zeit alles ok sein.

Verfasst: 11.12.2014, 15:21
von No.
Also das Protokoll des Fehlers beginnt am 02.12. und zum Ende hin hatte es sich dann wieder beruhigt, da taucht der Fehler nicht mehr auf. Eigenartig.

Ich hab heute nochmal geguckt... die Rotation hat heute nacht zu geschlagen. Also funktioniert diese auch schonmal.

Erst waren nach dem löschen dieser einen Datei, von 4Gb etwa 2,8Gb belegt... heute morgen nur noch 300Mb.

Ich hatte versucht die mit windows Wordpad zu öffnen, obwohl ich immer notepad++ verwende, aber dies hat gleich den Dienst verweigert und meinte die Datei wäre zu Groß :lol:

Mit wordpad konnte ich es wenigstens öffnen, dauerte aber fast 1 stunde bis ich was angezeigt bekommen hatte. :lol:

Verfasst: 13.12.2014, 16:31
von Dayworker
Ulli (continuum) und ich hatten auch mal Probleme eine gepackte, knapp 100MB grosse Logdatei zu interpretieren, da diese nach dem Entpacken auf gut 1.5GB anschwoll.
Das Notepad++ sich weigert Dateien ab einer unbekannten Grösse zu öffnen, war mir dabei auch schon aufgefallen. Wenn du nur unter Windows zuhause bist, tut es dort auch der Large Text File Viewer v5.2. Die App zählt nur beim Öffnen einer Datei kurz (kurz ist relativ und in Abhängigkeit zur Datenträgerperformance zu verstehen, eine SSD ist von Vorteil...) die Zeilenanzahl durch und hält ansonsten nur den gerade angezeigten Dateiinhalt im RAM vor. Beim Scrollen wird dann dynamisch nachgeladen.