I use centoplus kernel 2.6.18-128.7.1.el5. This was the only kernel that make possible to build vmware server 2.0.2 from tar.gz package.

two latest kernel have problem to build the modules (2.6.18-164.2.1.el5 - 2.6.18-164.6.1.el5 )

no modification to glibc until now...4 vms running smoothly without problems..

the only problem is that when i stop vmware-mngt (web interface) i cannot login through vmware infrastructure client..

We see...

SOLUTION #1 (libc-2.5.so reversion)

# cat /etc/issue
CentOS release 5.4 (Final)
Kernel \r on an \m

lynx http://mirror.centos.org/centos/5.3/os/x86_64/CentOS/glibc-2.5-34.x86_64.rpm

rpm -Uvh --root=/tmp/ --nodeps ./glibc-2.5-34.x86_64.rpm

mkdir /usr/lib/vmware/lib/libc.so.6

cp /tmp/lib64/libc-2.5.so /usr/lib/vmware/lib/libc.so.6/libc.so.6

# tail -3 /usr/sbin/vmware-hostd
export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH

eval exec "$DEBUG_CMD" "$binary" "$@"

SOLUTION #2 (Circumventing /usr/sbin/vmware-hostd library wrapping script)

Here is another method alluded to in part by djzort earlier in this thread but djzort's solution failed to find all library paths (causing gui function failures) so I added more and changed /etc/init.d/vmware accordingly. The downside is this method circumvents the dynamic library path building of the /usr/sbin/vmware-hostd script and exucutes the /usr/lib/vmware/bin/vmware-hostd binary directly. I’m not sure if this will present future problems or not. With no reversion changes with libc-2.5.so of the first solution, this solution ran for 12 hours without hostd crashing before I opted to go with the crowd and finally got the right 5.3 version of libc-2.5.so working with hostd. Possibly this added solution might shed more light on what is actually going on as the libc-2.5.so reversion was not required.

Below is the snippet from the modified /etc/init.d/vmware. You can see I added a LD_LIBRARY_PATH statement, commented out the old exec call and added a new one. I derived the paths from dizort’s first post adding that single path to the beginning of the path output of the /usr/sbin/vmware-hostd script.

# Start host agent
vmware_start_hostd() {
export LD_LIBRARY_PATH=/usr/lib/vmware/vmacore:/usr/lib/vmware/hostd:/usr/lib/vmware/lib/libxml2.so.2:/usr/lib/vmware/lib/libexpat.so.0:/usr/lib/vmware/lib/libstdc++.so.6:/usr/lib/vmware/lib/libgcc_s.so.1:/usr/lib/vmware/lib/libcrypto.so.0.9.8:/usr/lib/vmware/lib/libssl.so.0.9.8

vmware_bg_exec "`vmware_product_name` Host Agent" \
"$vmdb_answer_LIBDIR/bin/vmware-hostd" -a -d -u "$vmware_etc_dir/hostd/config.xml"
#"$vmdb_answer_SBINDIR/vmware-hostd" -a -d -u "$vmware_etc_dir/hostd/config.xml"
}

So what in /usr/sbin/vmware-hostd is causing the issue is the question. It would “appear” I’ve essentially done the same thing as the /usr/sbin/vmware-hostd script, with the possible exception of path order. Thoughts?

I have not noticed a performance degradation anywhere.

Thanks!