i just upgrade my centos box server..
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..
used libc2-5.so from glibc-2.5-24.el5_2.2.x86_64.rpm ( centos 5.2 updates )
works for me
Just to confirm that I am getting this after upgrading to Centos 5.4 - Im running 64 bit with Xeon Processors
I figure it's worth mentioning - I saw what appears to be the same issue on Ubuntu 9.10, and was able to resolve it without downgrading any libraries. I'd be curious to know if a similar fix could work for RHEL.
My solution for vmware-hostd crashes on Ubuntu: http://communities.vmware.com/thread/242151?tstart=15
I tried the RHEL 5.3 libc-2.5.so reverting solution originally posted by dirkgf in this thread but must have grabbed the wrong libc-2.5.so or done something wrong because hostd was still crashing. But the below steps did eventually work when I used glibc-2.5-34.x86_64. I found another solution that seems to work too, which I describe following the libc-2.5.so reversion steps below.
SOLUTION #1 (libc-2.5.so reversion)
\# cat /etc/issue
CentOS release 5.4 (Final)
Kernel \r on an \m
rpm -Uvh --root=/tmp/ --nodeps ./glibc-2.5-34.x86_64.rpm
cp /tmp/lib64/libc-2.5.so /usr/lib/vmware/lib/libc.so.6/libc.so.6
\# tail -3 /usr/sbin/vmware-hostd
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_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?
Thanks guys, that seems to have got the VMs stable again - the whole thing has shaken my confidence though. I understand its out of VMwares control but I thought a fix would be out by now, after all it potentially affects RHEL5.4 as well I guess
Im seriously considering looking at Xen or KVM but there needs to be a great interface on it. OpenQRM looks to have what Im seeking in that respect
We all took a chance by going at a platform which is not officially supported . Can't blame VMware.
I too have experienced this issue. Running 26 vmware servers v2.0 and 2.1 on Dell and IBM hardware, CentOS 5.4 (many built as 5.2 and 5.3), 64 and 32-bit. I have implemented the workaround (subst. glibc-2.5-34.x86_64 and modfiying the vmware-hostd wrapper script), but since the workaround the performance of my host has taken a turn for the worse. I have, as a result, not implemented the workaround on any other hosts.
Has anyone else experienced this degredation of performance?
Thanks goes to everyone who has provided their experience and most of all to those who found the culprit and offered this workaround.
a performace in hostd related tasks ? or vm performances ?
I have not noticed a performance degradation anywhere.
First symptoms were slow execution of commands on the host (ls, cp, vi, etc.) I do not directly use the guests so I'm not sure if their performance was directly impacted as well. A "top" revealed vmware-vmx's were the big users (no big surprise here). The Vmware UI was also slow in responding (but it hasn't crashed ) Initially I thought maybe it was the guests (5 of them) trying to recouperate from the unexpected shut-downs - only time will tell with this one. I'm keeping an eye on host CPU usage and will follow up later.
I've also decided to place the workaround on another host (whose guests are also fully monitored) to see if I get the same result.
An update to the performance issues is that things have settled down. Hosts and guests are showing roughly the same performance (in the mid-term) as before. Having kept a close eye on these systems overnight and throughout today, if I see no further concerns I will be implementing the workaround on the rest of my hosts whether they have exhibited the issue or not.
"The FIX for me was to:
yum downgrade glibc glibc-common
It will remove/revert about 22 Packages/Dependencies; for me this was
OK to downgrade glibc since i only run VMware on the systems. I then
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."
It seems to be me that Vmware Server is a public beta testing product.
It's not as easy to manage as MySQL Community Edition, and the problem
you see are not always good for VMWares' reputation.
As a User of vmware Server Community edition you have to deal with
problems around Linux updates coming in (glibc Versions right now),
unstable Web interface, bad Firefox support (only IE and only IE7, it
seems, watch your compatibility modes), etc. So many isses and I am not
sure if the commercially supported versions are better, why should
they? Hmm. I mean I would buy if they would be affordable, but what if
they are expensive and still unstable? At least they are supported ;).
So don't get me wrong: we invest money into companies that deliver
stable products and give something back to the open standards and open
source community. So far we have bought VMWare Workstation and for
Server we run the community editions. The experience is not really
good, just ok, with all these problems.
VMware Server 1.0 had less trouble.
Anyway, thanks everybody. Feedback welcome.
This fucking idiots can not only support RHEL5.1/CentOS5.1 as RHEL 5.x are SECURITY-UPDATES
What is the problem to privide a fix after many months and support guest-kernels > 2.6.27?????
Downgrade glibc does not solve this here
I am restarting "vmware-mgmt" since hours and never get a connection to the webui
First connection will be closed by the server, after reload the hostd is dead
root@caladan-host:~$ rpm -qf /lib64/libc-2.5.so
Is there a sure way to verify that after this change, vmware is using libc really changed?
I am using Fedora Core 11 with glibc-2.10.2-1.x86_64. I copied the file and restart VMware and all goes perfect. vmware-hostd never crash anymore.