Gibt es ein HDD Check (Sektor-Check) für ESXI ??

[lord_icon]

Moin,

ich habe den zwingenden Verdacht, dass eine meiner festplatten n treffer hat.
Gibt es eine Möglichkeit, diese irgendwie zu prüfen ?

2te Frage:
Welche Log ist denn dafür zuständig. Es gibt ja reichlich.

P.s. Ich denk mal, dass es eine HDD ist, denn das nachfolgende Problem tritt erst auf, wenn ich n Backup über nacht angestoßen hatte. Lass ich es aus, läuft der Server auch früh noch ohne ping verlust.

Vor Reboot ... regelmäßiger ping verlust... nach reboot: nicht einer.

[~thc]

Von einem periodischen Ping-Verlust über einen Backup-Job auf eine defekte physische Festplatte zu schließen, finde ich etwas voreilig.

Ich würde erst mal in das Logfile der VM schauen.

[Dayworker]

Sehe ich auch so. Ich würde erstmal nachsehen, weshalb eine Ping-Antwort bei dir im Schnitt 30ms braucht. Ich bin für die erste Antwort bei 10ms und danach mit Ausreissern bei 1ms.

In meinen Augen hast du ein wodurch auch immer ausgelöstest Netzwerkproblem. Wie "~thc" schon sagte, sieh dir das "vmware.log" dieser VM und auch das Ereignis-Log von Windows an. Es wäre auch hilfreich zu wissen, welche netzwerktechnische HW in Host und Gast zum Einsatz kommt. Deine Aussage von "dass eine meiner festplatten n treffer hat" läßt für mich nur den Umkehrschluß zu, daß bei dir ein Whitebox-System läuft und dadurch verschiedenste Probleme auftreten können, aber nicht müssen.

[irix]

Bitte nochmal klarstellen ob man ein Problem mit dem Dateisystem des GuestOS oder des VMFS vermutet hat.

Gruss
Joerg

[lord_icon]

Nunja.. ich denke schon, dass es was mit den Platten zu tun haben könnte.
Ich hab heute das Acronis Backup wieder nicht gemacht... und es läuft alles.

Aber gut.. bin gern auf der Suche nach alternativen Problemverursachern:

MB: X9DBL-iF (Intel® 82574L GbE LAN, 2 ports)
CPU: E5-2440
HDD: 2 x 1TB WDC Black
2 x 320GB WDC Black
RAID: LSI 9260-4i
vSphere: noch mit 17 Tage Probezeit

Das Ding ist ein Ersatzsystem, was im RZ steht um (normalerweise) fehlerhafte VM (hier aber XEN) umzulegen. Aktuell wurde heir aber ESXI parallel installiert und auch hochgefahren. (ESXI liegt hier auf einen USB 3.0 Usb-Stick)

Die pingzeiten von 30ms sind somit korrekt/normal.

Ich versuch nochmal n Backup zu machen, sodass ich wieder diesen Fehler bekomme und lass dann mal n tail auf "vmware.log" laufen. Mal schaun, was das so bringt.

[lord_icon]

obwohl.. is ja Blödninn, Log's liegen ja vor... genauer Zeitpunkt ja auch:

Lt. shell.log hab ich vorgestern:

Code: Alles auswählen

2014-08-04T19:35:00Z shell[152287]: [root]: reboot
2014-08-04T19:36:24Z SSH: SSH login disabled

Damit hab ich je den genauen Zeitpunkt:
EDIT:... ich hab garkeine vmware.log. Das sind die Datein, die ich in /var/log/ zu liegen habe

Code: Alles auswählen

-rw-------    1 root     root        4.4K Aug  4 23:01 smbios.bin
drwxr-xr-x    1 root     root         512 Aug  4 23:01 .
drwxr-xr-x    1 root     root         512 Aug  4 23:01 ipmi
-rw-r--r--    1 root     root       19.2K Aug  4 22:59 configRP.log
drwxr-xr-x    1 root     root         512 Aug  4 22:59 vmware
-rw-r--r--    1 root     root           0 Aug  4 22:59 esxcli.log
-rw-r--r--    1 root     root         176 Aug  4 22:59 .vmsyslogd.err
-rw-rw-rw-    1 root     root       38.0K Aug  4 22:59 boot.gz
lrwxrwxrwx    1 root     root          21 Aug  4 22:59 Xorg.log -> /scratch/log/Xorg.log
lrwxrwxrwx    1 root     root          21 Aug  4 22:59 auth.log -> /scratch/log/auth.log
lrwxrwxrwx    1 root     root          22 Aug  4 22:59 clomd.log -> /scratch/log/clomd.log
lrwxrwxrwx    1 root     root          25 Aug  4 22:59 dhclient.log -> /scratch/log/dhclient.log
lrwxrwxrwx    1 root     root          26 Aug  4 22:59 esxupdate.log -> /scratch/log/esxupdate.log
lrwxrwxrwx    1 root     root          20 Aug  4 22:59 fdm.log -> /scratch/log/fdm.log
lrwxrwxrwx    1 root     root          28 Aug  4 22:59 hostd-probe.log -> /scratch/log/hostd-probe.log
lrwxrwxrwx    1 root     root          22 Aug  4 22:59 hostd.log -> /scratch/log/hostd.log
lrwxrwxrwx    1 root     root          33 Aug  4 22:59 hostprofiletrace.log -> /scratch/log/hostprofiletrace.log
lrwxrwxrwx    1 root     root          21 Aug  4 22:59 lacp.log -> /scratch/log/lacp.log
lrwxrwxrwx    1 root     root          22 Aug  4 22:59 osfsd.log -> /scratch/log/osfsd.log
lrwxrwxrwx    1 root     root          27 Aug  4 22:59 rhttpproxy.log -> /scratch/log/rhttpproxy.log
lrwxrwxrwx    1 root     root          29 Aug  4 22:59 sdrsinjector.log -> /scratch/log/sdrsinjector.log
lrwxrwxrwx    1 root     root          22 Aug  4 22:59 shell.log -> /scratch/log/shell.log
lrwxrwxrwx    1 root     root          26 Aug  4 22:59 storagerm.log -> /scratch/log/storagerm.log
lrwxrwxrwx    1 root     root          25 Aug  4 22:59 swapobjd.log -> /scratch/log/swapobjd.log
lrwxrwxrwx    1 root     root          23 Aug  4 22:59 syslog.log -> /scratch/log/syslog.log
lrwxrwxrwx    1 root     root          20 Aug  4 22:59 usb.log -> /scratch/log/usb.log
lrwxrwxrwx    1 root     root          24 Aug  4 22:59 vmamqpd.log -> /scratch/log/vmamqpd.log
lrwxrwxrwx    1 root     root          24 Aug  4 22:59 vmauthd.log -> /scratch/log/vmauthd.log
lrwxrwxrwx    1 root     root          26 Aug  4 22:59 vmkdevmgr.log -> /scratch/log/vmkdevmgr.log
lrwxrwxrwx    1 root     root          25 Aug  4 22:59 vmkernel.log -> /scratch/log/vmkernel.log
lrwxrwxrwx    1 root     root          26 Aug  4 22:59 vmkeventd.log -> /scratch/log/vmkeventd.log
lrwxrwxrwx    1 root     root          27 Aug  4 22:59 vmksummary.log -> /scratch/log/vmksummary.log
lrwxrwxrwx    1 root     root          27 Aug  4 22:59 vmkwarning.log -> /scratch/log/vmkwarning.log
lrwxrwxrwx    1 root     root          21 Aug  4 22:59 vobd.log -> /scratch/log/vobd.log
lrwxrwxrwx    1 root     root          23 Aug  4 22:59 vprobe.log -> /scratch/log/vprobe.log
lrwxrwxrwx    1 root     root          24 Aug  4 22:59 vprobed.log -> /scratch/log/vprobed.log
lrwxrwxrwx    1 root     root          21 Aug  4 22:59 vpxa.log -> /scratch/log/vpxa.log
lrwxrwxrwx    1 root     root          19 Aug  4 22:59 vsantraces -> /scratch/vsantraces
lrwxrwxrwx    1 root     root          24 Aug  4 22:59 vsanvpd.log -> /scratch/log/vsanvpd.log
drwxr-xr-x    1 root     root         512 Aug  4 22:59 ..
-rw-------    1 root     root        4.6K Aug  4 22:59 sysboot.log


Warum ich dennoch an die HDD's festhalte ?
vmkwarning.log

Code: Alles auswählen

2014-08-04T19:00:34.852Z cpu6:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:05:34.848Z cpu0:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:10:34.848Z cpu2:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:15:34.852Z cpu9:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:20:34.852Z cpu2:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:21:56.416Z cpu5:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD3200YS2D01PGB0__________________________WD2DWCAPD2754714" state in doubt; requested fast path state update...
2014-08-04T19:21:56.686Z cpu5:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:25:34.852Z cpu4:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...
2014-08-04T19:30:34.848Z cpu1:33458)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "t10.ATA_____WDC_WD800JD2D08MSA1___________________________WD2DWMAM9LF06790" state in doubt; requested fast path state update...



[Dayworker]

Das "vmware.log" liegt immer im Ordner der jeweiligen VM.

Du hättest uns aber auch gleich sagen können, daß du eine "Western Digital Caviar 80GB 7200RPM SATA 1.5Gbps 8MB Cache 3.5-inch" einsetzt. Diese Platte wurde bereits 2009 vorgestellt und damit dürfte auch die Ursache gefunden sein. Sicher alle VMs von dieser Platte und ersetze sie umgehend. Du kannst dann ja mal das WD-Testprogramm drüberlaufen lassen. Da werden dir sicher einige Fehler angezeigt werden.

[lord_icon]

"Western Digital Caviar 80GB 7200RPM SATA 1.5Gbps 8MB Cache 3.5-inch" einsetzt.

Janein... auf der Platte liegt XEN drauf. Die Platte selbst hatte ESXI bei der installation selbst angelegt. Von meiner Seite dann später nur genutzt um win7.iso und debian.iso abzulegen.

Unter "Datenspeicher"habe ich die Platte erstmal unmountet und gelöscht.
Klicke ich auf "Geräte" ist die Platte selbst aber noch gemountet.
Grund ist hier wohl die Diagnostik vom ESXI. Kann ich diese irgendwie verschieben, sodass ich die Platte umounten kann und somit kein Zugriff mehr auf diese Platte erfolgt ?

Bzw. bringt das überhaupt was => Platte trennen. Greift ESXI dann wirklich nicht mehr drauf zu (?)

[Dayworker]

In meinen Augen zuckt der ESXi solange, wie die Platte angesteckt ist. Nur weil die Platte als DS verworfen wurde, ist sie ja trotzdem noch vorhanden und ein Unmount hält auch nur bis zum nächsten ESXi-Reboot.

[lord_icon]

jupp... dass hatte ich auch schon vermutet. Schade.
Nun gut. Dann muß ich mal RemoutHands im RZ bestellen.

Die Grundsatzfrage bleibt aber: Bisher sind es ja nur vermutungen mit der HDD.
SMART hat die Platte offensichtlich noch nicht... zumindest bekomm ich nur einen Fehler zurück.

Hat denn bzw. gibt es denn ein Tool, was ich auf ESXI Shell zum laufen bringen kann, der mir einen Sektor Test macht ?

[Dayworker]

Von VMware gibt es offiziell zwar ein VMFS-Testtool, das dir aber nicht weiterhilft, da du damit nur testen aber nicht reparieren kannst. Unser "continuum" hatte und meckert das noch immer bei VMware an, für die Öffentlichkeit hat sich bisher aber noch nichts geändert.
Bau halt die Platte aus und teste sie auf einem lokalen Rechner in einem externen Laufwerksgehäuse. Dann weißt du es ganz genau.

[continuum]

Ein primitiver Test der Platte lässt sich so machen:

dd if=/dev/disks/t10.ATA.... of=/dev/null

läuft der Befehl komplett durch hat die Platte keine defekten Blöcke

[kastlr]

Hallo,

hast du denn mal ein Filesystem Check in der VM durchgeführt?
Sofern der keine Probleme meldet sollte auch die Platte eigentlich i. O. sein.

Und hast du mal versucht, die SMART Parameter der Platte direkt auszulesen?
ESXi S.M.A.R.T. health monitoring for hard drives

Finden sich in den vmkernel/vmkwarning.logs denn SCSI Fehler?
Denn diese Pfad Fehler bedeuten eigentlich, das ein vorangegangenes TUR (Test Unit Ready) nicht innerhalb der Wartezeit beantwortet worden ist.

Du kannst ja mal einen SCSI Rescan durchführen,vielleicht zeigt der ja Wirkung.

Gruß,
Ralf

[lord_icon]

ICh habe das Problem nun glaube ich finden können.

Mein Switch meldet:

Code: Alles auswählen

High Collision or Drop Rate on port 24


Als Lösung wird mir folgendes Vorgeschlagen:

Description:
A large number of collisions or packet drops have occurred on port 24.

Possible causes:
The possible causes include an extremely high level of traffic on port 24, half/full duplex mismatch, a misconfigured or malfunctioning NIC or transceiver on a device connected to this port, or a topology loop in the network.

Actions:

Use a network monitoring device or application to determine the traffic levels on the affected segment. If needed, consider subdividing that segment with switches or bridges, or moving high-traffic devices to their own switch ports.
Check the directly-connected device for mismatches in half/full duplex operation (half duplex on the switch and full duplex on the connected device).
Check for a misconfigured NIC or transceiver (such as a transceiver configured for "loopback test" or "SQE test").
Also, verify that there are no topology loops in your network. If not enabled, you may also enable Spanning Tree.

Port 24 ist der Uplink zum I-net.
Diese "High Collision or Drop Rate" beeinflusst mein ganzen Switch. Alle anderen angeschlossenen Geräte verlieren ihren Ping.
Deaktiviere ich port 19 oder starte den esxi neu, kehr erstmal wieder Ruhe ein... ca. 2 Tage lang. Am Port 19 hängt im Übrigen der ESXi.
Am Switch selbst hängt kein anderes Gerät, wo ein VMWare Produkt läuft.

Weiß einer, wie ich das Problem weiter eingrenzen kann ? ... oder gar beheben ?