I recently upgraded to VMWare 4.5.2, with Fedora Core 3 as the guest and Windows XP as the host. It was much smoother than I expected, but it still needed a few tweaks. Here's what I did to whip it into shape.
Since I wrote this, I've upgraded to VMware 6.0.0 and switched from FC3 to Ubuntu Dapper (6.06), then later to Feisty (7.04). Almost all of these tips still apply, though!
The kernel that shipped with FC3, 2.6.9-1.667, was slower than mud. X windows was especially bad, and would routinely use 50-60% of the CPU for nothing more than typing in Emacs. Kerneltrap's keithmo provided a "minimal" 2.6.9 kernel config, which I used to build my own kernel. It was better, but still much slower than it should have been. A few people blamed the 4G/4G kernel patch, which can perform poorly and was dropped in later FC3 kernels. Sure enough, yum update kernel bumped me to 2.6.11-1.14_FC3, which was just as fast under VMWare as my old, trusty RH9.
...except that it broke X windows. X would start and the mouse driver would load, but it wouldn't start my window manager or anything else. I was stuck with a black screen and a mouse cursor. Worse, the keyboard driver didn't load, so I couldn't Alt-F1 or Ctrl-Alt-Backspace to get back to a tty! I looked at /var/log/Xorg.0.log, but didn't see any obvious errors. After an hour of poking at xorg.conf and vmware-config-tools.pl, I finally tried yum update xorg-x11. It gave me version 6.8.2-1.FC3, which worked beautifully.
The 2.6 kernel and VMWare 4.5.2 also fought over the system clock. Specifically, the clock in the Linux guest ran 2-5x slower than real time. This affects everything time-based, including the keyboard repeat delay, which is very annoying. The problem is well documented on the VMWare forums, and there are a couple solutions. First, try the clock=pit kernel option. (Append it to the kernel line in /etc/grub.conf). If that doesn't work, download the source for your kernel, change the HZ constant in include/asm-i386/param.h from 1000 to 100, and rebuild. clock=pit didn't work for me, but changing HZ to 100 did.
Shared folders didn't work out of the box. Evidently, VMWare's hgfs driver doesn't get along with recent Linux 2.6 kernels. This is well documented on the VMWare and RedHat forums...and luckily, one intrepid hacker has posted a fix. To apply it, download the patch, then apply it to the vmhgfs driver source and re-run the VMWare Tools config script. When it asks if you want to compile the hgfs module from source, say yes. Here are the commands:
tar xf /usr/lib/vmware-tools/modules/source/vmhgfs.tar patch -p 0 < vmware_tools_hgfs_linux_2.6_guest.patch tar cf vmhgfs.tar vmhgfs-only/ cp vmhgfs.tar /usr/lib/vmware-tools/modules/source/ /usr/bin/vmware-config-tools.plYum is the preferred package manager for FC3. It's fairly similar to apt-get, which I'd used for a while. Once I added the Fedora Extras, FreshRPMs, and Dag repositories, I was able to install almost everything I needed, including...
...ion, my window manager! It's not exactly mainstream, so I'd always had to build it from source, but now there's an RPM. It requires lua-5.0.2 and lua-devel-5.0.2, which yum will kindly install for you.
Yum also found an RPM for Pine, my email client. Unfortunately, it complained that it couldn't find libldap.so.2. A quick ln -s /usr/lib/libldap.so /usr/lib/libldap.so.2 made it happy.
FC3 came with Firefox 1.0PR1, which was dog slow. It literally took 5-10 seconds to load a page, switch from one tab to another, etc. I used yum update firefox to upgrade to 1.0.2, which is much better.
I use Ian Macdonald's wonderful acoc tool, which adds color to most command-line *nix utilities. However, it didn't quite install out of the box. I installed the ruby-term-ansicolor rpm, but acoc still complained that it couldn't find ansicolor.rb. Turned out it was looking in /usr/lib/ruby/site_ruby/1.8/term, but acoc wanted it in /usr/lib/ruby/1.8/term. A quick mkdir -p and a ln -s fixed this.
xview is my image viewer of choice, and it came with RH9, but not with FC3. This wouldn't be a big deal, except it took me a while to figure out which package it came in. Turns out it's part of xloadimage, which yum happily installed for me.
I use GNU Emacs, and I use Subversion, so I expect them to work together. I use vc-svn.el, which provides VC-mode in Emacs for Subversion. However, the Subversion folks are currently handing that hot potato over to the Emacs folks, and in FC3, neither package has it! This was easily remedied, though. Download the last version of vc-svn.el from the Subversion web-based repository and put it in /usr/share/emacs/site-lisp.
I also use savehist.el in Emacs, which saves and restores most session history. It's in xemacs-edit-utils-pkg, which ships with XEmacs. However, finding a version that's compatible with GNU Emacs is iffy at best. So, I'm hosting it here: savehist.el 0.4 for GNU Emacs.
I work from home occasionally. To do this, I ssh to work, run programs on my RH9 workstation remotely, and display them on my local X server through the ssh tunnel. Unfortunately FC3 has xorg-x11, RH9 has XFree86, and they don't play well together out of the box. Luckily, this turned out to be easy to fix. I just needed to add ForwardX11Trusted yes to my ~/.ssh/config. Voila! Happy remote X display.
FC3 thoughtfully includes mplayer in its base distribution. However, it doesn't include the optional codecs, such as RealPlayer. To install them, download the codecs from the mplayer page and extract them into /usr/lib/win32. (The mplayer docs have more information, but you shouldn't need it.)
Both FC3 and Ubuntu, my new distro, use GDM. I don't mind GDM and X sessions, but I prefer a console login and xinit. To turn off GDM on Ubuntu, run update-rc.d -f gdm remove; update-rc.d gdm stop 20 2345. On FC3, comment out this line in /etc/inittab:
x:5:respawn:/etc/X11/prefdm -nodaemonHGFS, VMWare's Linux filesystem for shared folders, is quirky about permissions with Linux guests on Windows hosts. Windows and *nix filesystems handle permissions differently. *nix's are generally richer, so when the physical filesystem is on Windows, HGFS allows full access too all files for all users, but exposes their permissions as 700 and owned by root:root. This means that stat thinks you can't read them! This often crops up when running a
configurescript (orautogen.sh,autoconf, andautomake) to build a program from source. I've asked VMWare about this, but for now, it looks like the only workaround is not to use HGFS. :/