Seite 1 von 1
Gibt es ein HDD Check (Sektor-Check) für ESXI ??
Verfasst: 04.08.2014, 21:58
von 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.
Verfasst: 05.08.2014, 08:36
von ~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.
Verfasst: 05.08.2014, 10:02
von 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.
Verfasst: 05.08.2014, 10:26
von irix
Bitte nochmal klarstellen ob man ein Problem mit dem Dateisystem des GuestOS oder des VMFS vermutet hat.
Gruss
Joerg
Verfasst: 05.08.2014, 10:38
von 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.
Verfasst: 05.08.2014, 10:48
von 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 disabledDamit 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...
Verfasst: 05.08.2014, 11:33
von 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.
Verfasst: 05.08.2014, 11:53
von lord_icon
Dayworker hat geschrieben: "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 (?)
Verfasst: 05.08.2014, 12:48
von 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.
Verfasst: 05.08.2014, 12:52
von 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 ?
Verfasst: 05.08.2014, 18:41
von 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.
Verfasst: 06.08.2014, 01:04
von 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
Verfasst: 06.08.2014, 12:42
von 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
Verfasst: 31.08.2014, 21:30
von lord_icon
ICh habe das Problem nun glaube ich finden können.
Mein Switch meldet:
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 ?