VMware Tools in Fedora Core 6

It started with a simple desire to synchronize this thing with the real time. It wasn't quite Sunday, December 18th, but the clock was telling me that it was Sunday...December 11th. Almost a week late, which would be great if I could think of a few regrets...

This happened because of a unique issue while running one operating system in another. VMware Server is a newly free release of a formerly expensive and professional product that runs other operating systems within Windows, or vice versa. VMware Server is a wonder to use, but can also leave one wondering how to install and configure it. I've been chronicling my experience with it, and you can find bloggings of my installation and screen resolution experiences. Here I'll speak more about configuration after the install.

Tools has always been a challenge. VMware Tools is a mechanism for integrating the virtual machine (eg Linux) with the host operating system (eg Windows). Rather than treating the virtual machine and its Windows host as entirely separate entities, one can use Tools to bridge the two together. One of its features is the ability to drag the mouse directly from Windows into Linux and back out, without pressing any special keys to tell which operating system the mouse should be in. Another features is time synchronization, since virtual machine system clocks often run faster (or sometimes slower...) than real time, and between hibernation, the time can get off by weeks. For some reason, virtual machines can't synchronize well with Internet clocks, making Tools a necessity.

Tools makes things easier, but can be a challenge to install. With a few known hacks (scroll down to Setup), Tools worked fine on Fedora Core 5. After updating to Fedora Core 6, however, I needed to hunt down another series of hacks. With effort, I stumbled across them one by one in what could be a solution unique to my configuration. But perhaps at least one or several tips, grouped here, may prove useful to the reader.

My system is VMware Server 1.0.0 running on Windows XP SP2. The virtual machine runs Fedora Core 6, freshly updated. The computer is a Dell Inspiron 700m with a Pentium M 2.00 GHz processor and 1.23GB RAM. Most of these commands are best done as root (or for convenience, as sudo -s).

Initial steps

The documented method to install Tools is to:

• Click on the menu VM > Install VMware Tools... in the VMware Server Console. This mounts files on the Desktop that can be installed.


• Install the kernel-devel and gcc packges. yum install kernel-devel gcc on Fedora Core.


• Run the configuration script, vmware-config-tools.pl. So go the official instructions: "Respond to the questions the installer displays on the screen. Press Enter to accept the default value." The default value, or course, did not work. The script complained that the kernel headers could not be found and could not be compiled, and when manually located, matched a different kernel version and simply wouldn't work, even if successfully compiled.

Kernel update from i586 to i686

One of the most common comment on forums was about the discrepancy between the architecture targets of the kernel and kernel-devel on Fedora Core 6. What turned out to be the first entry in the Common Issues section of the Wiki for FC6 is a solution for upgrading a kernel targeted for i586 with one for i686 (Pentium II/K6II+). I'll leave the Wiki link to the reader, as the instructions seemed clear.

One helpful posting on a different issue advised downgrading the kernel-devel package to i586, but I read other postings that the i686 version would work as well, so long as both kernel and kernel-devel were consistent.

Link autoconf.h to config.h

I nonetheless found the posting useful for pointing out not only the package discrepancy, but also an issue with a kernel header file. A lengthy forum topic (scroll toward the bottom) clarified the issue and held a golden nugget on solving the header file dilemma: link autoconf.h to config.h in the include/linux folder:

cd /usr/src/kernels/2.6.18-1.2849.fc6-i686/include/linux
ln -s autoconf.h config.h

(for the .2849 kernel version; uname -a finds the appropriate number).

config.h will now be read as the newer autoconf.h. According to several users on one forum, it may also be possible simply to touch config.h instead of making the link.

Direct the script from version.h to utsrelease.h

For most people on the forums, synchronizing the kernel architectures and creating config.h did the trick. I kept getting an error, however, telling me:

The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match
your running kernel (version 2.6.18-1.2849.fc6). Even if the module were
to compile successfully, it would not load into the running kernel.

A search for "UTS_RELEASE" revealed a third issue: the variable UTS_RELEASE is stored in a new location. The hack this time involved directly editing the Tools script to look for the proper file. After making a backup copy, I changed the file references from linux/version.h to linux/utsrelease.h (corrected from the forum entry).

And the module compiled. Tools loaded into the kernel, time synchronized, and that night, I slept peacefully.

Additional thoughts/dreams

A few loose ends...feel free to comment below.

• My 3-part issues may have been the result of a unique configuration. The i586 kernel problem seems to be a known and accepted issue, and judging from the wealth of forums, the config.h isuse also does not appear to be unique. My final issue may have been unique, howver, since I have seen few reports of the need to switch to utsrelease.h. It may have been fixed in VMware Server 1.0.1. I have been holding off on the Server upgrade since installation takes a considerable amount of time, and the upgrade came barely a month after the initial release, with few reported updates. The Tools script may have been one of those "maintenance" fixes, though.


• My original impetus to get Tools on board was to fix the system clock and ensure that Text Flex CVS versions for Text Trix and Jar Ajar didn't conflict. This may have been a vestige from slow SourceForge servers, though, rather than a problem with the system clock. Recent advancements in CVS synchronization on sf.net may have also been the fix.


• Thanks to Colin's prompting, I've stepped up the RAM allocation from 256MG to 512MB. Very helpful, much speedier, and the host still has enough RAM!