How is vswap provisioned?

[highlandclinic1]

Hi,

I just got a NetApp FAS2240 and I'm trying to get my VMware infrastructure up and running.  One of the things on my list is to move the vswap for my clusters to a shared LUN on the NetApp.  I have a discussin going on the best way to do this on the NetApp community forums:

https://communities.netapp.com/message/94973

So, basically, I'm going to thin provision my vswap Volumes/LUNs based on the size of my physical memory and allow the Volumes/LUNs to autogrow up to twice the size of memroy if it needs to (which it shouldn't).  My only concern is how the vswap datastores get formatted when I point the cluster at them.  If I'm forced to format the vswap LUN completely, then the whole LUN size gets used instead of sizing up dynamically.  But, I'm told in the thread above that:

You need to select thin provisioning on the VMware side when formatting  the datastore to preserve thin provisioning on the NetApp side.

How in the world do I do that?

I'm using ESXi 4.1U2 hosts and Vcenter 4.1U2 also I believe.  Do I have any control at all over how these datastores get formatted?

[jdptechnc]

As you know, each VM will get a .vswp file that is equal in size to the memory allocated to the VM.  In order to guarantee this space to the VM during memory contention, I am fairly certain these files are fully provisioned.

I'm not sure what they're talking about thin provisioning when formatting a datastore.  There isn't an option for that.  You can thin provision your VMDK disk files, and you can thin provision your LUN from the NetApp side.  As to whether to do that for a SWAP LUN, I would excercise caution.  If you hit serious resource contention (a host goes down, a bunch of VM's reboot simultaneously, or whatever), and you don't have the LUN space for VMware to swap allocated memory back to vswp, you will be hurting.  If you're well insulated from that risk, you'd probably be OK.  If you have enough room to fully provision on the NetApp side, I personally wouldn't risk it.

Please note that with vSphere 5.x, there is an additional .vswp file for the memory overhead of the VM that you would have to account for... so if you upgrade, you're going to wind up adding a percentage of allocated memory in further vswp.