No vmkcore disk partition is available & no network core

[ohhmille]

Hallo Gemeinde

Seit ein paar Tagen habe ich auf einem ESXi 5.1 build 30 70 626 ( standalone free ) eine Fehlermeldung, die ich mir nicht erklären kann. Sie erscheint, nachdem ich auf einem DELL PowerEdge R710 die aktuellsten Firmware updates installiert habe.

Die Fehlermeldung lautet:
"No vmkcore disk partition is available and no network coredump server has been configured. Host core dumps cannot be saved."

Ich habe bereits folgende KB-Artikel zu Rate gezogen:
- https://kb.vmware.com/selfservice/micro ... Id=2004299

- https://kb.vmware.com/selfservice/micro ... Id=2097174

Leider funktioniert das alles nicht.


Folgende Befehle habe ich versucht:
~ # esxcli system coredump partition list
no configured dump partition found; skipping

~ # esxcli system coredump partition set --enable true --smart
Unable to smart activate a dump partition. Error was: Not a known device: mpx.vmhba34:C0:T0:L0.

Im vSphereClient habe ich nur folgende storage adapter
2port SATA IDE Controller (ICH9)
vmhba0 = Block SCSI
vmhba33 = Block SCSI
DellPERC 6/I Integrated
vmhba1 = SCSI

Dann habe ich noch folgendes probiert
~ # ls -alh /vmfs/devices/disks
drwxr-xr-x 1 root root 512 Sep 8 09:34 .
drwxr-xr-x 1 root root 512 Sep 8 09:34 ..
-rw------- 1 root root 7.4G Sep 8 09:34 mpx.vmhba32:C0:T0:L0
-rw------- 1 root root 896.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:1
-rw------- 1 root root 4.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:4
-rw------- 1 root root 250.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:5
-rw------- 1 root root 250.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:6
-rw------- 1 root root 110.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:7
-rw------- 1 root root 286.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:8
-rw------- 1 root root 557.8G Sep 8 09:34 naa.6782bcb00513910014dd408d1f86c0cb
-rw------- 1 root root 557.7G Sep 8 09:34 naa.6782bcb00513910014dd408d1f86c0cb:1
-rw------- 1 root root 1.4T Sep 8 09:34 naa.6782bcb00513910014de901f077e2f48
-rw------- 1 root root 1.4T Sep 8 09:34 naa.6782bcb00513910014de901f077e2f48:1
lrwxrwxrwx 1 root root 20 Sep 8 09:34 vml.0000000000766d68626133323a303a30 -> mpx.vmhba32:C0:T0:L0
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:1 -> mpx.vmhba32:C0:T0:L0:1
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:4 -> mpx.vmhba32:C0:T0:L0:4
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:5 -> mpx.vmhba32:C0:T0:L0:5
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:6 -> mpx.vmhba32:C0:T0:L0:6
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:7 -> mpx.vmhba32:C0:T0:L0:7
lrwxrwxrwx 1 root root 22 Sep 8 09:34 vml.0000000000766d68626133323a303a30:8 -> mpx.vmhba32:C0:T0:L0:8
lrwxrwxrwx 1 root root 36 Sep 8 09:34 vml.02000000006782bcb00513910014dd408d1f86c0cb504552432036 -> naa.6782bcb00513910014dd408d1f86c0cb
lrwxrwxrwx 1 root root 38 Sep 8 09:34 vml.02000000006782bcb00513910014dd408d1f86c0cb504552432036:1 -> naa.6782bcb00513910014dd408d1f86c0cb:1
lrwxrwxrwx 1 root root 36 Sep 8 09:34 vml.02000000006782bcb00513910014de901f077e2f48504552432036 -> naa.6782bcb00513910014de901f077e2f48
lrwxrwxrwx 1 root root 38 Sep 8 09:34 vml.02000000006782bcb00513910014de901f077e2f48504552432036:1 -> naa.6782bcb00513910014de901f077e2f48:1


Da steht jetzt nur noch etwas von vmhba32...

Jemand eine Idee?!?

Grüße
Mille

[PBecker]

Und das liegt nicht nur daran, dass der Server von SD-Karte läuft und gar keine Platten hat?

[ohhmille]

Ja, ESXi ist auf einer SD-Card installiert. Am eigentlichen Betriebssystem haben wir ja gar nichts geändert, ist alles so geblieben während des firmware-updates.

Lokale Platten sind auch drinnen, ein RAID mit 7K Platten und eine RAID mit 10K Platten. ( VMFS3 )

Zusätzlich noch ein NFS storage!

Was mich halt wundert ist, dass es erst seit den firmware upgrades auftaucht...

[JustMe]

Die vmkcore Partition duerfte
-rw------- 1 root root 110.0M Sep 8 09:34 mpx.vmhba32:C0:T0:L0:7
(gewesen) sein.

Die beiden RAIDs dürfen 550G und 1T4 gross sein laut der Liste.

Warum der vmhba32 jetzt als vmhba34 erkannt wird, muesste vielleicht eher DELL/VMware erklaeren, wenn es denn nur mit dem Firmware-Update zu tun hat. Vielleicht hat ja der SD-Adapter aufgrund des Updates eine neue Device-ID erhalten...

Die USB- usw. sonstige spezielle Bootdevices tauchen im vSphere-Client grundsaetzlich nicht auf.

Schau mal auf der Kommandozeile mit
esxcli storage core adapter list
nach, was denn genau gelistet wird.

Dort laesst sich auch gleich mit fdisk -l (oder fuer die Nicht-Ewiggestrigen mit partedUtil, KB1036609) ueberpruefen, welche Typbezeichnungen die Partitions haben.

Laesst sich die vmkcore-Partition denn nicht-smart, d.h. unter expliziter Angabe der gewuenschten Partition zu einer solchen definieren?

[ohhmille]

Genau, die Größen der lokalen Platten stimmen. Da liegen hat die VMs drauf.

Das sind die storage adapter

~ # esxcli storage core adapter list
HBA Name Driver Link State UID Description
-------- ------------ ---------- -------------- --------------------------------------------------------------
vmhba0 ata_piix link-n/a sata.vmhba0 (0:0:31.2) Intel Corporation 2 port SATA IDE Controller (ICH9)
vmhba1 megaraid_sas link-n/a unknown.vmhba1 (0:3:0.0) LSI / Symbios Logic Dell PERC 6/i Integrated
vmhba32 usb-storage link-n/a usb.vmhba32 () USB
vmhba33 ata_piix link-n/a sata.vmhba33 (0:0:31.2) Intel Corporation 2 port SATA IDE Controller (ICH9)


Aktuell gehe ich auch davon aus, dass der SD-Card-Adapter eine neue Device-ID bekommen hat. Vielleicht hat der ESXi den jetzt auch nur als neuen erkannt, da die firmware noch NIE upgedatet wurde. VIelleicht ist das alles so neu, dass der ESXi denkt, dass sei komplett neu!
Wie dem auch sei!

fdisk -l ergibt folgendes

Disk /dev/disks/mpx.vmhba32:C0:T0:L0: 7948 MB, 7948206080 bytes
255 heads, 63 sectors/track, 966 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/disks/mpx.vmhba32:C0:T0:L0p1 1 115 917504 5 Extended
Partition 1 has different physical/logical endings:
phys=(115, 47, 9) logical=(114, 187, 9)
Partition 1 does not end on cylinder boundary
/dev/disks/mpx.vmhba32:C0:T0:L0p4 * 1 1 4080 4 FAT16 <32M
Partition 4 does not end on cylinder boundary
/dev/disks/mpx.vmhba32:C0:T0:L0p5 1 33 255984 6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p6 33 65 255984 6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p7 65 79 112624 fc VMKcore
/dev/disks/mpx.vmhba32:C0:T0:L0p8 79 115 292848 6 FAT16

Partition table entries are not in disk order

Disk /dev/disks/naa.6782bcb00513910014de901f077e2f48: 1498.6 GB, 1498675150848 bytes
255 heads, 63 sectors/track, 182203 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.6782bcb00513910014de901f077e2f48p1 1 182203 1463545533+ fb VMFS

Disk /dev/disks/naa.6782bcb00513910014dd408d1f86c0cb: 598.8 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/disks/naa.6782bcb00513910014dd408d1f86c0cbp1 1 72809 584838228+ fb VMFS


Bedeutet also, dass auf L0p7 meine VMKcore liegt.


Kann ich das dann mit diesen beiden Befehlen umbiegen?

esxcli system coredump partition set --partition="mpx.vmhba32:C0:T0:L0p7"

esxcli system coredump partition set --enable true


Kann ich das im laufenden betrieb machen, oder muss ich danach den HOST neu starten oder ähnliches?!

[JustMe]

Voellig richtig. So steht's ja auch in dem von Dir verlinkten ersten KB-Artikel
Ggfs. beim Eingeben auf der Kommandozeile darauf achten, die : zu "escapen".

Wg. dem Reboot triffst Du mich jetzt unvorbereitet...
Ich meine, ein Reboot waere nicht noetig. Der KB-Artikel erwaehnt sowas nicht, und laut Punkt 6. soll man ja auch gleich validieren (koennen), ob die Diagnostic Partition auch als solche gefuehrt wird.

[ohhmille]

GEIL! Das war´s

~ # esxcli system coredump partition list
Name Path Active Configured
---------------------- ------------------------------------------ ------ ----------
mpx.vmhba32:C0:T0:L0:7 /vmfs/devices/disks/mpx.vmhba32:C0:T0:L0:7 true true
~ #

Die Meldung im vSphere Client bleibt noch stehen, bis man den Management Agent neu startet. Hat bei mir knapp 20 Minuten gedauert. Keine Ahnung ob das normal ist. Jedenfalls läuft jetzt alles wieder...
Besten Dnak und grüße
Mille