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

Well, I finally took the plunge on my workstation and installed Windows 7 Professional 64-bit. I really am impressed with the usability. And, like the improvements that have been made. I have been on the Beta on one of my home machines, so I’m not entirely new to the Windows 7 look and feel.

My company is heavily into VMware virtualization, management and disaster recovery, and as such I use VMware vSphere\Infrastructure Client all the time. However, I got some strange errors when I tried to log in to one of our vCenter Servers. I realized that the vSphere Client was not supported on Windows 7, and so I started to do some digging. Here is a result of things I’ve found, and this should help get you going…

PROBLEM:

Error parsing the server “SERVER IP” “clients.xml” file

SOLUTION:

Note: I’m running the 64 bit version of Windows 7, so any reference to “Program Files (x86)” should be referenced as “Program Files” if you are running 32 bit Windows 7.

Step 1. Download the following file: System.dll (this file is a .zip file)

Step 2. Once downloaded, unzip the file into the directory:

C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib

If the “Lib” directory does not exist, then create it and drop in the DLL file.

Step 3. Next, we want to edit the “VpxClient.exe.conf” file which can be found in the C:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher directory and add the following three lines just before the end </configuration> tag:

<runtime>
<developmentMode developerInstallation=”true”/>
</runtime>

Step 4. Now we have to create a system environment variable for Windows.  Right-click on “Computer” and go to “Properties”. Now click on the “Advanced System Settings” option:

Now, go into the “System Properties” box and click the “Advanced” tab and then click “Environment Variables”

Now create a new “System” variable called ‘DEVPATH’ and assign the following variable value:

%ProgramFiles(x86)%\VMware\Infrastructure\Virtual Infrastructure Client\Launcher\Lib

(again, making note that it would be %ProgramFiles%  instead of %ProgramFiles(x86)% if you are on 32 bit Windows 7)

Done! You will probably have to reboot your Windows machine to make sure the DEVPATH variable is loaded. Also, some people may have to “Run as Administrator” in order for this workaround to work properly.

Note: This workaround bypasses the normal .NET Framework loading mechanism so that assembly versions in the DEVPATH folder are no longer checked. Handle with care.

Sources: ftubio @ VMware Communities, Xtravirt, TechHead

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 really excited about the possibilities with this VMware Infrastructure 3 in most >SMBs. I really understand why so many larger companies have gone with this solution for their infrastructures. Don’t get me wrong – I see valuable benefits for the SMB market as well – just not with VI3 in particular.

That’s probably my one hangup with VMware – license fees. Hopefully, with the impending release(flash in the pan) of Microsoft’s HyperVisor Solution with Windows 2008, VMware will be able to lower the cost of licensing their software or offer comparable packages to entice SMBs to pay for a technology that’s much more mature and feature-rich than a make-shift way of doing things, IMHO.

I will update here as the week progresses and jot down my thoughts of the sessions.

Time to get some sleep, so that’s it for VMware Training in Raleigh