Transparent Page Sharing is a technology from VMware that essentially deduplicates memory. Instead of having 100 copies of the same memory segment it keeps just one, and returns the savings to the user in the form of additional free capacity.
In a move that further encourages people to never patch their systems VMware has set the new default for Transparent Page Sharing to “off.” They did this in the latest Updates to ESXi (ESXi 5.5 Update 2d, for example). More specifically, in order to use it by default you now need to configure your virtual machines to have a “salt,” and only VMs with identical salts will share pages. To specify a salt you need to manually edit a virtual machine’s .VMX file, which also requires the VM to be off and removed from inventory, too.
What a mess.
If you patch to the latest versions for security reasons it’ll be off, and you’ll likely have some serious memory contention issues. In one of my environments we have almost an entire host worth of shared pages (209.71 GB):
which, under ESXi 5.5 Update 2d, will be gone.
If I were you I’d put it back the way it was, which means an advanced configuration option on each ESXi box, Mem.ShareForceSalting set to 0. You can’t use Update Manager, though, because the new default appears after ESXi 5.5 Update 2d boots. You need to set the flag once the host is up, then reboot the host once more. So it’s a pretty manual patching round this time.
This is all due to a low-risk security concern that’s likely not even a consideration for a typical enterprise. VMware wants ESXi to be secure by default, which I get, but this is a major change that seriously affects resources & budgets, too. Major changes go in major releases (5.1.0, 5.5.0, etc.), not third-level point releases, and NOT mixed up with a critical security fix, either. This is a classic VMware Hobson’s choice: take the whole thing or leave it. Or perhaps it’s a Catch-22. Regardless of the cliche, I suspect this poor “feature” release decision is going to cause some headaches for VMware customers this time.
More information is in the VMware KB:
There is a tool available that helps you to estimate the impact of this change to your environment: http://www.running-system.com/still-enough-host-memory-inter-vm-tps-disabled/
I used the tool in some clusters and there will be no problem if I can trust the results of the tool. So I would not recommend to put Mem.ShareForceSalting back to 0 in general if I were you – I would check it before and then make a decision.
Bob,
As you know probably already know, you shouldn’t have to manually edit VMX files, this can be automated using our various API/CLIs (http://blogs.vmware.com/vsphere/2012/03/acessing-virtual-machine-advanced-settings.html). In addition, one nice thing that I’ve found out over the years working with vSphere Security Hardening which has you applying VM Advanced Settings (which basically persist to the actual VMX file) is that you can do it while the VM is live, and if you vMotion it, the changes go into affect. This would technically allow you to update it for your VMs without downtime. I’ve now tried this myself with this specific parameter, but if I believe it should work as well.
I’d totally forgotten that a vMotion makes the changes live. Thanks William, good work as always.
I threw together a quick script that uses powercli and plink to do some TPS calcs. http://pcli.me
With the amount of memory being paged to disk as displayed in your image, I wouldn’t be too worried about the amount to page sharing being used or lost… Environments that are that poorly managed are doomed anyway.