I wrote an article a while ago that discussed how to interpret CPU utilization in a virtualized environment and the caveats that must be considered when diagnosing SQL Server performance on a VM. Here is a link back to that post.
Similar complexities arise when discussing memory utilization on a guest VM. On a physical server, if we look at the system properties and see 8GB of physical memory, we can be certain that we have 8GB of memory to play around with. Only when the OS requires more than 8GB of memory, does swaping memory to disk (paging) need to occur. In a virtualized environment, we can no longer be sure that the physical memory that we are supposed to have, is actually available to my operating system. To create a simple example, if we have one VMWare ESX host with 4GB of physical memory, and two VM guests, each allocated to use 4GB of memory, something must give. ESX must step in and decide how physical memory is going to be delivered to each of its gusts. The two main processes that may occur that can impact the VM guest's memory allocation are Memory Ballooning and Hypervisor Swapping. I will explain each below:
On each VM that is being managed by VMWare ESX, there is driver installed on each guest OS that is referred to as the balloon driver. This driver communicates with the ESX host through a private communication channel. If the ESX host determines that it is being starved of memory, it will tell the balloon driver to artificially expand its memory utilization on the guest OS, thereby forcing the OS to use less memory. This may result in memory paging to disk, due to less physical memory being available. Once the balloon driver claims its memory, the ESX host can then go and reclaim it since the guest OS no longer has access to it.
If the Ballooning process is insufficient, ESX will step in as a last resort and swap (at random) some of the guest OS's memory pages to a disk device on the ESX server. A guest specific swap file is created upon startup, and is used during this process. Significant performance implications could exist in these scenarios depending on the speed of the disk that these swap files are being placed on.
For a thorough discussion of both of these process along with a wealth of additional information, the following white paper provided by VMWare is an excellent read.
Bottom line, on a VMWare guest, do not always assume that just because you see 8GB of physical memory as displayed in the system properties, that you actually have access to all of that memory. Making this assumption could have you chasing your tail trying to diagnose a performance issue that is occurring simply because of an over provisioned ESX server.