So, you recognize that FreeBSD isn’t officially supported on VMware ESX, but you want to give it a try anyway? Here’s what I did to get it installed, with VMware Tools and using e1000 Ethernet drivers:
Installation was for the most part straightforward – I chose “Other” for the operating system type, and allocated resources like I would for pretty much any other operating system. The install from an NFS-mounted ISO image worked fine; I’ve only run into two issues so far: Installing VMware Tools and changing the Ethernet drivers from the default Lance drivers.
Attempting to install the VMware tools from the pull-down menu in the VI console resulted in an uninformative “general system error” message. A little googling turned up a suggestion to use the VMware Tools from VMware Server; after copying the tarball over, it installed fine, and allowed me to VMotion the virtual. The VMware Tools status displays as “OK” in the VI Client, although I notice that nothing is displayed for “DNS Name”; I’m not sure if that’s a VMware Tools issue, or something else.
Switching the Ethernet drivers almost threw me. I tried to use the method described in this VMTN post – editing the .vmx file to specify
ethernet0.virtualDev = "e1000"
but upon reboot, I found that the .vmx file was automatically edited back to contain:
ethernet0.virtualDev = "vlance"
Another VMTN post – about OpenBSD – pointed me in the right direction – simply make the edit, and start the host directly from the ESX machine, instead of through the VI Client. To do that, log into your ESX host and find the configuration file of the FreeBSD guest:
[root@esx root]# vmware-cmd -l
Then use vmware-cmd again to start the host, using the path to the configuration file you found with the command above:
[root@esx02 root]# vmware-cmd /vmfs/volumes/[...]/fbsdhost/fbsdhost.vmx start
start() = 1
This command should take a few seconds to return; from limited testing, it appears you only need to start the guest like this the first time after changing the Ethernet device – future reboots in the VI Client interface don’t appear to touch the .vmx file.
Update 2/6/2008: I had originally set this machine up as a two-processor SMP virtual, but I found I was getting strange core dumps while running “make buildworld”; switching the virtual to be uniprocessor (and reinstalling) seems to have addressed this. Additionally, I neglected to mention that I made sure to use an LSI Logic virtual SCSI adapter; ESX actually gave me this by default when I configured the machine.