This Question is Answered
1 "correct" answer available (10 pts) 2 "helpful" answers available (6 pts)
dirkgf wrote:
just for reference in case somebody else is having this issue. We seem to have been able to resolve the problem for us. Following the steps we performed.
just for reference in case somebody else is having this issue. We seem to have been able to resolve the problem for us. Following the steps we performed.
- Log on to your VMware host.
- Create the directory /usr/lib/vmware/lib/libc.so.6
- Log on to an RHEL 5.3. machine. Grab /lib64/libc-2.5.so (or
/lib/libc-2.5.so in case you're running an 32 Bit host) and copy it to
the VMware host into /usr/lib/vmware/lib/libc.so.6 - Rename the file libc-2.5.so within /usr/lib/vmware/lib/libc.so.6 to libc.so.6
- Open /usr/sbin/vmware-hostd and add /usr/lib/vmware/lib/libc.so.6 to the LD_LIBRARY_PATH. I just added an "export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH" before the last line.
- Restart your vmware services (our just the host)
I just wanted to post to this thread to bump this (wish there was a WIKI for this kind of thing). My situation was a bit different since I updated glibc on my box to add a dev environment to compile a server monitoring agent - little did I know (or realize) that this hosed vmware hostd until I rebooted the server a month later
I really wish vmware would just include their own versions of glibc and put that in path instead of relying on the OS. Library hell (DLL hell whatever) ain't fun. OR better yet put out a patch when RHEL is reved since it is a supported platform. Then again, I guess this is their way of saying a native hypervisor like ESX/ESXi is the better option to avoid these issues.
Anyway, It was great that you posted this procedure after discovering the issue. It definitely saved me (and hopefully others) a lot of time and stress. Thanks.
ok !! thanks for the reply !!
Probably tomorrow i will give a try
