The following tips work both under VMWare ESX (2 & 3) and VMWare Server 1.0.
1. General tips
Don't use a virtual machine for network-heavy workloads. VMware and other full-hardware virtualization environments (MS Virtual PC, QEmu, etc.) introduce a heavy penalty on I/O, especially network I/O. Expect to be able to get only around 30%-40% out of a gigabit interface (which still amounts to ~~40 MB/s). For example, don't use virtual machines for network routers and similar tasks. Also, don't use them for tasks which require exact timing (e.g. multimedia processing, industrial machine control, etc.). These points are actually valid for any combination of virtualization software and guest OS.
2. Don't use lnc
This tip is no longer current, as lnc doesn't exist in FreeBSD 7. It's still valid for FreeBSD 6.3 and earlier versions.
While it's the default, lnc driver is the worst network driver for your virtual machine. It's GIANT-locked (meaning it doesn't allow for much parallelizm in the OS), and it's actually deprecated and will be dropped in FreeBSD 7. The replacement for lnc is le and it's present at least in FreeBSD 6.2 and newer, but it's not included in the default GENERIC kernel. Thus, you'll have to configure and compile a custom kernel with device lnc replaced with device le. (Just loading the if_le kernel module won't work because the lnc driver present in the kernel at boot time will detect and use the hardware first.)
In VMWare ESX 3 and VMWare Server 1.0 there's an undocumented configuration option for the virtual machine that enables VMWare to emulate Intel E1000 hardware instead of the AMD Lance[*]. To use it, edit the .vmx file and put ethernet0.virtualDev="e1000" in the appropriate place (anywhere). The simulated device also has TSO support (which is usable in FreeBSD 7, though I don't know what performance can be achieved with the simulated hardware). Device em is faster and not GIANT-locked so it should give the best performance.
3. Reduce kern.hz
Kernel's timer frequency ("HZ") in FreeBSD 6.x and 7.x is set to a relatively large value - 1000 Hz. This was done in attempt to reduce latency in the interim period while some kinks are sorted out and it's planed for it to be reduced back to 100 Hz in future versions of FreeBSD. High HZ setting has a negative impact on simulated machine's performance because the VM software spends a lot of time handling timer interrupts instead of doing real work.
You can change the HZ setting by adding a line like kern.hz=100 in /boot/loader.conf. In the extreme cases you might want to use very low values for kern.hz like 20, but test first!
4. Disable internal VMWare swapping
Consider disabling VMWare internal memory swapping and make the virtual machine fit in in the physical memory of the host for best performance.
5. VMWare Tools not necessary
It would be nice to have VMWare Tools working on FreeBSD but apparently the company doesn't want to support it properly. Currently, the only thing that VMWare tools are useful on FreeBSD is to get GUI features like clipboard sharing and automatic mouse focus grab in X.Org. VMWare tools on Linux seem to include a driver that does something with memory management, but it's not available for FreeBSD. You don't need VMWare Tools for the following things to work: networking, timer, X.Org GUI.
Networking is handled by the le driver or the em driver. These two will work without any special configuration of FreeBSD. To use the em driver, you might need to modify the VM configuration to include ethernet0.virtualDev = "e1000" or a similar appropriate line. To use the VMWare vmxnet driver (which as far as I can see isn't much different than the le driver), you need to build a kernel without the le driver first.
Timer issues can be lessened (never resolved, even with VMware tools) by reducing kern.hz to something like 50 or 100 Hz (in loader.conf), and installing ntpd.
X.Org can use the generic "vmware" display driver which is included in the default X.Org collection of drivers. Mouse, etc. are also handled generically.
The only remaining functionality is the ability to "shrink" drives. If you're running VMWare Server on Windows host, there are third party utilities for VMWare that can do the same thing.
[*]If you're from VMWare-the-company, please don't remove this feature from both of the products. It's very useful both in ESX and Server for both production and testing.
