Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

ESXI 5.5 the inode table of its ramdisk (root) is full.

Moderatoren: Dayworker, continuum, Tschoergez, irix

Member
Beiträge: 92
Registriert: 26.08.2010, 10:40

ESXI 5.5 the inode table of its ramdisk (root) is full.

Beitragvon meddie » 03.12.2014, 15:34

Hallo Leute,

habe mich heute mit meinem ESXi Host verbunden und wollte die Konsole einer VM starten. Dieses schlug fehl mit der Meldung, dass es kein Lock File erstellen kann.
In der vmkernel Log sehe ich diese Meldung:

Code: Alles auswählen

Cannot create file /var/run/vmware/tickets/vmtck for process hostd-worker because the inode table of its ramdisk (root) is full.


Tja dachte zuerst, alles Easy mit df -h siehst Du was voll ist. Aber da zeigt er nur die VMFS Volumes an und nicht die /
Hab die KB von vmware durchgecheckt. Es gibt keine SNMP Traps die man löschen kann. Die Logs liegen auf einer Storage. (Der ESXi ist auf einem 2 GB USB Device installiert. )

NACHTRAG: Wenn ich

Code: Alles auswählen

 cd /
du -hxc . | less


ausführe sehe ich am Ende total: 1.1 G das UFM Device ist 2 GB

Habe die ganzen tmp Verzeichnisse durchgeguckt ist auch nichts drin.

Habt Ihr noch ein Tipp für mich
Danke
Gruß Eddie

King of the Hill
Beiträge: 12359
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 03.12.2014, 15:54

Unabhängig vom Füllstand eines Laufwerks bedeutet eine Inode-Meldung eigentlich immer, daß der für Verzeichnis- oder Dateieinträge notwendige Speicherbereich des Dateisystems erschöpft ist. VMware hat dazu den KB-Eintrag VMware ESXi 5.x host becomes unresponsive when attempting a vMotion migration or a configuration change (2040707) verfaßt.

Member
Beiträge: 92
Registriert: 26.08.2010, 10:40

Beitragvon meddie » 03.12.2014, 16:21

Den KB hab ich auch schon.
das sehe ich:

Code: Alles auswählen

~ # cd /
~ # stat -f /
  File: "/"
    ID: 100000000 Namelen: 127     Type: visorfs
Block size: 4096
Blocks: Total: 476301     Free: 325889     Available: 325889
Inodes: Total: 524288     Free: 515571


Und es gibt bei mir gar kein SNMP Verzeichnis im /var/spool/

King of the Hill
Beiträge: 12359
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 03.12.2014, 17:11

Sieh dir mal den KB-Eintrag ESXi/ESX error: No free space left on device (1007638) an und arbeite die Lösungspunkte 3 und 4 durch. Irgendwo müssen ja viele, vermutlich Dateien rumliegen.
Alternativ starte den ESXi mal neu. Wie lange läuft der eigentlich bei dir bereits?

Member
Beiträge: 92
Registriert: 26.08.2010, 10:40

Beitragvon meddie » 03.12.2014, 18:34

Hi Dayworker,

vielen Dank für Deine Unterstützung ich komme mir auch total blöd vor, wenn Du mir Tipps gibst, aber diesen KB habe ich auch schon. Allerdings kann ich mit den Verzeichnissen nichts anfangen. Diese 3 Verzeichnisse sind da nicht vorhanden die in den KB beschrieben werden.
Was den vmkfstools Befehl angeht, meine ganzen VMFS liegen ja auf einer Storage, das heißt diese können ja nicht betroffen sein. Einen lokalen Datastore habe ich nicht.

Der Server hat eine uptime von 267 Tagen und ein paar Stunden

Code: Alles auswählen

~ # find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;
-r--r--r--    1 root     root     306797152 Mar 13  2014 /tardisks/s.v00
-r--r--r--    1 root     root     155311920 Mar 13  2014 /tardisks/sb.v00
-rw-------    1 root     root     4394019979264 Dec  3 17:29 /dev/lvm/532083a5-4e9a92be-d025-001999bad5f1
-rw-------    1 root     root     549487378432 Dec  3 17:29 /dev/lvm/525f8712-0beca302-59c9-0019999869ee
-rw-------    1 root     root     2198754820096 Dec  3 17:29 /dev/lvm/5170eb5c-54ed1806-adb4-001999babd46
-rw-------    1 root     root     1288221753344 Dec  3 17:29 /dev/lvm/504717c3-0df7ab9c-b431-00199998e359
-rw-------    1 root     root     2198754820096 Dec  3 17:29 /dev/lvm/4f609827-dfa7ed84-54fd-00199998e359
-rw-------    1 root     root     1648999006208 Dec  3 17:29 /dev/lvm/4f6097b1-e8a07dd2-e036-00199998e359
-rw-------    1 root     root     1099243192320 Dec  3 17:29 /dev/lvm/4f61be16-8a9acc7a-3c1b-00199998e359
-rw-------    1 root     root     1099243192320 Dec  3 17:29 /dev/lvm/4f6097fb-0e9c9d70-ac16-00199998e359
-rw-------    1 root     root     5244423503872 Dec  3 17:29 /dev/lvm/4f60977f-4674aaa4-ca4d-00199998e359
-rw-------    1 root     root     8388339564544 Dec  3 17:29 /dev/lvm/530caadc-6c1c7381-f68c-001999eea401
-rw-------    1 root     root     85899345920 Dec  3 17:29 /dev/cbt/34217712-cbt
-rw-------    1 root     root     21474836480 Dec  3 17:29 /dev/cbt/152b18eb-cbt
-rw-------    1 root     root     1979120929792 Dec  3 17:29 /dev/cbt/32ebcb3a-cbt
-rw-------    1 root     root     107374182400 Dec  3 17:29 /dev/cbt/2fc9cb36-cbt
-rw-------    1 root     root     85899345920 Dec  3 17:29 /dev/cbt/2fde89fd-cbt
-rw-------    1 root     root     42949672960 Dec  3 17:29 /dev/cbt/2f6a8477-cbt
-rw-------    1 root     root     42949672960 Dec  3 17:29 /dev/cbt/2fc58474-cbt
-rw-------    1 root     root     85899345920 Dec  3 17:29 /dev/cbt/33c4ccad-cbt
-rw-------    1 root     root     64424509440 Dec  3 17:29 /dev/cbt/3671ccaa-cbt
-rw-------    1 root     root     53687091200 Dec  3 17:29 /dev/cbt/1c5f37b9-cbt
-rw-------    1 root     root     107374182400 Dec  3 17:29 /dev/cbt/234537b6-cbt
-rw-------    1 root     root     171798691840 Dec  3 17:29 /dev/cbt/1caf0d1-cbt
-rw-------    1 root     root     214748364800 Dec  3 17:29 /dev/cbt/17ff0cd-cbt
-rw-------    1 root     root     375809638400 Dec  3 17:29 /dev/cbt/22ff0c9-cbt
-rw-------    1 root     root     274877906944 Dec  3 17:29 /dev/cbt/13b5a51-cbt
-rw-------    1 root     root     53687091200 Dec  3 17:29 /dev/cbt/13e5a40-cbt
-rw-------    1 root     root     21474836480 Dec  3 17:29 /dev/cbt/727fe-cbt
-rw-------    1 root     root     2147483648 Dec  3 17:29 /dev/cbt/327ff-cbt
-rw-------    1 root     root     31963438080 Dec  3 17:29 /dev/cbt/b1c87-cbt
-rw-------    1 root     root     85899345920 Dec  3 17:29 /dev/cbt/21171c-cbt
-rw-------    1 root     root     1649267441664 Dec  3 17:29 /dev/cbt/10171d-cbt
-rw-------    1 root     root     2002780160 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0
-rw-------    1 root     root     299876352 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0:8
-rw-------    1 root     root     115326976 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0:7
-rw-------    1 root     root     262127616 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0:6
-rw-------    1 root     root     262127616 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0:5
-rw-------    1 root     root     939524096 Dec  3 17:29 /dev/disks/mpx.vmhba32:C0:T0:L0:1
-rw-------    1 root     root     5244669919232 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00000000
-rw-------    1 root     root     5244668853760 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00000000:1
-rw-------    1 root     root     1649267441664 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00040000
-rw-------    1 root     root     1649266294784 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00040000:1
-rw-------    1 root     root     1099511627776 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00060000
-rw-------    1 root     root     1099505030144 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00060000:1
-rw-------    1 root     root     2199023255552 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00070000
-rw-------    1 root     root     2199019334144 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc00070000:1
-rw-------    1 root     root     1099511627776 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000b0000
-rw-------    1 root     root     1099505030144 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000b0000:1
-rw-------    1 root     root     1288490188800 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000c0000
-rw-------    1 root     root     1288489123328 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000c0000:1
-rw-------    1 root     root     2199023255552 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000d0000
-rw-------    1 root     root     2199022190080 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000d0000:1
-rw-------    1 root     root     549755813888 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000e0000
-rw-------    1 root     root     549754748416 Dec  3 17:29 /dev/disks/naa.600000e00d11000000110dbc000e0000:1
-rw-------    1 root     root     8388608000000 Dec  3 17:29 /dev/disks/naa.600000e00d00000000012daf00020000
-rw-------    1 root     root     8388606934528 Dec  3 17:29 /dev/disks/naa.600000e00d00000000012daf00020000:1
-rw-------    1 root     root     4394288414720 Dec  3 17:29 /dev/disks/naa.600000e00d00000000012daf00010000
-rw-------    1 root     root     4394287349248 Dec  3 17:29 /dev/disks/naa.600000e00d00000000012daf00010000:1
~ #


und das liefert mir der df -h

Code: Alles auswählen

~ # df -h
Filesystem    Size   Used Available Use% Mounted on
VMFS-5        4.8T   3.7T      1.0T  78% /vmfs/volumes/Eternus-VM-Storage-SAS-1
VMFS-5     1023.8G 588.4G    435.4G  57% /vmfs/volumes/Eternus-VM-Vorlagen-NLS-1
VMFS-5        1.5T   1.0T    494.5G  68% /vmfs/volumes/Eternus-VM-SAP-NLS-1
VMFS-5        2.0T   1.5T    510.4G  75% /vmfs/volumes/Eternus-VM-File-NLS-1
VMFS-5        1.2T 781.5G    418.2G  65% /vmfs/volumes/Eternus-VM-DMZ-NLS-1
VMFS-5        2.0T   1.6T    402.8G  80% /vmfs/volumes/Eternus-VM-SAP-NLS-2
VMFS-5      511.8G  86.6G    425.2G  17% /vmfs/volumes/Eternus-VM-SVN-NLS-1
VMFS-5        4.0T   2.6T      1.4T  64% /vmfs/volumes/DX80-SAP-Replication
VMFS-5     1023.8G 481.0G    542.8G  47% /vmfs/volumes/Eternus-VM-EV-NLS-1
VMFS-5        7.6T 669.1G      7.0T   9% /vmfs/volumes/DX80-VM-Replication-1
vfat        249.7M 176.4M     73.3M  71% /vmfs/volumes/a1e935af-a74ba73f-8c24-55097576f200
vfat        249.7M   8.0K    249.7M   0% /vmfs/volumes/cde1e01f-a940f3b1-5f60-76aa870b1000
vfat        285.9M 191.4M     94.5M  67% /vmfs/volumes/bf1b8003-bb4f04a5-edf5-9f0849c25200

Danke Dir

Experte
Beiträge: 1443
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 04.12.2014, 09:40

Der KB-Artikel 2033073, der auch den SNMP-Hinweis gibt, spricht doch nicht von df -h, sondern von vdf -h

Da werden am Ende auch die Belegungen der RAM-Disks ausgegeben, z.B.

Code: Alles auswählen

Ramdisk                   Size      Used Available Use% Mounted on
root                       32M      816K       31M   2% --
etc                        28M      312K       27M   1% --
tmp                       192M       16K      191M   0% --
hostdstats                639M        3M      635M   0% --
snmptraps                   1M        0B        1M   0% --


Wie sieht das bei Dir aus?

Ich denke nicht, dass hier der Datastore das Problem ist, sondern eben, wie die Fehlermeldung ja schon deutlich sagt, die RAM-Disk, in der wohl irgendwelche Helper-Informationen abgelegt werden sollen.

Und es muessen dann nicht unbedingt SNMP-Dateien sein, die da Inodes belegen, sondern auch andere Komponenten (z.B. das "verwandte" CIM) koennen Probleme bereiten.

Insofern waere der Tipp von Dayworker, das System mal durchzustarten, mit an Sicherheit grenzender Wahrscheinlichkeit auch zielfuehrend.

Member
Beiträge: 92
Registriert: 26.08.2010, 10:40

Beitragvon meddie » 04.12.2014, 09:49

Stimmt das habe ich irgendwie verpeilt.
Das ist die Ausgabe;

Code: Alles auswählen

~ # vdf -h
Tardisk                  Space      Used
elxnet.v00                312K      310K
emulex-c.v00               30M       30M
ima-be2i.v00                1M        1M
lpfc.v00                    1M        1M
scsi-be2.v00              664K      660K
svscimpr.v00               11M       11M
net-igb.v00               296K      293K
net-ixgb.v00              432K      429K
lsiprovi.v00               26M       26M
scsi-meg.v00              164K      161K
ata-pata.v00               40K       39K
ata-pata.v01               28K       27K
ata-pata.v02               32K       30K
ata-pata.v03               32K       30K
ata-pata.v04               36K       35K
ata-pata.v05               32K       31K
ata-pata.v06               28K       27K
ata-pata.v07               36K       32K
block-cc.v00               80K       77K
ehci-ehc.v00               92K       91K
s.v00                     292M      292M
sb.v00                    148M      148M
weaselin.t00               14M       14M
esx-dvfi.v00              404K      401K
xlibs.v00                   1M        1M
ima-qla4.v00                1M        1M
ipmi-ipm.v00               40K       38K
ipmi-ipm.v01               88K       87K
ipmi-ipm.v02              100K       97K
lsi-mr3.v00               180K      177K
lsi-msgp.v00              364K      363K
misc-cni.v00               24K       23K
misc-dri.v00                4M        4M
mtip32xx.v00              180K      176K
net-be2n.v00              420K      419K
net-bnx2.v00              272K      268K
net-bnx2.v01                1M        1M
net-cnic.v00              132K      131K
net-e100.v00              288K      286K
net-e100.v01              232K      229K
net-enic.v00              132K      130K
net-forc.v00              120K      117K
net-mlx4.v00              332K      328K
net-mlx4.v01              224K      220K
net-nx-n.v00                1M        1M
net-tg3.v00               260K      259K
net-vmxn.v00              100K       98K
ohci-usb.v00               60K       58K
qlnative.v00                1M        1M
rste.v00                  740K      737K
sata-ahc.v00               80K       76K
sata-ata.v00               56K       52K
sata-sat.v00               60K       59K
sata-sat.v01               44K       40K
sata-sat.v02               44K       40K
sata-sat.v03               36K       32K
sata-sat.v04               32K       28K
scsi-aac.v00              168K      164K
scsi-adp.v00              412K      409K
scsi-aic.v00              280K      278K
scsi-bnx.v00              224K      223K
scsi-bnx.v01              196K      194K
scsi-fni.v00              160K      157K
scsi-hps.v00              164K      160K
scsi-ips.v00               96K       93K
scsi-lpf.v00                1M        1M
scsi-meg.v01               92K       91K
scsi-meg.v02               88K       87K
scsi-mpt.v00              372K      371K
scsi-mpt.v01              500K      497K
scsi-mpt.v02              420K      418K
scsi-qla.v00                1M        1M
scsi-qla.v01              272K      268K
uhci-usb.v00               60K       57K
FTS-Conf.v00                8K        7K
xorg.v00                    3M        3M
imgdb.tgz                 372K      370K
state.tgz                  20K       18K
-----
Ramdisk                   Size      Used Available Use% Mounted on
root                       32M       18M       13M  56% --
etc                        28M      200K       27M   0% --
tmp                       192M       16K      191M   0% --
hostdstats               1053M       13M     1039M   1% --


RAMdisk scheint nicht voll zu sein

Experte
Beiträge: 1955
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 04.12.2014, 10:18

Was ergibt bei dir das Kommando

Code: Alles auswählen

ls -l /productLocker/
?
(Normal: "floppies" und "vmtools")

Experte
Beiträge: 1443
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 04.12.2014, 10:27

Jein, nicht ganz...
Es geht ja nicht um Platz auf der RAM-Disk, sondern in deren inode table. Und wenn ganz ganz viele kleine Eintraege in diese Tabelle geschrieben werden (z.B. fuer leere Dateien), dann fuellt sich nur diese Tabelle, aber nicht das Dateisystem.

Dafuer spricht ja auch die ergebnislose Suche nach grossen Dateien.

Einer der frueheren Outputs listet "Eternus DX80". Wird die von Fujitsu Primergy-Servern angesprochen? Vielleicht mit Fujitsu Custom Image? Wenn ja+ja: Welche Version, und wurden nach der Installation Patches nur von VMware selber oder auch von FTS eingespielt?

Und noch immer bleibt die Frage:
Wie waer's mal pragmatisch mit einem Reboot des betroffenen Hosts?

Member
Beiträge: 92
Registriert: 26.08.2010, 10:40

Beitragvon meddie » 04.12.2014, 10:49

~thc hat geschrieben:Was ergibt bei dir das Kommando

Code: Alles auswählen

ls -l /productLocker/
?
(Normal: "floppies" und "vmtools")


Jop:

Code: Alles auswählen

~ # ls -l /productLocker/
total 512
drwxr-xr-x    1 root     root             8 Jan  7  2014 FLOPPIES
drwxr-xr-x    1 root     root             8 Jan  7  2014 VMTOOLS
~ #


JustMe hat geschrieben:Einer der frueheren Outputs listet "Eternus DX80". Wird die von Fujitsu Primergy-Servern angesprochen? Vielleicht mit Fujitsu Custom Image? Wenn ja+ja: Welche Version, und wurden nach der Installation Patches nur von VMware selber oder auch von FTS eingespielt?

Ja nur Fujitsu Primergy Server. Und das andere Ja ein Fujitsu Image 5.5.0 1331820. Nach der Installation nur Patches von vmware.

JustMe hat geschrieben:Und noch immer bleibt die Frage:
Wie waer's mal pragmatisch mit einem Reboot des betroffenen Hosts?

Ist für morgen geplannt. Da da ein paar VMs drauf sind, die ich auf den anderen Hosts nicht unterbringen kann (wegen der Größe) und es ja doch ein Risiko besteht, dass der ESXi nicht hochfährt. Oder die VMs anschließend nicht starten kann.

Experte
Beiträge: 1443
Registriert: 04.10.2011, 14:06

Beitragvon JustMe » 04.12.2014, 10:59

meddie hat geschrieben:Ja ein Fujitsu Image 5.5.0 1331820. Nach der Installation nur Patches von vmware.

Das koennen aber bei >250 Tage Uptime auch nicht soooo viele sein ;-)

Trotzdem:
Das ist nicht wirklich gut...
Beim Custom Image kommen ja ein paar Komponenten mit in's System, die nicht Bestandteil der VMware-Originale sind. Weil die dort nicht mit dabei sind, werden die dann halt nie aktualisiert. Und ob diese "Altlasten" mit den restlichen aktualisierten Komponenten noch gut zusammenspielen, wird vmtl. auch niemand mehr testen (wollen).

Selbstverstaendlich wuerde sich jeder wuenschen, fehlerfreie Software zu erzeugen, aber ich befuerchte mal, dass das auch bei FTS (und von dort hinzugefuegten Komponenten) noch nicht erreicht wurde.

Deswegen koennte ein nachgezogenes Patchen mit dem aktuellen FTS-Stand (z.B. beim Reboot gleich, und dann immer mal wieder) durchaus hilfreich sein, denke ich...

Experte
Beiträge: 1955
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 04.12.2014, 11:41

JustMe hat geschrieben:Das koennen aber bei >250 Tage Uptime auch nicht soooo viele sein ;-)

Die Installation von einem Patch bringt das ESXi komplett auf den Stand dieses Patches.
Mit einem falschen Kommando ersetzt man möglicherweise herstellerspezifischen Treiber durch die VMWare-Originale ("install" statt "upgrade").


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste