Probleme mit den vmkfstools

[Klaus_Urban]

Hallo,
ich habe Probleme mit den vmkfstools.

vmkfstools -x check "$Quell_Ordner/F.vmdk" -> Datei OK
vmkfstools -i "$Quell_Ordner/F.vmdk" "$Ziel_Ordner/F.vmdk" -d thin -> Kopie OK
-----------------------------------------------------------------------
vmkfstools -x check "$Ziel_Ordner/F.vmdk" -> Datei OK
vmkfstools -i "$Ziel_Ordner/F.vmdk" "$NFS_Ordner/F.vmdk" -d thin -> Input/output error (327689) bei ca. 55%
Nach einer Wiederholung der gleiche Fehler bei 55%

Bei einer täglichen Kopie kam der Input/output Fehler am 5.1, 19.1, 26.3, 19.4, 23.4, 4.5, 8.5, 10.5, 14.5, 23.5 und 26.05

Starte ich die Ziel_Ordner VM und teste den Inhalt von F.vmdk per chkdsk wird kein Fehler gefunden.
Woran kann es liegen, dass die Kopie der Kopie nicht erstellt werden kann, obwohl die Kopie fehlerfrei funktioniert?

Klaus

Ps.
Am Speicherort liegt es nicht. Wenn der Fehler auftritt, ist es egal worauf die 2. Kopie angelegt wird.

[Dayworker]

Wenn die lokale Kopie keine Fehler bringt, dürfte der Quelldatenträger wohl Okay sein.
Werden zur Kopierzeit auch Verbindungsabbrüche zum NFS bzw allgemein Netzwerkprobleme geloggt?

[Klaus_Urban]

Hallo Dayworker,

> Wenn die lokale Kopie keine Fehler bringt, dürfte der Quelldatenträger wohl Okay sein.
> Werden zur Kopierzeit auch Verbindungsabbrüche zum NFS bzw allgemein
> Netzwerkprobleme geloggt?

Es gibt keine Verbindungsabbrüche.
Wenn die Kopie fehlschlägt, ist es egal wohin kopiert wird. Auch ein
vmkfstools -i "$Quell_Ordner/F.vmdk" "$Quell_Ordner/F-Neu.vmdk" -d thin
ist Fehlerhaft. Die Fehlerquell muss die 1. Kopie sein, aber leider kann ich dort kein Fehler ermitteln.
Die Notlösung wäre:
Wenn die 2. Kopie nicht erstellt werden kann, dann die 1. Kopie nochmal erstellen.
Das kann natürlich eine Endlosschleife werden.
Oder die 2. Kopie vom Original erstellen. Aber dann muß die VM immer die doppelte Zeit Offline sein.

Klaus

[kastlr]

Hallo Klaus,

unterstützen deine Arrays VAAI und befinden sich Quell und Zielordner des ersten Copyjobs auf dem selben Array?
Wenn ja, würde ich die Nutzung von VAAI mal temporär deaktivieren und dann deine Jobs erneut durchführen.
Denn bei einem VAAI unterstütztem Copy Job meldet das Array dem ESXi Server relativ zügig, das der Copy Job erfolgreich abgeschlossen ist.
In Wahrheit ist das Array aber noch fleißig dabei, die Daten von der Quelle zum Ziel zu kopieren.
Wenn du dann zeitnah deinen zweiten Jobs startest hast du parallel Jobs gegen das erste Zieldevice laufen, und das könnte die Ursache deines Problems sein.

Gruß,
Ralf

[Klaus_Urban]

Hallo Ralf,

> Wenn du dann zeitnah deinen zweiten Jobs startest hast du parallel Jobs gegen das
> erste Zieldevice laufen, und das könnte die Ursache deines Problems sein.

Leider nein. Der Fehler kommt auch, wenn ich die 2. Kopie Stunden später starte.

Klaus

[kastlr]

Hallo Klaus,

sofern dein Array VAAI unterstützt, schalte es mal testweise ab und lass deinen Job noch mal laufen.

Gruß,
Ralf

[Klaus_Urban]

Hallo Ralf,

>sofern dein Array VAAI unterstützt, schalte es mal testweise ab und lass deinen Job noch >mal laufen.

VAAI ist nicht aktiv.

Klaus

[kastlr]

Was sagen denn die vmkernel Logs, die sollten dir eigentlich weiterhelfen.
Darin sollten sich Hinweise auf das eigentliche Problem finden lassen.

Gruß,
Ralf

[Klaus_Urban]

Hallo Ralf,
in den logs finde ich darüber nichts.
Der Server läuft schon ohne Neustart über 6 Monate.
Ich werde ihn demnächst mal neu starten.

Klaus

[Dayworker]

Laß mal bitte das VMware-Reportscript durchlaufen und lad das ZIP dann mal irgendwo hoch.
Ansonsten muß du alle Log's halt selbst mal durchforsten, was bei einem längerlaufenden Server aber zur echten Mammutaufgabe werden kann...

[Klaus_Urban]

Hallo Dayworker,

>Laß mal bitte das VMware-Reportscript durchlaufen

wie?
Funktioniert das bei der ESXi-Free Version?

Btw. Ich konvertiere gerade die Original-Dateien von EagerZeroed Thick nach Thin.
Denn nur bei den EagerZeroed Thick Dateien treten die Probleme auf.

Klaus

[Dayworker]

Schau dir mal den KB-Eintrag Collecting diagnostic information for VMware ESX/ESXi using the vSphere Client (653) an und mit etwas Glück findet sich darin die Ursache.
Ralf aka "kastlr" scheint auch ein leicht masochistische Ader für das Auswerten solcher Logs zu haben. Vielleicht sieht er damit die Ursache auf den Log-Blick.

[Klaus_Urban]

Hallo Dayworker,
ich habe das VMWare-Reportscript erstellt.
Aber nach der Umstelung von EagerZeroed Thick nach Thin trat der Fehler nicht mehr auf.

Klaus