9
ESXi kein Platz in var log
Guten Morgen.
Ich hatte gestern noch eine Fehlermeldung beim migrieren von VMs auf einen anderen Speicher:
Ein allgemeiner Systemfehler ist aufgetreten: Failed to write header to "/var/log/vmware/journal/1571837490.4: Error while writing to file. There is no space left on the device
Ich habe daraufhin ein bischen gesucht und das Problem beim ESXi verortet. Aber das hat mich zunächst mal gewundert, der Server ist ersetzt worden und wurde im Anschluss von mir komplett neu aufgesetzt, konfigiruert und ist mehr oder weniger Reserve, da laufen nur 2 VMs wirklich aktiv drauf und es passiert einfach nicht viel. Das Problem hatte ich vorher auch bei keinem ESX.
Mit der Shell arbeite ich sehr wenig, mein "Wissen" stammt also aus der Suchmaschine.
für mich unauffällig
var auffällig
da habe ich mich getraut zu löschen
scheint weg zu sein
und hier kommts, die Datei, ursprünglich mindesten 1MB, ist weg aber der Speicher ist jetzt voller als vorher? Fängt der ESX hier sofort an zu schreiben oder wie kann ich das interpretieren?
Jetzt habe ich komplett /var/log von allen *.log befreit:
Das scheint mir immernoch sehr wenig Platz zu sein aber ich kann wieder migrieren. Leider habe ich keine Ahnung wie viel Platz man hier haben sollte und ich habe auch nichts mehr in /var gefunden was besonder groß geraten ist aber so aussieht als ob man es löschen könnte. habt ihr da einen Rat oder Erfahrungswerte für mich? Wenn die Ramdisk so schlank angelegt wird sollte man ja meinen das der ESX sich darum kümmert wenn der Platz knapp wird.
Hier noch zum Vergleich ein anderer ESXi:
Ich hatte gestern noch eine Fehlermeldung beim migrieren von VMs auf einen anderen Speicher:
Ein allgemeiner Systemfehler ist aufgetreten: Failed to write header to "/var/log/vmware/journal/1571837490.4: Error while writing to file. There is no space left on the device
Ich habe daraufhin ein bischen gesucht und das Problem beim ESXi verortet. Aber das hat mich zunächst mal gewundert, der Server ist ersetzt worden und wurde im Anschluss von mir komplett neu aufgesetzt, konfigiruert und ist mehr oder weniger Reserve, da laufen nur 2 VMs wirklich aktiv drauf und es passiert einfach nicht viel. Das Problem hatte ich vorher auch bei keinem ESX.
Mit der Shell arbeite ich sehr wenig, mein "Wissen" stammt also aus der Suchmaschine.
[root@esx11:~] df -h
Filesystem Size Used Available Use% Mounted on
VMFS-5 4.0T 2.4T 1.6T 61% /vmfs/volumes/VMFS01
VMFS-5 4.0T 2.4T 1.6T 61% /vmfs/volumes/VMFS02
VMFS-6 1.6T 102.9G 1.5T 6% /vmfs/volumes/VMFS03
VMFS-6 1.6T 1.4G 1.6T 0% /vmfs/volumes/VMFS04
vfat 249.7M 190.9M 58.9M 76% /vmfs/volumes/1ff0a0e0-72d7a75c-6ef0-8f78e5e79b03
vfat 249.7M 192.5M 57.2M 77% /vmfs/volumes/206967e8-42b8d658-9db3-8c87577d9abe
vfat 285.8M 178.8M 107.0M 63% /vmfs/volumes/5d27321a-23bba400-939f-a0d3c10372c8[root@esx11:~] vdf -h
[...]
-----
Ramdisk Size Used Available Use% Mounted on
root 32M 2M 29M 8% --
etc 28M 264K 27M 0% --
opt 32M 120K 31M 0% --
var 48M 47M 12K 99% --
tmp 256M 117M 138M 45% --
iofilters 32M 0B 32M 0% --
shm 1024M 0B 1024M 0% --
hostdstats 803M 5M 797M 0% --[root@esx11:~] du -ch /var
[...]
47.6M /var/log/EMU/mili
47.6M /var/log/EMU
48.0M /var/log
[...]
[root@esx11:~] find /var/log -size +1000k
/var/log/EMU/mili/mili2d.log[root@esx11:~] rm /var/log/EMU/mili/mili2d.log
[root@esx11:~] find /var/log -size +1000k[root@esx11:~] vdf -h
[...]
-----
Ramdisk Size Used Available Use% Mounted on
root 32M 2M 29M 8% --
etc 28M 264K 27M 0% --
opt 32M 120K 31M 0% --
var 48M 48M 0B 100% --
tmp 256M 117M 138M 46% --
iofilters 32M 0B 32M 0% --
shm 1024M 0B 1024M 0% --
hostdstats 803M 5M 797M 0% --Jetzt habe ich komplett /var/log von allen *.log befreit:
Ramdisk Size Used Available Use% Mounted on
[...]
var 48M 47M 12K 99% --Hier noch zum Vergleich ein anderer ESXi:
Ramdisk Size Used Available Use% Mounted on
[...]
var 48M 20M 27M 42% --
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 508269
Url: https://administrator.de/forum/esxi-kein-platz-in-var-log-508269.html
Ausgedruckt am: 28.03.2025 um 07:03 Uhr
9 Kommentare
Neuester Kommentar
Moin,
hatte ich so auch noch nicht.
tail -f dateiname zeigt Dir die letzten Zeile und alle neue Einträge.
Einfach mal schauen was da so reinkommt.
Es klingt so als ob er da im Sekundentakt irgendwas reinschreibt und irgendwann ist halt voll.
Stefan
hatte ich so auch noch nicht.
tail -f dateiname zeigt Dir die letzten Zeile und alle neue Einträge.
Einfach mal schauen was da so reinkommt.
Es klingt so als ob er da im Sekundentakt irgendwas reinschreibt und irgendwann ist halt voll.
Stefan
Ich konnte aber nicht wirklich eine einzelne Datei beobachten die diesen Platz verbraucht, zumindest nicht mit .log Endung. Die große Datei die ich einzeln gelöscht habe ist nicht wieder gekommen. Ich suche im Moment mit ls -l -S -R aber der Auswurf ist mäßig übersichtlich. Gibt es eine Möglichkeit die Größe von Ordnern inkl. Inhalt zu sehen?
Hallo,
versuch mal
du -h --max-depth=1 /
Statt 1 kannst Du auch mal 2 oder 3 probieren. Hängt von den Dateien ab ab wann das nicht mehr lesbar ist
versuch mal
du -h --max-depth=1 /
Statt 1 kannst Du auch mal 2 oder 3 probieren. Hängt von den Dateien ab ab wann das nicht mehr lesbar ist
Das gesammte Verzeichnis /var ist auf beiden verglichenen Servern nahezu identisch in Größe und Anzahl der Dateien. Ich habe alle Zeilen von ls /var -l -S -R verglichen. Wesentliche Außnahme ist die Datei /var/log/EMU/mili/mili2d.log die ich ja gelöscht hatte. Sie ist wieder da, ist aber deutlich kleiner als auf dem neuen Server ohne Speicherplatzproblem, irgendwie logisch.
Schlussfolgerungen die mir bleiben:
a) Es gibt versteckte Daten die ich mit ls nicht sehe.
b) Der Speicherplatz wird falsch berechnet / angezeigt.
c) Die SD-Karte (HP 8GB in DL380G8p) ist fertig.
Schlussfolgerungen die mir bleiben:
a) Es gibt versteckte Daten die ich mit ls nicht sehe.
b) Der Speicherplatz wird falsch berechnet / angezeigt.
c) Die SD-Karte (HP 8GB in DL380G8p) ist fertig.
Zitat von @StefanKittel:
Hallo,
versuch mal
du -h --max-depth=1 /
Statt 1 kannst Du auch mal 2 oder 3 probieren. Hängt von den Dateien ab ab wann das nicht mehr lesbar ist
Das kennt er nicht.Hallo,
versuch mal
du -h --max-depth=1 /
Statt 1 kannst Du auch mal 2 oder 3 probieren. Hängt von den Dateien ab ab wann das nicht mehr lesbar ist
Du hast Du doch oben schon benutzt?
Vor dem max-depth=1 stehen 2 Bindestriche
Vor dem max-depth=1 stehen 2 Bindestriche
Hi,
nutz mal lieber zum ansc´hauen:
ls -lisa
oder stelle mit alias es ein
usw.
Gruß
Holli
nutz mal lieber zum ansc´hauen:
ls -lisa
oder stelle mit alias es ein
alias ll='ls -lisa'
alias l='ls -ls'
alias cls=clear usw.
Gruß
Holli
[root@esx11:~] du -h --max-depth=1 /var
du: unrecognized option '--max-depth=1' https://kb.vmware.com/s/article/1003564
ls -lisa läuft, zeigt halt Ordner immer mit 512 Byte an. Aber wie schon oben geschrieben habe ich mir alle Dateien unter /var angeschaut, mit einem anderen Server verglichen und keine Problemfälle gesehen. Ich weiß also nicht so recht wo ich mit ls noch gucken könnte. Ich könnte höchstens noch den Output parsen und mal nachrechnen ob die Dateien in Summe auf ~48MB kommen...
Der Vollständigkeit halber poste ich hier noch ein paar Sachen.
Das Problem tritt unter VMware ESXi, 6.7.0, 13981272 mitlerweile auf allen meiner 3 Hosts auf. Der Speicher läuft voll, in der Folge scheitern mind. 3 Aktionen mit unterschiedlichsten Fehlermeldungen:
- Es können keine neuen VMs angelegt werden
- vMotion aktiver VMs funktioniert nicht
- Der Hypervisor läßt sich nicht Updaten
Auf einem System habe ich jetzt nochmal die mili2d.log gelöscht, einen Reboot gemacht, die Updates zum laufen bekommen und das Ergebnis unter VMware ESXi, 6.7.0, 15160138 ist der Speicherbedarf drastisch gefallen.
Beispiel Ausgangszustand:
nach Upgrade:
Das Problem tritt unter VMware ESXi, 6.7.0, 13981272 mitlerweile auf allen meiner 3 Hosts auf. Der Speicher läuft voll, in der Folge scheitern mind. 3 Aktionen mit unterschiedlichsten Fehlermeldungen:
- Es können keine neuen VMs angelegt werden
- vMotion aktiver VMs funktioniert nicht
- Der Hypervisor läßt sich nicht Updaten
Auf einem System habe ich jetzt nochmal die mili2d.log gelöscht, einen Reboot gemacht, die Updates zum laufen bekommen und das Ergebnis unter VMware ESXi, 6.7.0, 15160138 ist der Speicherbedarf drastisch gefallen.
Beispiel Ausgangszustand:
Ramdisk Size Used Available Use% Mounted on
root 32M 2M 29M 8% --
etc 28M 240K 27M 0% --
opt 32M 556K 31M 1% --
var 48M 48M 0B 100% --
tmp 256M 256M 0B 100% --
iofilters 32M 0B 32M 0% --
shm 1024M 0B 1024M 0% --
hostdstats 2053M 8M 2044M 0% --
[root@esx12:~] ls -ll
total 797
lrwxrwxrwx 1 root root 49 Sep 15 12:50 altbootbank -> /vmfs/vo lumes/e2de46e7-1f68cb59-724f-f2e465d37da7
drwxr-xr-x 1 root root 512 Sep 15 12:48 bin
lrwxrwxrwx 1 root root 49 Sep 15 12:50 bootbank -> /vmfs/volum es/df44e1e0-82a0ceea-cc3b-8662cd0fef12
-r--r--r-- 1 root root 340570 Jun 18 2019 bootpart.gz
-r--r--r-- 1 root root 225444 Jun 18 2019 bootpart4kn.gz
drwxr-xr-x 19 root root 512 Mar 10 08:56 dev
drwxr-xr-x 1 root root 512 Mar 10 08:10 etc
drwxr-xr-x 1 root root 512 Sep 15 12:48 lib
drwxr-xr-x 1 root root 512 Sep 15 12:48 lib64
-r-x------ 1 root root 20972 Sep 14 07:52 local.tgz
lrwxrwxrwx 1 root root 6 Sep 15 12:51 locker -> /store
drwxr-xr-x 1 root root 512 Sep 15 12:48 mbr
drwxr-xr-x 1 root root 512 Sep 15 12:48 opt
drwxr-xr-x 1 root root 131072 Mar 10 08:56 proc
lrwxrwxrwx 1 root root 29 Sep 15 12:51 productLocker -> /locke r/packages/vmtoolsRepo/
lrwxrwxrwx 1 root root 4 Jun 18 2019 sbin -> /bin
lrwxrwxrwx 1 root root 12 Sep 15 12:51 scratch -> /tmp/scratch
lrwxrwxrwx 1 root root 49 Sep 15 12:50 store -> /vmfs/volumes/ 5d1b3ced-c12afed2-656b-08f1eaebfafa
drwxr-xr-x 1 root root 512 Sep 15 12:48 tardisks
drwxr-xr-x 1 root root 512 Sep 15 12:48 tardisks.noauto
drwxrwxrwt 1 root root 512 Mar 10 08:56 tmp
drwxr-xr-x 1 root root 512 Sep 15 12:48 usr
drwxr-xr-x 1 root root 512 Sep 15 12:52 var
drwxr-xr-x 1 root root 512 Sep 15 12:48 vmfs
drwxr-xr-x 1 root root 512 Sep 15 12:48 vmimages
lrwxrwxrwx 1 root root 18 Jun 18 2019 vmupgrade -> /locker/vm upgrade/nach Upgrade:
Ramdisk Size Used Available Use% Mounted on
root 32M 2M 29M 8% --
etc 28M 264K 27M 0% --
opt 32M 120K 31M 0% --
var 48M 444K 47M 0% --
tmp 256M 8M 247M 3% --
iofilters 32M 0B 32M 0% --
shm 1024M 0B 1024M 0% --
hostdstats 803M 3M 799M 0% --
[root@esx11:~] ls -ll
total 797
lrwxrwxrwx 1 root root 49 Mar 9 15:15 altbootbank -> /vmfs/volumes/206967e8-42b8d658-9db3-8c87577d9abe
drwxr-xr-x 1 root root 512 Mar 9 15:13 bin
lrwxrwxrwx 1 root root 49 Mar 9 15:15 bootbank -> /vmfs/volumes/1ff0a0e0-72d7a75c-6ef0-8f78e5e79b03
-r--r--r-- 1 root root 342321 Nov 23 04:50 bootpart.gz
-r--r--r-- 1 root root 226682 Nov 23 04:50 bootpart4kn.gz
drwxr-xr-x 19 root root 512 Mar 10 09:00 dev
drwxr-xr-x 1 root root 512 Mar 10 08:17 etc
drwxr-xr-x 1 root root 512 Mar 9 15:13 lib
drwxr-xr-x 1 root root 512 Mar 9 15:13 lib64
-r-x------ 1 root root 22621 Mar 9 15:09 local.tgz
lrwxrwxrwx 1 root root 6 Mar 9 15:16 locker -> /store
drwxr-xr-x 1 root root 512 Mar 9 15:13 mbr
drwxr-xr-x 1 root root 512 Mar 9 15:13 opt
drwxr-xr-x 1 root root 131072 Mar 10 09:00 proc
lrwxrwxrwx 1 root root 29 Mar 9 15:16 productLocker -> /locker/packages/vmtoolsRepo/
lrwxrwxrwx 1 root root 4 Nov 23 04:32 sbin -> /bin
lrwxrwxrwx 1 root root 12 Mar 9 15:16 scratch -> /tmp/scratch
lrwxrwxrwx 1 root root 49 Mar 9 15:15 store -> /vmfs/volumes/5d27321a-23bba400-939f-a0d3c10372c8
drwxr-xr-x 1 root root 512 Mar 9 15:13 tardisks
drwxr-xr-x 1 root root 512 Mar 9 15:13 tardisks.noauto
drwxrwxrwt 1 root root 512 Mar 10 09:00 tmp
drwxr-xr-x 1 root root 512 Mar 9 15:13 usr
drwxr-xr-x 1 root root 512 Mar 9 15:13 var
drwxr-xr-x 1 root root 512 Mar 9 15:13 vmfs
drwxr-xr-x 1 root root 512 Mar 9 15:13 vmimages
lrwxrwxrwx 1 root root 18 Nov 23 04:32 vmupgrade -> /locker/vmupgrade/
