VMware vs. Microsoft: Why Memory Overcommitment is Useful in Production and Why Microsoft Denies it

In the ongoing virtualization war much has been written (pro and con) about the value of memory overcommitment, a feature VMware ESX has and Microsoft Hyper-V is lacking (XenServer, too, for that matter). But only few people take a look at what the term overcommitment actually means. In this article I will explain how overcommitment works, why it greatly benefits VDI installations and why Microsoft denies exactly this.

What is Memory Overcommitment?

Memory overcommitment is not a feature in itself, but a collection of technologies out of which "transparent page sharing" is the most interesting in my opinion. The usefulness of transparent page sharing will spring to mind immediately if you consider VDI environments. There, host machines typically run large numbers of identical client operating systems with the same applications installed on them. Since all the clients/guests run the same application set, most of the code pages they need to keep in memory are identical. Each guest keeps separate copies of all system and application EXEs and DLLs in memory - what a waste!

Now consider the following: in memory program code is organized in units of pages. If you had a component that identified all those identical pages in each guest's virtual memory and map them to one set of pages in the host's physical memory, you could reduce the code memory footprint of n virtual machines to that of one single virtual machine. And that is in a nutshell what VMware's "transparent page sharing" does.

Windows Has Been Overcommitting Since the Earliest Days of NT!

You can also look at it another way: This technology has been around for ages and is built into every modern operating system. Consider a typical Windows system with several applications running. All of those applications require a common set of system DLLs, like advapi32.dll, ntdll.dll and so on. It would be a waste of RAM to load those system DLLs into memory multiple times. Instead, the OS loads each DLL only once and maps the one set of physical pages into each process's virtual memory. I have explained this in more detail here.

Conclusion

What VMware has done is actually quite simple: they have taken the proven technology of page sharing and taken it one step further: From multiple processes on a single OS to multiple OS’s on a single VM host. This is the logical step to take. Others will take it when they have the technology ready.

So why does Microsoft not recognize the value of transparent page sharing? Simple: because they do not have it yet. It is the same with VMotion/LiveMigration and countless other technologies in the past whose value Microsoft traditionally plays down until they have it themselves.

References

VMware white paper explaining memory resource management in ESX server

The Burton Group on memory sharing