VMware Cloud Community
wrgrubb
Contributor
Contributor

vSAN Storage Capacity

We are currently running a 3-node vSAN 6.5 cluster with approximately 14TB of usable space.  As shown below, it shows 7.42TB Used - Physcally Written and 4.8TB Used - VM overreserved.  The default storage policy is being used and Object Space Reservation is set to 0 and dedup and compression are disabled.  Anyone have any idea why this Used - VM overreserved is occupying this space?

Capture.JPG

Tags (1)
0 Kudos
3 Replies
GreatWhiteTec
VMware Employee
VMware Employee

How many VMs do you have in this environment? Large VMs (RAM)?

What you are seeing is most likely vSAN Sparse Swap. If you add all the memory of VMs (turned on) and multiply by 2 you will most likely get to your overreserved number. The reason? By default, vSAN thin-provisions in the back end; however, this does not apply to the swap file, and this is thick provisioned. To take it a step further, this object (swap) utilizes the default policy (FTT=1 default setting). This mean that the swap object in vSAN will be size of memory of VM * 2 (FTT=1). If you change the FTT on the default policy then the amount of space used will increase (FTT=2 & 3).

If you do not wish to have this space taken, you can disable SwapThickProvision advanced setting on the hosts.. Proper planning should be done prior to disabling this. I wrote a blog about this not long ago. https://greatwhitetec.com/2017/03/20/vsan-sparse-swap/

The VM overreserved setting appears when dedupe/compression is disabled. I did a quick test on my lab to demonstrate this.

  • Lab hosts had SwapThickProvisionDisabled set 0
  • Space of VM overreserved = 40GB
  • Changed /VSAN/SapThickProvisionDisabled to 1  (see my blog for how to..)
  • Turned VMs off/back on
  • Space of VM overreserved now = 0GB

pastedImage_2.png

pastedImage_3.png

pastedImage_4.png

Hope this helps. I will write a blog about this too shortly...

0 Kudos
wrgrubb
Contributor
Contributor

Thanks so much for the quick reply.  This definitely appears to be the culprit.  We will look into implementing this change.  Thanks again.

0 Kudos
TheBobkin
Champion
Champion

Hello,

4.8TB seems like a lot of vswap space (unless this is a VDI farm).

You may want to check that Storage Policies are indeed being applied properly and no vmdk' are thick (you will only see this for sure via RVC or using cmmds-tool).

Steps for checking this can be found in my comments here:

deduplication and Compression overview shows no savings at all

Bob

-o Please mark this comment as helpful and/or answer if it resolves your issue o-

0 Kudos