VMware stürzt bei Linux stress-test regelmäßig ab

[bico]

Hallo,

ich habe folgendes Problem mit meinem VMware esxi4 releasebuild 171294,

Jedesmal wenn ich

Code: Alles auswählen

stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s

eingeben stürzt das System so ab: http://yfrog.com/16errorawj

ist das ein Bug oder wie kann ich das verhindern? Das irgendwie doof, wenn das System so "instabil" ist.

cheerio
bico

[Dayworker]

Der TPM-Eintrag macht mich allerdings etwas stutzig. Poste doch bitte mehr Infos zum Host.

[bico]

es handelt sich um einen i7-920 mit 24gb ram und supermicro board, habe heute wieder einiges rumgespielt und der server stürzt weiterhin bei stresstests - auch mit nur 4vCPUs z.b. ab. Ich bin mit meinem Latein am Ende - das Problem betrifft den ganzen Host, der dann aufeinmal nicht mehr reagiert und eben diesen "pink-screen" hat und resetted werden muss.

Ich verstehe die Fehlermeldung genauso wenig, warum es dieses Problem gibt, dachte bis jetzt vmware wäre sehr stabil.

[bico]

http://kb.vmware.com/selfservice/micros ... Id=1011452

hilft leider auch nicht weiter...

[bico]

warum stürzt also das komplette system ab? wie kann ich das verhindern ? keiner ne idee?

[Dayworker]

Gute Frage. Da der ESXi ja kein OS im herkömmlichen Sinne hat, lassen sich solche Tests nur in einer VM austesten. Womit läßt du also deine Stress-Tests laufen? Wie sieht dazu die VMX aus?
Hast du parallel mal eine Anfrage dazu im VMTN gestellt?
Hast du den Host mal mit einem herkömmlichen OS unter den Stress-Test gestellt, gabs da auch Probleme? Steht sämtliche HW eigentlich auf der VMware-HCL?

[edit]
Seh ich ja jetzt erst.

auch mit nur 4vCPUs

Der ESXi4 unterstützt bis auf die Enterprise-Plus anscheinend nur 4 vCPUs und diese gibt es meines Wissens nach nur mit SnS. Damit solltest du problemlos ein Ticket bei VMware auslösen können.
Da dieses Forum nur ein "inoffizielles, unabhängiges deutsches VMware-Forum" ist, haben wir keinen Zugriff auf VMware-Ressourcen und kennen daher auch nicht für alle Probleme eine Lösung; LEIDER.

[bico]

Hallo,

habe schon ein offizielles ticket erstellt, aber noch kein feedback erhalten:

http://communities.vmware.com/thread/244303

die hardware ist komplett unterstützt - ich habe sogar exakt die gleiche hardware bereits im einsatz und da lief es ohne probleme. auch exakt mit gleichen VMs und gleichen Kernels der VMs. Ich habe auch komplett den Server ohne VMware installiert mit normalen Debian Linux 5 64Bit - ebenso wie auf den VMs läuft - und stresstest ohne Probleme/Absturz machen können. Der Fehler muss also irgendwo bei VMware liegen - wie wo was - keine Ahnung. Ob es an einer Einstellung im Bios liegt weiß ich leider auch nicht. Darum ist das Bios von mir auch auf defaults gesetzt worden und nur VT-D enabled worden, aber auch hier stürzt der HOST nach Stresstest mit VM wieder ab. Wenn der Host nun live geht weiß ich nicht ob die Abstürze an der hohen CPU-Auslastung liegen, an nem Bug im stress programm oder im Hostprogramm - dumm auch dass eine VM das komplette System damit down setzen kann, das darf nicht sein.

da ich exakt gleiche hw bereits mit VMware live habe, und auch zick stresstests erfolgreich durchgeführt, wundert mich dieses verhalten. auf beiden system läuft exakt das gleiche build - beide haben exakt die gleiche hw und bios konfig.

[Dayworker]

Wenn beide ESX die gleiche HW und Einstellungen besitzen, kommen nicht mehr viele Dinge infrage.
Hattest du den ESX-Download eigentlich mal auf seine md5-Sig überprüft?

[bla!zilla]

Stinkt nach defekter Hardware. Tausche mal Speicher und teste die CPUs einzeln.

[bico]

es muss an irgendner einstellung die der eine hat und der andere nicht hat liegen. ich kann mir nicht vorstellen dass es an speicher liegt. da das eine system live ist kann ich es nicht einfach mir nichts dir nichts tauschen. eine defekte cpu halt ich für sehr unwahrscheinlich.
gegen ein hw problem spricht, dass wenn ich auf dem system normales linux laufen lasse, ein stresstest ohne absturz verläuft.

[bico]

ich hab jetzt auf das update 1 vom 19.11.2009 mittelst host update utility geupdated....es läuft jetzt build 208167 mit den ganzen vmware firmware updates - insgesamt wurden 8 installiert. ich hab gehofft dass das problem dadurch verschwindet - der tpmerror ist tatsächlich damit verschwunden, allerdings kommt ein neuer - genau dann wenn ich stress test mache - kann mir jmd endlich helfen den fehler zu diagnostizieren mittels logfiles - leider ist in der vmware community überhaupt keine hilfsbereitschaft.

http://yfrog.com/5cnewerrorj

pls help!


edit
vmware vm memtest:
http://img37.imageshack.us/i/memtestonvm.jpg/

vmware fehlermeldung dabei:
http://img37.imageshack.us/i/memtestonhost.jpg/

und dann stürzt er ab...

hab den host jetzt mal einen memtest86+ unterzogen, er bleibt da bei 12 Min einfach eingefroren - ohne Fehlermeldung hängen...:
http://yfrog.com/7gmemtestonhost2j

iwas stimmt bei der virtualisierung des rams also nicht in vmware... hmmm...?



zu edit2:

mit24gb
habe jetzt alle cores bis auf einen deaktiviert und zunächst mal normalen stresstest machen lassen, sowie memtest - er bringt mir auch da zwar errors, stürzt aber nicht ab - zumindenst nach 20 min errorposting (588 errors)


danach mit24gb
punkt1
habe jetzt alle cores wieder aktiviert und genau das gleiche mit stresstest und memtest gemacht (sind 2vms am laufen, die eine macht stresstest, die andere memtest) und siehe da es brauch nicht mal 2 min da stürzt er ab

also hab ich mal alle rammodule durchgetestet, bei meinem glück war es gleich das erste. ich hab also nur noch 20gb verbaut gehabt, genau das gleiche wie mit punkt1 gemacht und siehe da - auch kein absturz - verhält sich also ähnlich wie 24gb ram mit nur 1 core...

also hab ich mal das letzte rammodul als einziges eingebaut und wollte punkt1 wiederholen - aber das mainboard hat nur das supermicro logo gezeigt, aber nichtmal mehr gebooted ... das ist deutlich indiz für mich das dieser ramriegel wo nen batscher hat.

sicherheitshalber hab ich grad nochmal einen xbeliebigen den ich vermute dass er okay ist, eingesetzt und mache punkt1 ... und nach 5 min - 2x stresstest während auf anderen vm ständig memtest lief - kein einziger error und absturz. einzige was komisch ist, dass der memtest, welcher auf einer vm läuft, zwar kontinuierlich fortläuft, aber es irgendwie lagged. d.h. die zeitanzeige ist nicht fortlaufend sondern 2:31 min ... dann 3:14 min usw .... ich vermute mal es liegt daran dass der vm 4 gb ram hat und im system insgesamt auch nur 4 gb ram verbaut sind und er daher engpässe hat? falls das aber auch ein anzeichen für defekten ram ist müsste ich alles wieder von vorne machen... was meint ihr? ich verweis mal eher auf mein fazit


FAZIT: vielen dank für die hilfe - ich vermute dass es der ramriegel ist - ich werde mir jetzt diesen vom händler überprüfen und austauschen lassen und hoffen dass alles dann funktioniert.

[Dayworker]

Wie von "bla!zilla" schon gesagt, teste bitte mal einzeln Speicher und CPU. Mehr können wir an der Stelle nicht aus deinem PSOD herauslesen und dazu mußt du auch nicht dein Live-System plündern. Einfach ein Speicher raus, testen und dann das gleiche Spiel mit nur einer CPU. Damit hast du wenigstens Werte, um die HW notfalls reklamieren zu können.
Hast du eigentlich mal das Support-Script gestartet und den generierten Report inklu DMP-File an VMware geschickt?

[edit]
Seh mir grad dein edit an.

[edit2]
Ein Memtest auf dem Host mit aktivierten Caches und im Channel-Modus ist leider nutzlos, da die Fehleradresse dabei verdeckt wird und/oder der Speicherfehler scheinbar wahllos über den gesamten Speicher wandert. Lass den Memtest mal mit nur einem Modul und nur im ersten Speicherslot bei deaktivierten Caches laufen und teste dann alle Module durch. Wie mir gerade wieder einfällt, kann es bei der Architektur des Core i7 auch nicht schaden, alle Tests mit nur einer CPU zu absolvieren, da der Speicherkontroller ja mit auf dem Die sitzt.

[jf2]

sicherheitshalber hab ich grad nochmal einen xbeliebigen den ich vermute dass er okay ist, eingesetzt und mache punkt1 ... und nach 5 min - 2x stresstest während auf anderen vm ständig memtest lief - kein einziger error und absturz. einzige was komisch ist, dass der memtest, welcher auf einer vm läuft, zwar kontinuierlich fortläuft, aber es irgendwie lagged. d.h. die zeitanzeige ist nicht fortlaufend sondern 2:31 min ... dann 3:14 min usw .... ich vermute mal es liegt daran dass der vm 4 gb ram hat und im system insgesamt auch nur 4 gb ram verbaut sind und er daher engpässe hat? falls das aber auch ein anzeichen für defekten ram ist müsste ich alles wieder von vorne machen... was meint ihr? ich verweis mal eher auf mein fazit

Wenn Du mit 4GB im ESXi-Host eine VM mit 4GB startest und dort einen Memtest machst swapt sicher der ESXi, man sollte im vsphere-client sehen (beim Host "Leistung" -> "Arbeitsspeicher") das "Verwendeter Auslagerungsspeicher" (zu deutsch: eine Swapdatei) benutzt wird. Das sollte die springende Zeit erklären. Wenn Du der VM mal nur 3GB gibst (oder 7GB bei 8GB installiertem Speicher) sollte das dann aber nicht mehr passieren.

[bla!zilla]

Bitte geh mal systematisch an die Sache ran:

Speicher testen. Wenn Fehler auftreten versuchen das defekte Modul zu identifizieren.

Anders wird es nicht klappen. Die Vermutung, dass es am Speicher liegt, liegt sehr nahe. Wenn eine Kiste unter Last wegklappt, dann ist es zu 99% defekte Hardware.