Where to Place your VM Swap?

This one has been bothering me lately. Where do you place your Virtual Machine Swap files?

There are two options:

  1. In the Same Directory  as the VM
  2. In the Datastore specified by the host.

As you can see below.


If you choose the second option then you can configure the swap location per host


Here comes my question.

Duncan Epping posted about the Impact of decisions… - for those that wanted to keep the vswp files on local VMFS datastores on their Hosts. Frank Denneman also wrote a post regarding this subject as well- Impact of host local VM swap on HA and DRS.

My question is as follows. When changing this you see (in both screenshots) a nice warning from VMware that this could degrade vMotion performance.

I take this to be true if you were moving the swapfile location to a local VMFS volume located on the ESX host. When initiating a vMotion - the vswp file will have to be copied to the other host’s vswp location for the migration to complete.

But what about a different Datastore that is shared storage - but not the location of the virtual machine files?

This is actually specified as a one of NetApp’s best practices (NetApp and VMware vSphere Storage Best Practices TR-3749) pg. 80.


Now why would you do this? If you look on the right - you will see one reason - no snapshots, which will save precious disk space. Second reason  - no replication is needed (unless of course this is a requirement)

Some say this is a risk - because if your datastore with the vswp files goes down then all your VM’s go down, which in essence is true - but… Since in most cases the datastore is just another volume on the same storage array from which the VM’s are running from - the chance of the vswp datastore failing is equal to that of the chance that VM’s datastore will fail.

So my question at the end of the day. Is the warning still valid when you define a shared datastore - one which all the ESX hosts in that cluster can access?

There is of course a certain overhead needed to set this option on each ESX host in the cluster - but that is not (IMHO) so much of an issue.

Looking forward to your comments.