You may be aware about recent academic research regarding potential TPS (Transparent Page Sharing) (enabled by default) vulnerability, where you may be able to determine AES encryption key from memory timings.
VMware response for this (although they do not believe it can be used in real world): they will disable inter-VM TPS (between VMs) by default. This means deduplication will still work inside one VM though.
KB2080735
Releases with changed default behavior:
- ESXi 5.5 Update release – Q1 2015
- ESXi 5.1 Update release – Q4 2014
- ESXi 5.0 Update release – Q1 2015
- The next major version of ESXi
Because of this change VMware also introduces new management capabilities for ESXi
KB2091682
- ESXi 5.5 Patch 3. For more information, see VMware ESXi 5.5, Patch ESXi550-201410401-BG: Updates esx-base (2087359).
- ESXi 5.1 patch planned for Q4, 2014
- ESXi 5.0 patch planned for Q4, 2014
So how can disabling Inter-VM TPS impact your environment?
The answer is as usual: it depends
For the modern processors with MMU support (Intel EPT Hardware Assist and AMD RVI Hardware Assist – Nahalem and newer) where ESXi is leveraging usage of Large Pages (2MB) and by default there won’t be huge impact as TPS is not effective there until host comes under memory pressure and pages are breaked down to 4KB.
KB1021095
Usually in an healthy environment you are not coming under such memory pressures especially if you are counting with some High Availability reserve.
Additionally modern operating systems – since Windows 2008 and Vista (Linux as well), are leveraging security feature called Address Space Layout Randomization (ASLR), which is preventing TPS to be effective, especially in ZEROing when large pages are used. (Zeroing is collapsing memory with zeroed blocks into one)
Note: Counting TPS into your HA reserve is not a good idea because “deduplication” itself takes few hours after it releases some memory. So your memory will be most probably balooned or even swapped out to the disks anyway.
However some VDI deployments especially with floating (not dedicated) desktops might be operating under memory pressures all the time, in that case you have to be very cautious.
Older operating systems – prior Windows 2008 and Windows Vista are using small pages 4KB by default so they are benefiting from TPS a lot.
Also you may have disabled usage of the large pages before, using Mem.AllocGuestLargePage 0 in this case you should be benefiting from TPS even in case of “modern” operating systems.
Best way to check how much you are utilizing TPS is to check performance tab in you vSphere client (on cluster or host level, but can be done on VM level too). In memory view check SHARED and ZERO metrics. SHARED is all memory which is saved with TPS and ZERO is memory with zeroed blocks collapsed into one. ZERO effectiveness should not be related to disabled Inter-VM TPS at all or only in a negligible way.
If you subtract ZERO from SHARED you will get an actual estimate of your savings from deduplication in general.
Note: You can use esxtop as well
Unfortunately you cannot check how much savings you have from Inter-VM TPS (at least I couldn’t find such metric), but I guess subtracted value should be a good pointer as usually you are not storing same blocks of memory twice, but it can happen in some applications.
To sum it up: Be cautious if you are hosting older operating systems or your environment is under heavy memory pressure right now
If you are interested, I have found some nice thoughts on this topic from security point of view on yellow-bricks.
Latest posts by Dusan Tekeljak (see all)
- VM Latency Sensitivity set to High still fails with no (proper) warning - June 27, 2024
- ESXi 6.7 U1 fixes: APD and VMCP is not triggered even when no paths can service I/Os - November 30, 2018
- Update manager error: hosts could not enter maintenance mode - November 19, 2018
