Dugg it.
To address memory overcommit (no pun intended), I would like to offer up a quick case study where memory overcommit works in my company of 160,000 employees. A few weeks ago I begain posting preliminary analysis of running production Citrix Presentation Servers inside VMs on ESX 3.x (see http://communities.vmware.com/message/863920). My preliminary findings show that the production Citrix VMs are taking advantage of Content Based Page Sharing (for a detailed explanation of VMware's Content Based Page Sharing, see Carl Waldspurger's whitepaper on Memory Resource Management in VMware ESX Server at http://www.waldspurger.org/carl/papers/esx-mem-osdi02.pdf). One virtualized Citrix server is handling 50-85 sessions and it's not full yet. Each of the sessions is running one of three published applications that all share the same base PowerBuilder code and .DLLs (about an 80MB memory footprint for each session). Because each of the 50-85 sessions shares the same code, the VMware's Content Based Page Sharing consolidates many of the identical pages into single read only reference points and discards the redundant copies. The net result is significant ESX host memory savings. As an example, what I'm seeing inside the Citrix VM is nearly 4GB of RAM being used, but from the ESX host perspective, 1GB or less physical RAM is being utilized, leaving the additional 3GB of physical RAM for another VM in the cluster to use. Now multiply this memory savings by the number of virtualized Citrix servers and the memory savings adds up quickly.
In the blog banter, a point is made by the opposition that it's going to be rare for a number of VMs on the same host to all be identical such that there would be a significant savings in memory page sharing. My example is proof that you don't even need multipe VMs to take advantage of VMware's page sharing and memory overcommit. The fact is that VMware's Content Based Page Sharing works both inter-VM (across VMs) and intra-VM (within a single VM). I verified this with Carl Waldspurger himself a few weeks ago. Summary: Citrix VMs running silo'd or partitioned application sets take advantage of intra-VM Content Based Page Sharing.
On the inter-VM Content Based Page Sharing front, an assumption is made by the opposition that rarely will VMs share the same code to amount to any sort of memory savings. I don't have hard numbers yet but I will say that in our VDI deployment that we are rolling out, all Windows XP images are rolled out from the same template which contains all of the tools each VDI user needs to do business. While there is no guarantee each VDI user will concurrently be running the same applications within their VDI, it's a fact that at a minimum they will each be running the same base operating system (Windows XP), Microsoft Outlook plus all of the MS Office code that loads in the background and at startup. Most will probably have at least 1 IE browser open as well, although the IE footprint is fairly minimal in the grand scheme of things. Depending on the number of virtual desktops we deploy on each host, I think we'll see generous memory savings. This is not to say we will intentionally overcommit memory. Ballooning and VMKernel swap allows memory overcommit but I'm not that desperate to take the performance hit that comes with it, although I'm not sure whether or not our VDI users would be able to tell the difference or not.
Jas
[i]Jason Boche[/i]
[VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]
VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
