This is less of a how-to than a series of guidelines to help optimize the IO performance of your VMWare server.  I’ve installed VMWare server on a number of the Linux distros and currently have VMWare servers running Debain 4, Fedora 9 and CentOS 5.  I would choose your distribution based more on your familiarity and advanced operating features.  If you do some reading you’ll find that many people are taking sides on a number of issues in the area of virtualization and one of the important areas of debate is footprint size.
Having done full OS installs and tiny footprint installs (less than 100 megs) I can say with confidence that the size of the footprint is irrelevant and doesn’t really impact performance.  However, a couple other things do:
Guests and Partitions:   there are 2 ways of setting up VMWare guests – you can pre-allocate disk space which is commonly referred to as the software solution, or you can allow VMWare to use direct disk access for these guests which is commonly referred to as the hardware solution.  Technically the hardware solution can utilize the disks faster, but I’ve personally found that using the software solution is more modular and makes it easier to move around guests OSs and modify the guest settings, themselves.Memory Subsystem and timing: there exists alot of information about host/guest timing issues and there are a couple things you can do to reduce the likelihood that they will plague you.  First tune some parameters in /etc/vmware/config and add the following:
host.cpukHz =XXXX
If your CPU was 3.04 GHz this would read:
where xxxx is the raw value of a single CPU in kHz this will trickle to your guests, but if vmware server is “guessing” you can run into timing problems.  Note that it is a conversion from GHz to kHz and not MHz.  The values below enable a system that tries to correct guest machines when the timestamp counter is very low
host.noTSC = TRUE
ptsc.noTSC = TRUE

Next, you’ll want to modify /etc/sysctl.conf to improve performance of VMWare server.  This helps overall performance in case physical memory is exhausted and swap needs to be used
vm.swappiness = 0
vm.overcommit_memory = 1

these settings tune how VM guest commits I/O to disk
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 1000

This sets how fast a VM guest can set it’s tick count to – the default for various Linuxdistros vary
dev.rtc.max-user-freq = 1024
Disks, Disks, Disks: I always attempt to put my guest OSs on their own partition and I format that partition thusly because VMWare server reads guests in huge blocks (/dev/sdb1 is the partition my guests reside on):
mke2fs -b 4096 -R stride=8 /dev/sdb1
Then I set the block readahead value to somewhere around 16384, but you can go as high as twice that value (in my case this is an entire disk array, so I dropped the partition indicator):
blockdev –setra 16384 /dev/sdb
There are other ways of optimizing performance but I’ve found that they take alot of time without providing much noticeable gain – my first VMWare server is still running without any of the tweaks I’ve described above and, given the hardware differences, it’s still about 25% more efficient to do things as I’ve described above.  Of course, these settings can be very different than those examples above depending on your hardware.
Also, I use the following formula to determine the total number of guests I’m going to host on a physical machine:
# of Guests = ((Total RAM + Swap)/Memory allocated per Guest on average)
so, if I had 4 gigs of ram and 8 gigs of swap, but wanted each guest to have 2 gigs of memory available for use I would have X number of VMs running simultaneously:
X = ((4+8)/2)
X = 6

Of course, I am assuming that you made a backup of your sysctl.conf before issuing the command sysctl -p