Massive Probleme VMware Server 2.0.2 & CentOS 5.4 64-Bit

[PatrickW]

Hallo zusammen,

ich habe massive Probleme mit meinem VMware Server.

Hardware:
Hetzner EQ4 Root mit Core i7 920, 8GB RAM und 2x 750GB Samsung HDDs im Software Raid1.

Kernel Version: 2.6.18-164.e15
VMware Server Version: 2.0.2 Build 203138

So nun zu den Problemen:

Zum einen schmiert andauernd der Webaccess ab, dazu habe ich zwar hier schon im Forum eine Lösung gefunden, allerdings hat diese bei mir nicht funktioniert, weil anscheinend noch Abhängigkeiten gab die er nicht ändern konnte.

Zum anderen schalten sich die VMs die ich dort habe einfach aus.
Das betrifft 2 Windows Server 2003 R2 Standard (1x 32-Bit und 1x 64-Bit).
Der 32-Bit hat 384MB RAM und eine vCPU, der 64-Bit hat 1,5GB RAM und eine vCPU.

Beide haben wachsende Festplatten und eine Netzwerkkarte ins Host-only Netz.

http://www.file-upload.net/download-2101233/hostd-7.log.html

Dort habe ich das Hostd.log hin hochgeladen, falls ihr noch andere Logs benötigt sagt Bescheid.

MfG Patrick

[Dayworker]

Mitwachsende (Spare-Disk) Platten sind ein häufiges Ärgernis und bedürfen der regelmäßigen bzw besser wöchentlichen Pflege in Form des Shrinkens der v.HDD. Ansonsten können die Platten bis zur Unbenutzbarkeit einschlafen und meistens läßt sich dann die VM auch nicht mehr starten.

Dein hostd7-Log hilft bestimmt noch, allerdings wäre momentan das "vmware.log" wesentlich aussagekräftiger.

[PatrickW]

Erstmal frohe Weihnachten.

Hier der Link zu den Log-files der VMs:
http://www.file-upload.net/download-2102007/Logs.zip.html

Ich habe sowohl die VMX-Dateien als auch alle VMware-Logs in die ZIP gepackt, sortiert nach den Systemen von denen die kommen.

[PatrickW]

Hat keiner eine Idee wo dran das liegen kann?

[Dayworker]

Also die "vmware/-0.log" haben keine Probleme und beide VMs sind auch normal beendet worden. Die Logs sind leider nicht sehr synchron und der Vergleich gestaltet sich relativ schwierig. Die "vmware-1/-2.log" beider VMs enthalten jedoch ein "Dec 24 02:30:14.746: Worker#1| Caught signal 6 -- tid abcd" und führen danach jeweils einer Auflistung folgender Lib's durch:

Dec 24 02:09:43.908: Worker#1| Caught signal 6 -- tid 4682
...
Dec 24 02:09:44.197: Worker#1| SymBacktrace[0] 0000000042e31810 rip=000000000041521c in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[1] 0000000042e31830 rip=0000000000468cf5 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[2] 0000000042e31920 rip=00000037ea40e7c0 in function (null) in object /lib64/libpthread.so.0 loaded at 00000037ea400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[3] 0000000042e31d68 rip=00000037e9c30265 in function gsignal in object /lib64/libc.so.6 loaded at 00000037e9c00000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[4] 0000000042e31d70 rip=00000037e9c31d10 in function abort in object /lib64/libc.so.6 loaded at 00000037e9c00000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[5] 0000000042e31eb0 rip=00000037e9c75d17 in function (null) in object /lib64/libc.so.6 loaded at 00000037e9c00000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[6] 0000000042e31ef0 rip=00000037e9c727c1 in function cfree in object /lib64/libc.so.6 loaded at 00000037e9c00000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[7] 0000000042e31f30 rip=000000000047eb93 in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[8] 0000000042e31fa0 rip=000000000054cc9b in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[9] 0000000042e31fc0 rip=00000000004f165d in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[10] 0000000042e32010 rip=00000000004f186c in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[11] 0000000042e32040 rip=000000000048542a in function (null) in object /usr/lib/vmware/bin/vmware-vmx loaded at 0000000000400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[12] 0000000042e32140 rip=00000037ea4064a7 in function (null) in object /lib64/libpthread.so.0 loaded at 00000037ea400000
Dec 24 02:09:44.197: Worker#1| SymBacktrace[13] 0000000042e32260 rip=00000037e9cd3c2d in function clone in object /lib64/libc.so.6 loaded at 00000037e9c00000
Dec 24 02:09:44.197: Worker#1| Unexpected signal: 6.

Die Libs /lib64/libpthread.so.0 und /lib64/libc.so.6 sind leider recht beliebt bei verschiedenen Problemen und treten öfter mal im Zusammenspiel mit fehlenden ia32-Lib's auf. Die ia32-Lib's sollten eigentlich auf deinem 64bit-Host vollkommen unnötig sein, aber wer weiß vofür das doch wieder gebraucht wird...

Dec 24 04:09:45.415: vmx| It appears that other virtual machines are running. Some host devices may be unavailable to this virtual machine. Some host devices (such as CD-ROM drives) may be shared among several virtual machines by toggling the entries in the "VM > Removable Devices" menu.

Bedeutet, daß beide VMs um das optische Laufwerk im Host konkurrieren und eigentlich sollte das keine Probleme machen. Da das CD-ROM aber nicht gebraucht wird und ISO's von HDD dazu auch wesentlich schneller sind, würde ich bei beiden VMs die Einbindung des Host-CD-ROMs abschalten. Mit etwas Glück löst das ja schon das Problem.

Hast du in der Zwischenzeit mal einen Dateisystemcheck auf dem Host angestossen

[PatrickW]

Moin,

einen Dateisystemcheck habe ich noch nicht angestossen.

Ich bin allerdings nochmal eine Anleitung durch gegangen, wo es um Probleme mit dem Webaccess ging, in diese Zug habe ich dann auch etwas in der vmware-hostd umgestellt.

Hier der Link aus dem Forum:
Link

Habe nur Schirtt eins gemacht.

Die beiden VMs erkennen gar kein Host Laufwerk, welches ich als CD/DVD Laufwerk verbinden könnte. Beide greifen auf ISOs zu.

Bisher laufen auch beide VMs ohne Probleme.

Ich werde nochmal einen Filesystemcheck anstoßen.

MfG

[Dayworker]

Die "vmware-hostd" ist bei mir eine ausführbare Datei, was soll man da ändern?

Okay, du nutzt also ISOs, aber weshalb bekommst du dann folgende Meldung:

Dec 24 04:09:45.415: vmx| It appears that other virtual machines are running. Some host devices may be unavailable to this virtual machine. Some host devices (such as CD-ROM drives) may be shared among several virtual machines by toggling the entries in the "VM > Removable Devices" menu.

Irgendein Gerät hast du anscheinend in beiden VMs aktiviert, könnte natürlich auch ein USB-Gerät oä sein.

Ich hab die Logs nochmal nach dem Signal 6 verglichen und der Wert vom eip-Register ist gleich. Damit kommen in meinen Augen nicht mehr viele Fehler infrage, ich tippe mal in der Reihenfolge auf Dateisystem-, Lib- oder RAM-Fehler.

[PatrickW]

Eine Down-Time für einen Dateisystemcheck habe ich nächste Woche, werde das Ergebnis dann heir posten.

[MarkyGoldstein]

Wir haben auch Probleme mit sich ausschaltenden vmware 2.0.2 Servern. Wir haben den Verdacht, dass es mit HD's zu tun hat. Beide Server sind bei uns Red Hat, auch der Host, und die beiden Server haben Daten-intensive Applikationen (MySQL und Berklee DBs).

Alle Infos zu diesen Problemen sind willkommen. Wir brauchen unbedingt Stabilität.

[PatrickW]

Also bie mir machen die beiden VMs Domaincontroller und Exchange.

[Dayworker]

Hmm. Red Hat und CentOS sind Geschwister und beruhen auf der selben Code-Basis, da wird ein Fehler auch im anderen vorhanden sein. Wenn die VMs bei "MarkyGoldstein" auch mit Signal 6 abschmieren und wieder die gleichen Libs im "vmware.log" auftauchen, ist die Ursache in meinen Augen wohl gefunden und ein Bug-Report angezeigt.

[sparrow]

Hallo,

bei CentOS (und vllt. auch RHEL) gibt es ein Problem mit der eingesetzten glibc auf dem System. Bei CentOS kommt dies bei Version 5.4 vor.

Ein Workaround gibt es hier: http://vmware-forum.de/viewtopic.php?t=18422
Im Prinzip geht es darum vmware-server2 (und _nicht_ dem kompletten System) die glibc aus der CentOS Version 5.3 zur Verfügung zu stellen.

Probleme die bei mir vorher auftraten:
Das Web-Interface war absolut unbrauchbar da es sich nach einigen Sekunden aufgehängt hat.
Ein Client der unter sehr viel Streß stand ging manchmal einfach aus.

Beide Probleme sind nicht mehr da seitdem die 'alte' glibc eingesetzt wird.
Bisher keine Stabilitätsprobleme auf einem DELL PowerEdge 1950 (oder 1900? irgend so etwas). Neustarts gibts nur bei Kernelupdates.

Ich helfe bei Problemen unter CentOS gerne weiter. Allerdings lese ich hier nicht jeden Tag. Im Zweifelsfall per PM auf den Thread hinweisen.

Gruß
sparrow

[sparrow]

Zum einen schmiert andauernd der Webaccess ab, dazu habe ich zwar hier schon im Forum eine Lösung gefunden, allerdings hat diese bei mir nicht funktioniert, weil anscheinend noch Abhängigkeiten gab die er nicht ändern konnte.

Zum anderen schalten sich die VMs die ich dort habe einfach aus.
Das betrifft 2 Windows Server 2003 R2 Standard (1x 32-Bit und 1x 64-Bit).
Der 32-Bit hat 384MB RAM und eine vCPU, der 64-Bit hat 1,5GB RAM und eine vCPU.

Beide Probleme lassen sich mit dem von mir oben verlinkten Workaround vermeiden.
Natürlich kannst du die alte glibc nicht einfach per Paketmanager installieren.

Solltest du da Fragen oder Schwierigkeiten haben: Frag hier einfach ich helfe gerne.
Das ist eine Sache von 20 Minuten und anschließender Neustart vom vmware-server.

[MarkyGoldstein]

Also wer Probleme mit Stabilität von vmware Server 2.0.2 unter Linux hat, sollte unbedingt diese Lösung anschauen:

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

"The FIX:

yum downgrade glibc glibc-common

It will remove/revert about 22 Packages/Dependencies. I then rebooted and re-ran vmware-config and every thing functions again. Note you need to change your yum update config so that it doesnt push down the newer glibc glibc-common until this issue gets official resolved."