VMWare Server: Erster Start einer VM hängt und wird abgebrochen

[BedriddenTech]

Hallo,

seit ein paar Tagen habe ich Probleme mit meiner VMWare-Installation. Ich habe VMWare Server 1.0.5, darauf eine VM, die beim Systemstart geladen werden soll. Das hat bis zum Mittwoch auch noch prima funktioniert. Jetzt stelle ich das folgende seltsame Verhalten fest: Egal, ob ichs aus der Konsole (vmware-cmd), beim Systemstart (vmware-serverd -s -d) oder mit der GUI versuche, immer bleibt das System eine ganze zeitlang hängen, um danach die VM wieder auf den Zustand "ausgeschaltet" zurückzusetzen. Im Log finde ich dann verschiedenes, aber nichts konkretes, z. B.:


May 10 13:49:12: app| New connection on socket server-vmxvmdb from host localhost (ip address: local) , user: root
May 10 13:49:12: app| Connection from : /srv/vm/gw/gw.vmx
May 10 13:49:12: app| VMServerdConnect: connecting to /srv/vm/gw/gw.vmx
May 10 13:49:12: app| Connected to /srv/vm/gw/gw.vmx
May 10 13:49:13: app| VMServerd IPC closed the connection with thread /srv/vm/gw/gw.vmx (0x8301ac0)
May 10 13:49:13: app| Lost connection to /srv/vm/gw/gw.vmx (/srv/vm/gw/gw.vmx) unexpectedly.
May 10 13:49:13: app| vmdbPipe_Streams Couldn't read: OVL_STATUS_EOF
May 10 13:49:13: app| VMHS: Connection to VM broken: cfg: /srv/vm/gw/gw.vmx; error: Pipe: Read failed; state: 3
May 10 13:49:13: app| VM suddenly changed state: poweredOff.

Oder:


May 08 15:22:33: vmx| ACL_InitCapabilities: here 2 (bug 63252)
May 08 15:22:33: vmx| VUINewControlConnection: after slow ACL gunk (bug 63252).
May 08 15:22:33: vmx| VUI: A new VMControl client connected.
May 08 15:22:33: vmx| IPC version negotiation version: VMX returning 2.1 to servercontrol
May 08 15:22:33: vmx| IPC vmcontrol-temp version: VMX returning 11.4 to servercontrol that tried 11.4
May 08 15:22:40: vmx| VMX IPC closed the connection with thread servercontrol (0x84d0360)
May 08 15:22:40: vmx| VMX: Remote VMControl client servercontrol disconnected.
May 08 15:22:42: vmx| vmdbPipe_Streams Couldn't read: OVL_STATUS_EOF
May 08 15:22:42: vmx| VMXVmdbConnectServerd - Trying to discover serverd
May 08 15:22:57: vmx| Caught signal 15 -- tid 8049 (eip 0xffffe410)

Wenn ichs danach nochmal händisch probiere, gehts. Daß die VM automatisch gestartet wird, macht keinen Unterschied: Andere Maschinen laufen auch erst beim zweiten Mal an, und die werden nicht beim Systemstart mitaktiviert.

An der Installation hatte ich vorher nichts geändert; Kernel ist schon seit Wochen 2.6.23.17, VMWare läuft dank des any-any-update 115. Ich habe versucht, Änderungen rückzuverfolgen, aber ich habe lediglich OpenLDAP und CUPS aktualisiert. Und wie gesagt: Diese Konfiguration funktionierte ohne Probleme bis noch vor kurzem; VMWare habe ich nicht angepackt. Ich habe jetzt natürlich mit Neuinstallation und Rekonfiguration versucht, dem Problem zu Leibe zu rücken, war aber erfolglos. Dateirechte stimmen, und das starten der VM als "root" bringt auch keinen Unterschied.

Das Problem tritt bei allen VM auf, auch bei neu angelegten. Den VMWare-BIOS-Screen bekomme ich nie zu Gesicht; wenns geht, dann bleibt die Anzeige der vmware-sever-console erstmal schwarz, um mir dann schon ein zur Hälfte gestartetetes OS zu zeigen.

Ich habe absolut keine Ahnung, wonach ich suchen könnte. Google habe ich zwar schon gefragt, aber nichts mit meinem Problem vergleichbares gefunden.

[BedriddenTech]

Ok, ich habs selbst gelöst. Die Lösung war... seltsam und unerwartet. Weil ich ja zuletzt den LDAP-Server (und damit auch die libldap und liblber) aktualisiert habe (nämlich von 2.2.x auch 2.3.39), habe ich mir alles angesehen, was irgendwie am LDAP hängt. Unter anderem was das NSS-LDAP-Modul gegen die alten Bibliotheken gelinkt (die aber noch vorhanden waren -- sprich es gab z. B. libldap-2.3.so.0 und libldap-2.2.so.0). Das funktionierte auch, d. h. ein normales "id <benutzer>" lieferte alles korrekt zurück. Gefragt wurde das richtige Verzeichnis, das mittlerweile auch Version 2.3.39 war.

Anscheinend war genau das ein Problem. Nachdem ich auch das NSS-LDAP-Modul erneuert hatte (die neuere Version linkte gegen die 2.3er-Bibliotheken), lief alles wie geschmiert. Ich bin dann direkt auf nss-ldapd umgestiegen, aber das hatte keinen weiteren Einfluß -- das Problem lag tatsächlich an der alten Version der Bibliotheken.

So, möge das irgendjemand anderem mit einem ähnlichen Problem hoffentlich eine Hilfe sein. :)