For applications like SQL Server, the application is going to grab extra memory to reserve for cache space. As SQL active memory usage increases, the sqlservr process will grab more memory for cache. You really don't want a SQL server to be starved for memory; you want to find what it requires at its peak usage. SharePoint and I think now Exchange do the same kind of thing.
There may be other factors, such as the SQL Server server settings being configured with a "minimum" memory setting that is greater than required.
A little research into SQL internals and a smidge of common sense on the part of the SQL/Application admin and the VMware admin is needed to find a happy medium. I personally wouldn't allocate less than 4 GB to a dedicated production SQL VM regardless of what the "active memory" footprint is.
I have been able in many cases to show active memory over time to cause people to rethink the "just throw more memory at the problem" mindset. If Windows or the installed applications in Windows want to tie up memory to the point where the allocated memory isn't enough to cover it, and the application can't be tuned to not so do, you may not have a choice but to give them more memory. In my experience, it will be evident to you immediately if physical memory starvation is the real issue. I've found that changes to the environment made by people who are afraid to let VMware do its job end up affecting performance more (for example, hard-set reservations and/or limits per VM). Also, I have found that the "real" bottleneck, when the culprit is less obvious, is often storage.