VMware-Forum

Nachdem ich gelegentlch PSOD (ESXi Absturz) Probleme mit dem Areca 1880 Controller unter ESXi 4.1 hatte (was schon öfter berichtet wurde), dachte ich es wäre eine gute Idee auf ESXi 5 zu aktualisieren, da durch das neue Treibermodell auch neue Areca Treiber erstellt werden mussten. Hat auch alles soweit geklappt. Der Treiber musste dann nachträglich per ESXCLI installiert werden, weil VMware den standarmäßig nicht im ESXi Installer integriert hat.

Bei ersten Test kam mir das System recht flott vor, vor allem die VMs anzuhalten und wieder aufzuwecken geht deutlich schneller als bisher. Allerdings gab es plötzlich Probleme beim Klonen von VMs von einem anderen Server auf den Areca Server. Windows 7 VMs wurden plötzlich nur noch im Reparaturmodus gestartet und XP VMs suchten plötzlich "ewig" nach Netzwerken.

Zuerst dachte ich, dass das mit dem Klonen übers Netzwerk zu tun hat. Dann hab ich das innerhalb des Servers selbst probiert und festgestellt, das zwischen bestimmten Volumen reproduzierbar diese Fehler auftreten. Zwischen anderen Volumen funktionierte es. Es handelt sich um insgesamt 10 VMFS3 Volumen. Der Server ist ein Supermicro System (X8DTH-i) mit 16 HD´s und Expansion Backplane, 48 GB RAM und 2*XEON E5620 CPUs. Unter ESXi 4.1 traten solche Fehler nie auf.

Es ist extrem verunsichernd wenn eine Basisfunktionalität wie das Kopieren von Daten nicht 100% zuverlässig funktioniert. Der Fehler tritt sowohl beim Klonen, als auch beim Migrieren und Kopieren über den Dateibrowser auf. Die bisherigen VMs selber scheinen aber bisher noch zu funktionieren (wenn man sie nicht migriert). Weiß nicht was ich jetzt machen soll, da ich die Vmware Tools z.T. schon aktualisiert habe, und deshalb wohl nicht so einfach zu 4.1 zurück komme......

Jemand einen Idee ?

VMware Support ist die Anwort welche du nicht hoeren moechtest.

Ansonnsten, die neuen VMware Tools funktionieren auch auf dem 4.1 ESXi. Einzig wenn du schon das HW Upgrade gemachst hast sieht es schlecht aus bzw. muss Hand angelegt werden an die VMX Dateien.

Gruss
Joerg

irix hat geschrieben:VMware Support ist die Anwort welche du nicht hoeren moechtest.

Ansonnsten, die neuen VMware Tools funktionieren auch auf dem 4.1 ESXi. Einzig wenn du schon das HW Upgrade gemachst hast sieht es schlecht aus bzw. muss Hand angelegt werden an die VMX Dateien.

Gruss
Joerg

Hi Jörg,

das mit den Tools klingt gut. Was für ein HW Upgrade meinst Du ? Die Volumes habe ich unter VMFS3 belassen. Lediglich das BIOS des MB habe ich aktualisiert....

Mit HW Upgrade ist das Virtual Maschine Hardware Upgrade von 7 auf 8 gemeint gewesen. Die Beschreibung als "BIOS Upgrade" hoere ich das erste mal . Aber wir meinen wohl das gleiche da es kein BIOS Upgrade gibt in dem Sinne.

Gruss
Joerg

Mir ist auch gerade aufgefallen, dass die geclonten VMs HW Version 8 haben...Mit BIOS Upgrade meinte ich allerdings tatsächlich das Upgrade des physischen Motherboards.

Die Ausgangsmaschine hatte allerdings auch schon HW Version 8. Insofern kann es nicht an der HW Version liegen....

Die Ausgangsmaschine hatte allerdings auch schon HW Version 8. Insofern kann es nicht an der HW Version liegen....

Dann können diese VMs aber nicht auf vSphere4 gelaufen sein. Die v.HW-Version 8 wurde erst mit vSphere5 bzw Workstation 8 eingeführt.

Beim einem Downgrade muß man eigentlich nur manuell die v.HW-Version in der VMX- und kleinen VMDK-Datei zurückdrehen. Danach ändert sich jedoch die vHW grundlegend und bei einigen OS wird eine erneute Aktivierung fällig.

Diese VM kam ursprünglich von einem vorher eingerichteten ESXi 5 Testserver. Die hab ich dann per VCenter auf den Produktionserver (nach Upgrade auf ESXi 5) geclont. Da fingen dann die Probleme an. Das ging dann auch schon nicht auf jedes Volume fehlerfrei.....

Hast du mal im Areca die Raid-Volumes überprüft?
Wenn es da schon Probleme gibt, ist entweder schon bei der Erstellung der Volumes etwas schief gegangen oder es liegt ein grundsätzliches Treiber-/HW-Problem vor.

Dann würde ich aber davon absehen, daß Teil weiterhin oder überhaupt produktiv einzusetzen und bei Support direkt einen Call bei VMware aufmachen. Ansonsten drehst du dich weiter im Kreis.
Beim Call zum Wochenende hin hilft es dann laut Jörg meist, die 3 berühmten Worte zu sagen.
Nein nicht die sondern: "Die Produktion steht."

Hi Dayworker,

hab die Areca Volumes überprüft. Lasst sich nicht auf bestimmte Volumes eingrenzen. Lief vorher unter 4.1 auch ohne Probleme (außer den gelegentlichen PSODs). Das mit dem HW-/Treiber Problem klingt da schon wahrscheinlicher.

Mach mir jetzt etwas Sorgen um die Datenintegrität der vorhandenen VMs. Noch laufen die Bestehenden, aber wie Du schon sagst: produktiv sollte ich das nicht mehr betreiben. Hätte vorher gerne das Problem isoliert, bevor ich wieder auf 4.1 zurück gehe. Am Montag geht das "richtige" Leben weiter, dann muß das Ding wieder produktiv sein....

Das seltsame ist, das die defekten und die "heilen" VMs keinen Unterschied in der Filesize haben. Windows 7 startet in der "Systemstartreparatur" und kommt da nicht wieder raus. Irgendwas muß sich innerhalb der VMDK verändern, kriege aber nicht raus was.....

Alex

Ob eine VMDK defekt ist oder nicht, kannst du von aussen nicht sehen und solange die VMDK-Struktur nicht beschädigt ist, beschwert sich auch der ESX(i) ist. Es reicht ja wenn ein Bit umgekippt ist und das Gast-OS fällt trotzdem auf die Nase.
Um das aber herauszubekommen, müßtest du einigen Aufwand betreiben. Die VM müßtest du einmal über den DS-Browser und dann noch ein zweites Mal nach dem Einbinden des VMFS in eine Live-CD runterladen und anschließend vergleichen.

Häufige oder auch gelegentliche PSODs zeigen aber immer ein Problem an. Spätestens nach dem zweiten unerwarteten PSOD mit denselbem Fehler sollte jedem klar sein, daß dort etwas oberfaul ist.

Ich hab aber noch einige Threads im Web gefunden, die ein Firmwareupdate nahelegen. Wenn ich mich dabei auch nicht verlesen habe, scheinen Areca 1880 und die LSI 92xx Serie auf den gleichen LSI2108-Chip zu setzen. Nur die Firmware scheint unterschiedlich zu sein.
Eventuell läßt sich hier sogar die LSI-Firmware einspielen, wenn du noch weitere 1880-Controller da hast.


[add1]
In solchen Szenarien dürfte auch irgendwann mal die große Stunde von BTRFS schlagen. Das geht ja immer davon aus, daß die Daten falsch geschrieben wurden und vergleicht dazu fortlaufend deren Checksummen mit den an verschieden Stellen im Dateisystem hinterlegten Kopien.


[add2]
Beim Thema BTRFS fällt mir gerade noch etwas ein.
Hast du den Controller-Cache mal deaktiviert?


[add3]
Über BTRFS würden sich dann sogar Datenfehler bei Fake-Raid-Controllern finden lassen, da diese ja den Arbeitsspeicher als Plattencache verwenden.

Dayworker hat geschrieben:[add1]
In solchen Szenarien dürfte auch irgendwann mal die große Stunde von BTRFS schlagen. Das geht ja immer davon aus, daß die Daten falsch geschrieben wurden und vergleicht dazu fortlaufend deren Checksummen mit den an verschieden Stellen im Dateisystem hinterlegten Kopien.

Da brauchst du nicht zu warten, solche Funktionalitäten bringt ZFS jetzt schon mit. Daher probier' mal aus ein openindiana mit einem ZFS für einen Datenpool in eine VM zu installieren und diesen Pool zu klonen, um ihn dann in eine andere frisch aufgesetzte openindiana-VM zu importieren. Ein Scrub-Durchlauf zeigt dir dann evtl. Fehler.

Edit: Und repariert sie sofort bei entsprechender Redundanz.

Hab das heute nochmal gecheckt und es scheint so das es speziell Probleme mit VMs und VMFS 3.46 Volumes unter ESXi 5 (übernommen von 4.1) mit 8MB Blockgröße gibt, die dann auf ein Volumen mit 4 MB Blockgröße geklont werden. Um das zu überprüfen hab ich die MD5SUM der -flat.vmdk´s ermittelt, und die stimmen dann tatsächlich nicht überein.

Scheint auch bei 4 MB auf 2 MB Blockgrößen zu passsieren. Werde noch überprüfen, ob das auf einem anderen Server auch passiert (oder wenn noch jemand so eine Konstellation hat; immer her mit den Ergebnissen...). Zum Testen hab ich eine minimal W7 32 Bit VM erstellt (HW Version 7). Bei einem kurzen Test mit untern ESXi 5 angelegten VMFS 3.54 Volumes mit LSI Controller gab es übrigens keine Probleme, genauso wenig wie mit neu angelegten VMFS 3.54 Volumes und dem Areca Controller....

Hab heute nochmal diverse Konstellationen auf dem gleichen Server getestet:

ESXi 4.1 mit aktuellem Areca Treiber: Klonen funktioniert mit allen Blockgrößen ohne Probleme (gleiche Volumen und Server wie unter 5.0)

ESXi 5.0 (frisch installiert, ohne Update von 4.1 auf 5.0) mit aktuellem Areca VIB: Klonen funktionert NICHT zwischen verschiedenen Volumes, meistens mit verschiedenen Blockgrößen.

ESXi 5.0 mit LSI 9240 Controller: Keine Probleme beim Klonen, auch mit VMFS 3.46 Volumes verschiedener Blockgrößen....

Firmware auf dem Areca 1880 ist die letzte stable Release. Die Bata Versionen wollte ich nicht testen, um meine Daten nicht noch mehr zu gefährden....

Sehe da z.Z. schwarz für den Areca Controller unter ESXi 5. Werde wohl wieder auf 4.1 zurück müssen und dann volumenweise auf einen LSI 9265i migrieren...Dann wird der Areca nur noch für Linux SANs eingesetzt....