How to Trick ESXi 5 in seeing an SSD Datastore

In vSphere 5, there is a new feature called Host Cache which allows a user to offload the virtual machine's swap onto a dedicated SSD device for better performance. This is done by creating a VMFS volume on an SSD device which is then detected by SATP (Storage Adapter Type Plugin) and allows a user to add and configure a VMFS datastore for host caching.

 

 

During the vSphere 5 beta, I was testing out various new features including Host Caching but did not have access to a system with an SSD device while updating and creating a few new scripts. After some research I found that if a default SATP rule is not available to identify a particular SSD device, that a new rule could be created containing a special metadata field specifying that it is an SSD device.

 

In the following example, I will take a local virtual disk (mpx.vmhba1:C0:T2:L0) in a vESXi 5.0 host and trick ESXi into thinking that it is an SSD device.

 

 

We will need to use esxcli whether that is directly on the ESXi Shell or using vMA and/or PowerCLI esxcli's remote version.

 

Note: The following assumes there is already a VMFS volume created on the device you want to present as an SSD device, if you have not done so, please create a VMFS volume before continuing

 

First you will need to create a new SATP rule specifying your device and specifying the "enable_ssd" string as part of the --option parameter:

 

~ # esxcli storage nmp satp rule add -s VMW_SATP_LOCAL -d mpx.vmhba1:C0:T2:L0 -o enable_ssd

 

You can verify that your rule was created property by performing a list operation on the SATP rules:

 

~ # esxcli storage nmp satp rule list | grep enable_ssd
VMW_SATP_LOCAL mpx.vmhba1:C0:T2:L0 enable_ssd user

 

Next you will need to reclaim your device so that the new rule is applied:

 

~ # esxcli storage core claiming reclaim -d mpx.vmhba1:C0:T2:L0

 

You now can verify from the command line that your new device is being seen as an SSD device, by displaying the details for this particular device:

 

~ # esxcli storage core device list -d mpx.vmhba1:C0:T2:L0
mpx.vmhba1:C0:T2:L0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T2:L0)
Has Settable Display Name: false
Size: 5120
Device Type: Direct-Access
Multipath Plugin: NMP
Devfs Path: /vmfs/devices/disks/mpx.vmhba1:C0:T2:L0
Vendor: VMware
Model: Virtual disk
Revision: 1.0
SCSI Level: 2
Is Pseudo: false
Status: on
Is RDM Capable: false
Is Local: true
Is Removable: false
Is SSD: true
Is Offline: false
Is Perennially Reserved: false
Thin Provisioning Status: unknown
Attached Filters:
VAAI Status: unsupported
Other UIDs: vml.0000000000766d686261313a323a30

 

As you can see the "Is SSD" field is not being populated as true where as before if you ran this command, it would display false

 

Now you can refresh the Storage view on the vSphere Client or you can do so from the command line by running the following command:

 

~ #vim-cmd hostsvc/storage/refresh

 

Now if you go back to the vSphere Client under "Host Cache Configuration" you should see the new fake SSD device for selection and you just need to configure it and Host Cache is enabled for this device.

 

 

This of course is probably not officially supported unless directed by VMware nor is there a real good reason for this. I personally had to go down this route for scripting purposes but if you wanted to see how Host Cache works, this is a neat trick to allow you to do so.