Quite a mouthful, eh? If you have a chance to add some SSDs to your blades, though, I think you will be happy with the results. See the VMware vSphere 5.1 Documentation Center for details on how ESX uses write back cache for virtual machine swap files.

First, get some SSDs and put them in your B2XX series blades and configure a local disk policy. I was lucky enough to get two drives per blades, so I set the local disk policy to RAID1.

You could go with RAID0, but I plan on using the local disks for A/V offload with vShield End-Point protection, so i wanted a bit more surety.

When the blade boots, you will be dismayed to see your new disks listed as “remote” during the ESX install. This is expected, see Scott Lowe’s post on it for an explanation. It isn’t a problem unless you are trying to use your disks for the ESX scratch disk- we are going to be using the disk for VM swapping, not the ESX Host, so we have one less step to do- see here for a vreference.

Finish your install and either drag the ESX box into vCenter or connect with the tools directly to the host. Create a new datastore from the local disks as you usually would. I recommend using a meaningful name, like _Local_SSD. If you use Host Profiles, you will want to uncheck the relevant checkboxes under Storage before pushing the Profile down to other hosts.

With your host selected, go to the “Configuration” tab and look under “Software”. You see a new link called “Host Cache Configuration”. Click it, and you will not see the disks you added.

Oh joy, we get to play with Putty. Connect to your host with Putty (don’t forget to turn on SSH in your security settings) and get ready to paste some commands. Leave your VMware tools showing “Storage”, you will want to refer back here for the super long naa numbers.

At this point, I could point out the numerous ways you could use PowerCLI, scripts or the vMA to do the same thing, but I think it better to learn how to do it from the command line first. Let’s get an understanding of the big list of values we are trying to manipulate first. We need to add a new value to the list of possible “Storage Array Type Plugins (SATPs)”. Refer to this great post by Stephen Foskett for more on SATPs and the PSA.

Type in “esxcli storage nmp satp rule list” into your putty session and hit enter to see all the SATPs your host knows about:

~ # esxcli storage nmp satp rule list

We need to add a line to end of this list, so that your SSD disk (which ESX is seeing as a SAS disk on the SAN) can use the “VMW_SATP_LOCAL” SATP. First, we need to get the naa of your drive. Look in the VMware tools at your disk, click on “Manage Paths” and you will see the naa number. In this case, mine is “naa.600508e0000000006c793530aa10e80e”. You can get this in Putty, but I like to check in the GUI, because Putty can be hard to read. Don’t bother typing it out, enter:

~ # esxcli storage nmp device list

~ # esxcli storage core device list -d  naa.600508e0000000006c793530aa10e80e

The “Is SSD: false” is what we need to change. We want to add a new rule for the VMW_SATP_LOCAL SATP, one that has option=enable_ssd

~ # esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device  naa.600508e0000000006c793530aa10e80e --option=enable_ssd

If you up arrow a few times and enter “esxcli storage nmp satp rule list”, you’ll see a new line at the bottom.

VMW_SATP_LOCAL       naa.600508e000000000bd5fc37cdb32b60d                 enable_ssd        user

Now unclaim the device

~ # esxcli storage core claiming unclaim --type device  --device naa.600508e0000000006c793530aa10e80e

and finally reload and run the claim rules

~ # esxcli storage core claimrule load
~ # esxcli storage core claimrule run

Now lets see if it worked

~ # esxcli storage core device list -d  naa.600508e0000000006c793530aa10e80e

You should now have a new disk listed under “Host Cache Configuration”.

Pick an amount to use, saving a little room for A/V VMs if need be.

Now add some VMs and browse the datastore to see your new swap files, and make sure to show the SAN guys on your team how you’re saving precious SAN resources.