When you say "not work properly" can you elaborate? What in particular is broken?
First, compared to ESXi with vCenter, VMware workstation is a toy. But even in workstation, every time you download an update to workstation, you are also getting an update to the tools that needs to be installed in all of your VMs.
ESXi with vCenter is massive. I teach 2 different 5 day (10 hour a day) bootcamps (Administration and Advanced) on VMware. I wrote our 4 day bootcamp on desktop implementation (VMware View) and our 4 day class on VMware Troubleshooting as well as collaborating on the other 2 classes.
The VMware tools provide a number of features to the ESXi environment starting with all the drivers for keyboard, mouse, video, network, disk, memory, and all of the virtuallized motherboard components such as IDE, PCI, PS2, and SIO controllers, etc.
In the case of ESXi, there have been 9 updates to the VMware tools for VMware ESXi 5 since its release 17 months ago, of which 6 were deemed as "Important BugFix"s, 3 as "Important Security" and 1 to add "Moderate Enhancements". There were also a number of "Critical Security" updates to the 4.0 and 4.1 VMware tools in the same time frame including one released 2/7/2013. So far there have only been 2 to ESXi 5.1, 1 each "Important BugFix" and "Important Security", both released 12/20/2012. While I don't know what version of drivers is supplied with FreeNAS, I am certain they do not include these most recently released “Important BugFix” s.
Of most obvious concern are Memory, Disk, and Network, in that order. Keep in mind the first 3 steps when creating/optimizing a VM for ESXi are:
1. Install the tools
2. Install the Paravirtual SCSI controller
3. Install the VMXNET3 network controller
Memory: VMware ESXi provides 3 levels of memory management beyond that of normal operating systems. Of course it has a basic swap file system like all operating systems, but this is considered only a last resort after the other 3 have been expended. Two of these are handled totally transparent to the VM (transparent page sharing and memory compression). Note: memory compression is only done to avoid swapping as compression would be faster than going to disk. The one of concern here is what is commonly called the Balloon driver that is part of the tools. This driver allows the VMware kernel when under memory contention, to request that the guest operating system in the VM (FreeNAS in this case) swap some of its memory rather than have the kernel try to guess what memory would be best to swap from the outside. The example I often use in class is: If the kernel were to try to guess from the outside, it might determine that a block of memory that has not recently been used and would be a candidate for swapping might actually contain the keyboard drivers since no-one has logged into the VM recently and used the keyboard. No OS would knowingly swap out the keyboard drivers. Only the guest OS has the knowledge and expertise to manage its own memory, thus the balloon driver in the tools. To be honest, if I were using FreeNAS for production, I would recommend reserving all of its memory so that it could not be swapped at all by either the balloon driver or the kernel.
Disk: Two issues really here. One is in response to some of the comments earlier in the thread. There were problems with the paravirtual SCSI controller in ESXi 4.0. Most of them were resolved by 4.0 update 2 and the paravirtual SCSI driver has further been enhanced since then. In addition, VMware now has a fully supported tools release for FreeBSD which they did not have that long ago. I have seen some comments in other threads about using 3rd party tools, which is a really bad idea now that VMware is fully supporting FreeBSD. Of course this is all predicated on having ESXi fully patched and having the tools updated to the current version. Again, I have no idea what drivers are in FreeNAS, whether they are third party or VMware official drivers. The VMware client is telling me they are "3rd-party/Independent" which could mean actual 3rd party or simply that not all the pieces are there (independent).
The second issue is the ability to quiese the disk. Others have mentioned this as an issue with backup, but that is just one manifestation. One of the primary features of VMware is DRS (Distributed Resource Scheduling). This allows VMware vCenter to balance the CPU and Memory load across multiple hosts by moving VMs from one host to another automagically with VMotion. VMware will give you a warning if it is not able to quiese the disk during a VMotion as this slows down the VMotion process and makes it more susceptible to problems. The disk is also quiesed for snapshots and other operations.
Network: VMXNET2 supported 64-bit OSs and VMXNET3 add support for various new features including some of the offload capabilities to physical NICs. Having the most recent version of the tools guarantees that these operations occur efficiently and properly. This could very well be the cause of some of the performance issues I have seen in the forums comparing FreeNAS network performance against other versions of Linux and Windows.
Now I didn't specifically answer your question about what is broken. Of course you can look at the release notes of the various updates but here is an excerpt from one of them:
PR 837005: Large number of UDP packets are dropped when you use the VMXNET3 adapter with a Linux guest operating system installed on an ESXi 5.0 host.
PR 837008: RHEL 6 virtual machine configured with Raw Device Mapping (RDM) devices through Paravirtualized SCSI (PVSCSI) adapter might encounter I/O failure after bus reset on an ESXi 5.0 host. During reset, the PVSCSI adapter causes the I/O to fail instead of executing the retry command.
PR 838575: The network scheduler uses a single queue to allocate bandwidth between all virtual machines sharing the same network resource pool. If multiple virtual machines send network data at the same time, the available bandwidth might get exhausted before it is allocated proportionally to all virtual machines.
The improvised algorithm now uses a time based scheduling scheme to optimally allocate bandwidth to all virtual machines sharing the same network resource pool.
PR 902238: The virtual machine fails during a specific backup scenario involving quiesced snapshot, this happens because the synchronous manifest file copy operation fails due to an inconsistency in callback process and forces the system to enter an invalid state.