I received this questions today so I thought I'd update this post "what size VSWAP LUNS to create?"  Basically if you are not reserving memory then the swap space needs to be equal to the configured virtual memory.  If you are reserving memory then it can be smaller "the difference between the reservation and the configured memory size".  For a full explanation the following is a good reference:  vSphere 5.1 Documentation Center Swap Space and Memory Overcommitment [URL]#com.vmware.vsphere.resmgmt.doc/GUID-AC40823A-695B-438A-A8F2-4B7C51A0D014.html?resultof=%2522%2573%2577%2561%2570%2522%2520
I cannot take credit for this post, I posed the question regarding “Best Practices for locating the Virtual Machine swap file and several vSpecialist responded with number of great answers / opinions / recommended best practices for that and for Guest OS Paging. So thanks to Robert Way, Rajeev Dawar, Rich Barlow, Itzik Reich, Scott Drummonds, and Erik Zandboer for their contributions.  Here’s one of the best general reads on this topic.  “(Alternative) VM swap file locations Q&A” [URL]  The general consensus is that if you are swapping you are screwed.  Once swapping starts, very bad things are already happening, so a design that is centered around identifying and stopping swap as soon as it happens is best.  Sure, EMC would love it if you put your swap files on EMC Flash technology to reduce the performance impact of swapping.  But this might not be the best use of Flash resources if you are concerned about cost, and who isn’t?  If you’ve done a good job architecting your VM’s then you shouldn’t be overcommitting memory and thus it shouldn’t really matter where you put the swap files.  So in general you could keep things simple and just accept the default “Virtual machine directory – Store the swap files in the same directory as the virtual machines”.  With EMC’s FAST VP technology on the VNX and VMAX, if the swap files are not used then they will be migrated to the lowest tier.    There are several good reasons to choose the option: “Datastore Specified by host – Store the swap files in the datastore specified by the host to be used for swap files. If not possible, store the swap files in the same directory as the virtual machine.”  And a reason to keep the VM swap files on a shared datastore versus a local datastore:  If you have a good number of virtual machines then based on what’s written above, there are more compelling reasons to choose to put your VM swap files in a different location. The next question is “Where do you put them?”  If you agree that if your swapping you're screwed anyway then it makes sense to just put them somewhere cheap and forget about it.  Here is some guidance related to EMC storage.   Option 1 – Put them somewhere cheap and monitor closely for swapping Create a LUN or volume on the least expensive storage tier.  This could be a dedicated NL-SAS or SATA disk group or with EMC FAST VP technology you could force the LUN to the lowest tier.  Connect all the hosts in the cluster to this datastore and use it as a consolidated location for all the VM swap files in the cluster.  Since the performance will be horrible if swapping occurs, the IO’s to this datastore should be closely monitored and if the alarm triggers then spring into action and go stop the swapping.  Option 2 – Let FAST VP do its thing Create a LUN or volume in a FAST VP pool.  With EMC’s FAST VP technology on the VNX and VMAX, if the swap files are not used then they will be migrated to the lowest tier, thus the most cost effective tier for swap files.  You could also force the LUN or Volume to the lowest tier upon creation.  Connect all the hosts in the cluster to this datastore and use it as a consolidated location for all the VM swap files in the cluster.  Then, as in Option 1, monitor the IO’s.  Option 3 – Plan for good performance if swapping occurs There may be some applications where you do not want to risk poor performance if swapping occurs.  Or, there may be applications that heavily utilize the available swap space.  One such application is SAP.  This is where Flash technology can dramatically help.  There are a few choices here:  It’s important to note that the above discussion was around ESX host swapping.  Don't forget about the other swapping: in the guest OS.  For this we used the term "paging" to differentiate it from ESX swapping.  If you really want to fully manage paging you should create a virtual disk for each guest OS's page file on the same datastore as the VM swap file.  Then if you are monitoring for IO’s to that datastore, the storage alarm will detect host swapping or guest paging.  Summary To keep things simple you can leave the VM swap file and OS page file in the default locations, place the VM in cluster with a shared datastore backed by a LUN or volume in a FAST VP pool, and monitor IO’s closely.  If you want to gain maximum efficiency then choose a location other than the default for the VM swap file and OS page file, place them on a datastore that is backed by the lowest tier of storage (e.g. NL-SAS RAID group or a FAST VM pool with NL-SAS), and monitor IO’s closely.  If you are concerned with performance if swapping occurs then choose a location other than the default for the VM swap file and OS page file and place them on a datastore that is backed by the Flash technology either on the array or host.  As always, questions, comments, feedback is welcome.
Best Practices for VM Swap File Locations and Guest OS Page Files when using 
EMC Storage