[solved] Instabile VMs

[hansfx]

Hi,


ich habe jetzt seit 3 Wochen einen ESXi Server laufen, den ich am Wochenende auch immer durchstarte.
HW: Q9550 mit 16GB Ram, der für das Board auch zertifiziert ist.
Es laufen aktuell 4 XP VMs drin, die Speicherlast beträgt 12 GB und die CPU Last konstante 50%-60%

Mein Problem ist, dass ich seit dieser Woche unkontrollierte Abstürze von Programmen in meinen VMs habe.
Java-Programme (HS_err pid Log da) oder andere Windows Programme. Die Programme und VMs habe ich schon seit über einem Jahr im Einsatz, zuvor auf VMWare Server 2.0 und sind bis data extrem stabil gelaufen.
Interessant war, dass besagtes Java-Programm in 2 VMs zur gleichen Zeit abgestürzt ist.
Die VMs an sich erzeugen auch nicht viel Last.

Für mich deutet das auf ein Speicherproblem hin. Am ESXi in den Logs sehe nur nix.
Müsste der da nicht auch Probleme bekommen bzw. machen ?

Ich bin jetzt etwas ratlos, was die Fehlersuche angeht.
Ist ein MemTest innerhalb der VM z.B. sinnvoll ?
Bei meinem letzten Hardwareproblem unter VMWare Server ist mir die ganze Kiste stehen geblieben, also richtig eingefroren.

Ich hätte jetzt zunächst erstmal in allen 4 VMs Prime95 laufen lassen, das für ein paar Stunden,
einfach um mal Last zu simmulieren.
Dann evtl. MemTest in der VM oder gleich am Server selbst - über Nacht.

Sonst Tips was ich machen könnte ?


Danke, Hans.

[Martin]

Memtest in der VM macht keinen Sinn, da Du keine Möglichkeit hast, aus dem Ergebnis auf das betroffene Speichermodul zu schließen. Ich würde mit einem Memtest auf dem Server selbst beginnen.

[hansfx]

Ja, richtig.

Da ich das ganze aber nur am Wochenende machen kann,
war das der Versuch die Tage bis dahin evtl. schon was erkennen zu können.

[hansfx]

Kaum erzeuge ich Last per Prime95 in meinen 4 VMs (Host zu 100% dicht),

dann kommen auch paar Logeinträge, die ich nicht deuten kann:

Code: Alles auswählen

[2010-02-17 18:11:47.038 15295B90 verbose 'vm:/vmfs/volumes/4b6ab0ad-2b32a199-7ec3-001b214da07a/XPProf_TS5/XPProf_TS5.vmx'] Updating current heartbeatStatus: green
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 config.annotation
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 config.files.vmPathName
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 config.guestFullName
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 config.uuid
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 guest.hostName
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 guest.ipAddress
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 name
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 recentTask
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 runtime.connectionState
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 runtime.host
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 runtime.powerState
[2010-02-17 18:11:47.039 15295B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 runtime.recordReplayState
[2010-02-17 18:11:47.041 152D6B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 name
[2010-02-17 18:11:47.042 152D6B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 parent
[2010-02-17 18:11:47.042 152D6B90 verbose 'PropertyJournal'] ERProviderImpl<BaseT>::_GetChanges: Aggregate version Overflow 128 resourcePool


Kann mir das jemand deuten ?

[hansfx]

Hat evtl. einer einen Tip für mich, wo ich Informationen zu den Messages finden kann ?

Google hilft hier mal nicht weiter.
Die Doku von VMWare noch nicht, da bin ich zumindest noch nicht fündig geworden.

[Dayworker]

Du kannst es im VMTN probieren, viel Hoffnung würde ich mir aber nicht machen. Eine Erklärung zur Funktion sämtlicher Einstellungen in einer VM gibt es offiziell auch nicht oder wird aus Supportgründen zurückgehalten...

[continuum]

Hat die VM vielleicht 347 snapshots ?

[hansfx]

Also ich hab keine Snapshots angelegt.
Es ist eine Std.Installation des ESXi 4.1U, die seit 3 Wochen jetzt läuft.
In den Datastores sehe ich auch keine unüblichen Files.
Muss zugeben, weis nicht wie ich jetzt rausfinden kann ob da Snapshots angelegt werden

Interessanterweise sind die Einträge jetzt verschwunden, es wechselt einzig der HeartBeat Status immer von gelb auf grün, abwechselnd für jede VM mal.

Ich tippe darauf, dass durch meinen extremen Lasttest die VMs einfach nicht mehr in der vorgegebenen Zeit geantwortet haben und dann entstand das ganze.
4 mal Prime95 und die CPU war wirklich dicht, bei 12 GB verwendetem RAM.
Aber über eine Stunde stabil.

In einem VMWare.log habe ich das noch gefunden, ziemlich häufig sogar:

Code: Alles auswählen

Feb 19 11:20:29.348: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
Feb 19 11:20:33.352: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
Feb 19 11:20:37.359: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip
Feb 19 11:20:41.362: mks| Restoring cursor bypass 3 from vm which took 3->2->3 roundtrip


In den anderen VMLogs nix zu dem Datum.

Und in dem Systemlogs war einzig diese Meldung verdächtig:

Code: Alles auswählen

Feb 19 08:47:10 vmkernel: 5:22:20:41.237 cpu3:1746819)WARNING: VFAT: 154: File_Ioctl


Die macht mir sorgen, da lese ich daraus, dass eine HDD evtl. einen defekt hat.
Jetzt weis ich nur nicht wie ich das Prüfen kann, sind 2 Samsungs HDDs.

[hansfx]

Update hier der Vollständigkeit.

Das Problem war ein Speicherproblem. Im Ram Riegel waren nicht ganz korrekte Timings eingetragen, was Memtest dann nach 2h Laufzeit auch zeigte.
Habs mit Support von OCZ herausgefunden und korrigieren können.

Das dürfte die Abstürze innerhalb der VMs zumindest erklären.