This post is also available in: Italian

Reading Time: 4 minutes

There are already lots of information about VMware vSphere 6.0 (actually in beta) but one big change has not be publicized so much: starting in December with the next ESXi Update release, TPS (Transparent Page Sharing) among virtual machines will no longer be enabled by default and this will not only be applied to next release, but also on current releases.

This actually does not mean that will be not be available (at least not in the short period), but is another historical piece that will be not used by default, like the vSphere Client (first was announced as no longer available in next release, than something has changed) or like ESX Server or Converter Enterprise.

But what is TPS?

To use a simple concept, TPS is a VMware unique technology to deduple the main memory of an ESXi hosts: more memory pages from different VMs (or also from a single VM) on one host could be identical and, after that TPS has run, deduple as a single physical memory page.

VMware-TPS

Note that this is not a real-time process, but is an time frame process: ESXi hosts periodically scans the content of guest physical memory for pages that could be shared. And it will take time to run and bring it’s effects. More information could be found this White-paper: Understanding Memory Resource Management in VMware vSphere 5 (but TPS and most apply also on previous versions).

Why will be not enabled by default?

The main reason explained in this post is related security reason: some recent academic research leveraged TPS to gain unauthorized access to data under certain highly controlled conditions. So VMware strives to be “secure by default” wherever possible, although the security risk associated with enabling TPS is very low. More information are available on KB 2080735.

But there are also some interesting enhancements to still use TPS (for example in VDI environments where could useful to provide memory overcommit) that are described in KB 2091682: a new host config option Mem.ShareForceSalting is introduced to enable or disable salting (order for two VMs to share a page, both their salt and the content of the page should be same; a salt value is a manually configurable vmx option for each virtual machine).

But this security issue is not the only reason why TPS could/should be disabled.

One reason is related to TPS with large pages with hardware MMU systems and is well described in KB 1021095 or several blogger posts: mainly TPS could be not so useful (although still applicable) in system with large pages, because the probability of finding two large pages that are identical is very low (pages could be fragmented in smalles, but in this case there are much more overhead). For the same reasons recent operating systems with hardening memory management (using for example randomization of address with Windows ASLR) will not benefit so much from TPS (you can compare how TPS works on Windows XP vs. Windows 7 or 8).

Another reason is related to the operational cost of using TPS as described from since the first article on how it does work: usually memory pages are compared using hashes that summarizes page’s contents, but then a successful match will be followed by a full comparison of the page contents to verify that the pages are really identical. This mean a lot of time consuming operations (although there are more cores on each servers and both cores and memory are much faster, memory on hosts is becoming much bigger!).

And there is also the aspect related to vMotion operations: when you move a VM across hosts all the memory will be copied without any consideration on with pages are shared (also if you move two VMs that share some pages). This mean that during a maintenance activity (for example) the overall used RAM may increase rapidly (TPS will only run on demand and will take lot of time to dedupe pages) and you have to take care of this. Same apply for environments with a huge dynamicity where lot of VMs are created, deleted, or rebooted (could be the case of a development environment).

The curious aspect is that TPS was one the distinguished function available only on ESXi (and ESX) and was never been implemented by other hypervisors: now this gap may be be filled by VMware that will disable it (but not actually removing or unsupported it) in next upgrades.

For more considerations about this important news you can also read Frank Denneman’s blog post: Future direction of disabling TPS by default and its impact on capacity planning.

Share

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-24. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-23. Nutanix NTC 2014-20. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.