CentOS 5.4 has a new glibc package that essentially breaks VMware Server’s hostd process. There are many posts out there regarding the issues, and various means of fixing them. However, I am just going to summarize info I’ve found out there on the net, and hopefully you should be able to follow very easily and get your VMs back up and running.

PROBLEM:

VMware Server 2 (hostd) crashes on CentOS 5 after upgrading to the latest releases of glibc and glibc-common

NOTE ON SOLUTIONS: There are two methods to solve this. The first requires downgrading the libraries system-wide. This should be fine if you only use the CentOS host as a VMware Server Host and nothing else. However, if you are in doubt whether your other applications, etc. on that host will run on a slightly older version of glibc, please use SOLUTION METHOD 2 as it will only affect VMware, and essentially tell VMware Server where to look for the correct libraries it needs.

Disclaimer: I am not responsible for you rendering your server useless. When in doubt, don’t upgrade to CentOS 5.4… Although, you probably already did that, and this is why you’re here.

SOLUTION METHOD 1:

Step 1: Go to /etc/yum.repos.d and copy the file CentOS-Base.repo to CentOS53-Base.repo

Step 2: In CentOS53-Base.repo, rename all the packages to reflect the 5.3 version. So, change:

[base] --> [base53]
[updates] --> [updates53]
[addons] --> [addons53]
[extras] --> [extras53]
[centosplus] --> [centosplus53]
[contrib] --> [contrib53]

Step 3: In CentOS53-Base.repo, replace all instances of release=$releasever with release=5.3

Step 4: Now, downgrade the glibc and glibc-common libraries by running the following commands:

yum downgrade glibc glibc-common

Step 5: To avoid any problems with future upgrades/updates, it would be best to exclude them from the list of available updates on yum. Add the following to your /etc/yum.conf file:

exclude=glibc glibc-common glibc-devel glibc-headers glibc-utils nscd

Step 6: Reboot the server, and now re-run /usr/bin/vmware-config.pl to reconfigure with downgraded glibc libraries.

/usr/bin/vmware-config.pl

Step 7: (Optional) Run the following command to make sure future upgrades/updates will not download the updated glibc* libraries.

yum list glibc*

Now, if you have other applications installed on CentOS, and you don’t want to worry about any issues with future use of glibc on your server, please follow the next method to manually link VMware hostd process to use the older glibc libraries.

SOLUTION METHOD 2:

(Make sure you are logged in as root for these steps)

Step 1: Install the latest 2.0.2 VMware Server package and run the configuration. It will crash, but just ignore this for now.

Step 2: Run the following command, and make note of the response.

arch

Step 3: Run the following commands, and replace any instance of {ARCH} with the result of Step 2:

mkdir ~/vmwareglibc
cd ~/vmwareglibc
wget http://mirror.centos.org/centos/5.3/os/{ARCH}/CentOS/glibc-2.5-34.{ARCH}.rpm
rpm2cpio glibc-2.5-34.{ARCH}.rpm | cpio -ivd
mkdir /usr/lib/vmware/lib/libc.so.6
mv lib64/libc-2.5.so /usr/lib/vmware/lib/libc.so.6/libc.so.6

Step 4: Open the VMware hostd process script for editing.

vim /usr/sbin/vmware-hostd

Step 5: At line 372, before the program is called, insert two empty lines and add the following:

export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH

Before Example:

if [ ! "@@VMWARE_NO_MALLOC_CHECK@@" = 1 ]; then
     export MALLOC_CHECK_=2
fi
 
eval exec "$DEBUG_CMD" "$binary" "$@"

After Example:

if [ ! "@@VMWARE_NO_MALLOC_CHECK@@" = 1 ]; then
     export MALLOC_CHECK_=2
fi
 
export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH
 
eval exec "$DEBUG_CMD" "$binary" "$@"

NOTE: In Step 3, the wget command may in the future be this as 5.3 repositories are taken off of the main CentOS Mirrors:

wget http://vault.centos.org/5.3/os/{ARCH}/CentOS/glibc-2.5-34.{ARCH}.rpm

Either method you use should get you the desired end result: VMware Server 2 running on CentOS 5.4

Be sure to comment if this helped you. Thanks.

2/11/2010 UPDATE: A bug exists to where if you’re on the VMware Host server and trying to access the VMware Web Access UI with HTTPS via Firefox you will simply see a blank screen. Instead, use http://<HOST_IP_ADDRESS>:8222/ui

2/12/2010 UPDATE: Firefox 3.6 does not work with the Remote Console Plugin – you must use 3.5.7 or earlier, Internet Explorer, or use the VI Client. – VMware Communities Thread

I soon realized that this wasn’t as easy as it seemed. CentOS printed test pages, etc. just fine from the host using the device /dev/lp0. However, VMware wanted to use the device /dev/parport0 – actually, I really didn’t have an option as it was simply a drop-down menu and not a simply text field to enter whichever device I wanted to specify.

I tried manually editing the .vmx file and changing the line:

parallel0.fileName = "/dev/parport0"

TO

parallel0.fileName = "/dev/lp0"

No dice… Even though CentOS worked when trying to print to the device /dev/lp0, it did not seem to work this way with VMware Server. With a little digging, I was able to find a way to make the passthrough work correctly, albeit not 100% smoothly due to what may be a bug with VMware Server.

Here is what I did in order to get the port working:

1. Remove lp module:

2. Edit the file /etc/modprobe.conf, and beneath the existing ‘alias’ lines, add these lines:

alias lp off
alias parport_lowlevel parport_pc

3. Make sure no modules are using the parport0 device (output should be ‘none’):

4. Reboot the system and run the above command again to make sure that lp module does not bind to parport0

5. Make sure the lp module is not loaded:

6. Add the virtual parallel port to the VM while it is powered off, and make sure it’s set to the hardware device /dev/parport0 and checked to Connect at Power On:

7. Boot VM, and it should auto-detect the LPT1 port inside of Windows:

8. Once Windows is loaded, go back to the host and edit the parallel port settings to disconnect the port, and then reconnect the port.

9. This parallel port passthrough should work until the next reboot of Windows, and then simply complete Step 8 again, and it will be back.

Hope this helps someone else that’s looking for a solution!

I am loving the new VMware Workstation 6.5 with Unity mode(among other features) I hope to be rid of the need for a dedicated boot entry for Windows. If you haven’t checked it out yet, Unity mode alows you to have access to your Guest OS’ applications menu in order to start and run those apps in the ‘space’ of your Host OS’ desktop. Not the most technical explanation, but it essentially allows the focus to be on what you’re doing with your VM as opposed to the OS itself – cool stuff.

Which brings me to the reason for this post – it seems as though the latest release of Ubuntu (Intrepid Ibex – 8.10) doesn’t play well with VMware Workstation(or vice versa). Then throw in the added complication of an Acer laptop that I’m dealing with (TravelMate 3260), and it becomes more complex.

Of course I searched around the internet for answers, and found bits and pieces. I was able to fix my keymap issue here. I made use of compiz-check to verify my hardware was capable of running Compiz and then installed it.

So, now I am pretty much set, from what I have read and can tell that I should be able to utilize Unity mode in my VM now. (Of course, I have already created my Windows XP VM, installed updates/VMware Tools, etc.)

Well, I booted up the VM and once it was up and ready, clicked the Unity button. I was finally ready to try this puppy out. VMware Workstation minimized and the Unity “Start” button was created at the top left, just under the top Applications bar in Ubuntu. I clicked the button for my VM and… nothing! It did absolutely nothing. Well, the first thing I tried to do was bring up my VMware Workstation window again, and it came up all gray and was basically not responding.

Well, this was all after a bit of time trying to get this thing to work, so I was dissapointed. I searched the net again to no avail, just turning up post after post of different people having the same issues (apparently not this guy). So, I tried different combinations of VM settings in displays, Unity settings, etc. It still would just show the button, almost defiantly.

I decided to try something else – I noticed that while in VMware Workstation preferences, there are a couple options that are grayed out unless you are running VMware Workstation as root. So, I opened up a terminal and ran:

sudo /usr/bin/vmware

It opened up the VMware Workstation window, and I started my Windows VM once more. I just knew it was going to work this time. Once loaded I again pressed the Unity button and it minimized VMware Workstation; leaving my Unity Menu at the top left again. I pressed the Menu button this time with added confidence, only to find that the result was the same.

However, I noticed that in the terminal window, there was a message:

VMware Workstation Hint:
A language-specific mapping from X keysyms to machine scancodes will be used,
based on the detected keyboard type of "us101", because you are not using an
XFree86 server running on the local machine.
However, this program's language-specific mapping may not be correct for your
keyboard in all the details, because X keyboard mappings vary.
You can override specific key mappings in the virtual-machine configuration.
For more information, please see VMware Workstation documentation available
on our Web site at "http://vmware.com/info?id=10".

0) OK

Please choose a number [0-0]:

Obviously, I had grown weary of this “Hint” earlier on and had already set it to not show this again. As soon as I typed in 0 and hit Enter, a game of Solataire popped up on my screen in all it’s Compiz-enabled, Windows 95 prowess.

I was finally enjoying Unity mode and bouncing back and forth between windows(literally), apps, OSes. It was a touching moment to see such vastly different OS models come together like that!

Ok, maybe not that touching, but it’s sure nice to have my proprietary apps running side by side with the open-source goodness that it Linux.

Anyone else have issues like this? Any tips, or suggestions? I am just glad I got this far on it, as I’m by no means a Linux guru. Maybe this will help some others that have struggled with the same issues as I.

Kudos to VMware for another slick release of Workstation, and Ubuntu with a nice release of Interpid Ibex – And to all those whose information helped me along the way, Thank You!

EDIT: Just as an update to anyone reading this, I found out that there is a much better way to do this. Instead of using the “xkeymap.nokeycodeMap” line in your VMware workstation config file, if you manually specify the keymap instead of simply having it ignore it, you can actually run Workstation 6.5 as your user and no need to have a terminal window open, so it’s much more fluid.

Look at this post on the VMware Community site.

Hope this helps someone!