Continuing from Part 1 of Exploring the vSphere Flash Read Cache (vFRC) APIs, we will now explore the necessary vSphere APIs to setup and configure vFRC on your ESXi host. There are two workflows in which you can create your Virtual Flash Resource, the first is simply adding all valid SSDs as you would when using the vSphere Web Client which automatically creates a VFFS (Virtual Flash File System) which is used to manage the underlying SSD devices. The second workflow is to start with a single SSD and to manually create the VFFS volume which then allows you to extend the VFFS by adding additional SSD devices. We will be going over both set of workflows and the necessary vSphere APIs required to perform these operations.

To automate the configuration of vFRC on your ESXi hosts, you will need to access both vFlashManager and storageSystem along with the following vSphere API methods:

  • QueryAvailableSsds
  • ConfigureVFlashResourceEx_Task
  • DestroyVffs
  • FormatVffs
  • HostConfigureVFlashResource
  • ExtendVffs

To demonstrate the functionality of these vSphere APIs, I have created a vSphere SDK for Perl sample script called and it supports the following operations: query, listssd, add, format, extend and destroy

Workflow 1 - Add all valid SSD devices

To configure a Virtual Flash Resource for your ESXi host, you will need to use the vSphere Web Client and click on the "Add Capacity" button and select all valid SSD devices for that particular ESXi host as seen in the screenshot below.

To automate the same workflow, we first need to be able to identify the list of available SSD devices that could be used for either vFRC or even VSAN. There is a nice vSphere API method under the storageSystem called QueryAvailableSsds which has been implemented in the script as the "listssd" operation.

Here is an example execution of the "listssd" operation:

./ --config .vcenter55-1 --vihost --operation listssd

As you can see from the output we have three available SSD devices matching the vSphere Web Client output. To add these SSD devices and create your Virtual Flash Resource, you will need to use the "add" operation within the script that accepts a comma seperated list of the SSD device paths as shown in the above output. Next we need to call the vFlashManager's ConfigureVFlashResourceEx_Task method which thnan accepts an array of SSD device paths to automatically configure and add the Virtual Flash Resource.

Here is an example execution of the "add" operation:

./ --config .vcenter55-1 --vihost --operation add --disk /vmfs/devices/disks/naa.6000c297de55bcf0471f311abc865449,/vmfs/devices/disks/naa.6000c2992cfbf14a2d827303c48632fa,/vmfs/devices/disks/naa.6000c2989357b5d31eb20256e39f9338

We can confirm that our Virtual Flash Resource was successfully created by running the "query" operation.

Here is an example execution of the "query" operation:

./ --config .vcenter55-1 --vihost --operation query

From the output we can see a VFFS was automatically created for us including its name and UUID and it contains the three SSD devices we added in earlier. We can also confirm by logging into our vSphere Web Client and we should see the same output as well.

In preparation for the next workflow, we can easily destroy our VFFS which is the same operation within the vSphere Web Client by selecting the "Remove All" button. To do so, we need to use the storageSystem's DestroyVffs method. In the script, this has been implemented as the "destroy" operation.

Here is an example execution of the "destroy" operation:

As you can see workflow 1 is pretty straight forward if you have an ESXi host that contains all the SSD devices you wish to add to your Virtual Flash Resource. In workflow 2, we will take a look at starting with a single SSD and manually creating the VFFS which can then be extended OR if you have an existing Virtual Flash Resource and would like to extend it, the set of APis shown in workflow 2 will aide in that use case.

Workflow 2 - Create VFFS using single SSD device / Extend VFFS

When going through workflow 1, the VFFS volume is automatically created for the user and is not something on would need to think about unless you would like to extend an existing VFFS. In this workflow we start out by adding a single SSD device which will require the creation of VFFS volume and then we will then extend that VFFS with additional SSD devices so we end up in the same end state as workflow 1.

To create a VFFS, you will need to use the FormatVffs API method which accepts a single SSD device and VFFS label and then using the HostConfigureVFlashResource API method to mount the VFFS volume to the ESXi host. This has been implemented as the "format" operation which is similar to the "add" operation but require an additional --vffs parameter which denotes the VFFS volume label.

Here is an example execution of the "format" operation:

./ --config .vcenter55-1 --vihost --operation format --vffs vghetto-vffs --disk /vmfs/devices/disks/naa.6000c297de55bcf0471f311abc865449

As part of the result, it will return the VFFS UUID which is required when extending a VFFS. You can also get this information by using the "query" operation which we can also see the label that we have assigned our VFFS.

To add additional SSD devices to our existing VFFS using either workflow 1 or 2, you will need to use the ExtendVffs API method which requires the VFFS UUID and the SSD device you wish to add. This has been implemented as the "extend" operation within the script.

Here is an example execution of the "extend" operation:

./ --config .vcenter55-1 --vihost --operation extend --vffs_uuid 527fc6e6-249cdb69-d502-005056adfa73 --disk /vmfs/devices/disks/naa.6000c2992cfbf14a2d827303c48632fa

We can confirm our changes by using the "query" operation as well as looking at our Virtual Flash Resource using the vSphere Web Client. We should see the two SSD devices that we have added to our VFFS.


In Part 3 of exploring the vSphere Flash Read Cache (vFRC) APIs, we will take a look at migrating a virtual machine which has vFRC configured and the options we have in terms of either migrating or dropping the vFRC cache.

Thanks for the comment!