Monthly Archives: February 2015

Updated ESXi TPS setting and what to consider for VDI

Another reminder today that ESXi TPS default setting is being changed to be disabled. This was first acknowledged in Oct 2014 that under certain highly controlled situation, it is possible to gain unauthorized access to in memory data. Although this is unlikely to be achievable in a production environment VMware is keeping to secure-out-of-the-box principle and so will be disabling TPS by default. Patches have been released for vSphere to effect this.

So, what does this mean to VDI environments?

Before going any further, if you are unsure of what TPS (Transparent Page Sharing) is, there are lots of resources out there, just ask Google search. One about ESXi memory management which I like is a VMware KB article 2017624.

So, back to this change and it’s impact. It is common knowledge that TPS does help in a VDI environment to save the amount of physical memory required to support all the virtual desktops in a host. It is not unreasonable to see that about 10% (can be more) of memory can be shared in a virtual desktop environment.

With the change that TPS between virtual machines is disabled by default, this 10% (or more) savings needs to be considered carefully.

I’ll cover the 2 scenarios, new deployment and current running environment.

New Deployments
I always strongly urge that a proper sizing assessment to be performed. This is to ensure that the infrastructure is not undersized. An additional step here is to really determine if you want to take advantage of TPS, if yes, validate during the assessment how much savings you get with TPS, and then extrapolate accordingly. If no, then answer is simple, assume no overcommit of RAM; which I’m seeing more and more environments to choose this route (even before the change in TPS).

Remember, if you choose to use TPS, make sure it is enabled in all the ESXi hosts.

Current Running Environments
If you are now operating a VDI on vSphere environment, there will have to be some work to be done, BEFORE you patch.

  • Assess how much memory savings you are actually getting now
  • Work with your security team to agree on the direction to take; i.e. to continue using TPS or not
  • Work out the plan be it to keep TPS on or turn it off

If the plan is to keep TPS on, add a step in the ESXi post patching process to ensure that the TPS is at the level you want. This is a change in process, so make sure it is well communicated to those that executes the ESXi patching procedure.

If the plan is to be on the conservative side and turn off TPS, make sure you have sufficient RAM capacity. Take the amount of savings that you have determined from the assessment, and work out how much physical RAM will be needed when TPS turns off.

There are many ways to skin this cat, and there is no one fixed direction I would recommend, it will certainly vary between each environment.

What is important is to do the necessary due diligence before execution.