WilliamLam.com

How to automate vFRC configurations using the command-line in ESXi

by // 1 Comment

While working on my vSphere Flash Read Cache (vFRC) articles last week, I wanted to be able to quickly build out my vSphere environment so that vFRC was fully configured as part of my ESXi installation using a Kickstart script. This would allow me to simply add my ESXi hosts into vCenter Server and not have to go through the vSphere Web Client for each host configuring vFRC. Now of course the vSphere Web Client is not the only option to configure vFRC, you can also use the vSphere APIs by creating your own script or even using the new vFRC PowerCLI cmdlets as an alternative.

However, I was interested in creating a very simple script that I could easily integrate with my kickstart deployment as that is what I am using for automated provisioning of my Nested ESXi hosts. With a bit of research and some trial/error, I have come up with a process that can be fully automated from the command-line of ESXi. In my environment I have a Nested ESXi host that contains three SSD's (4GB each) which will be used to construct my Virtual Flash Resource.

Note: Jump to the very bottom for a completely automated script to configure vFRC for your ESXi host.

Step 1 -You will want to list out the available SSD devices on your ESXi host, you can do so by using the following ESXCLI command:

esxcli storage vflash device list

You will need to make a note of the device ID's as they will be required in the sub-sequent steps.

Step 2 - Next we will need to partition our devices before we can create VFFS (Virtual Flash File System) and we will need to calculate the end sector if we wish to consume the entire device. To do so, we will need to use the partedUtil command and specify the "getptbl" option to identify some information.

partedUtil getptbl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009

You will need to make a note of the first three numbers which represents number of cylinders, number of heads and number of sectors per track. To calculate the end sectors, the equation will be the following: (Number of Cylinders x Number of Heads x Number of Sectors Per Track) - 1

In our example we have (522*255*63)-1 which gives us 8385929

To create the partition, we will again use the partedUtil and specify "setptbl" option by running the following command (ensure to replace your end sector value):

partedUtil setptbl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009 "gpt" "1 2048 8385929 AA31E02A400F11DB9590000C2911D1B8 0"

For more details on using the partedUtil command, please refer here and here.

Since my other two devices are exactly the same size, I can just re-use the command and replace the device path. Ensure all devices that you wish to use in your Virtual Flash Resource is partition before moving onto the next step.

Step 3 - We will now create our VFFS volume which only needs to be created on one of the devices. In this example, I have chosen to use the first SSD device as shown in "esxcli storage vflash device list". To create the VFFS volume we will use the vmkfstools tool just like we would if we were creating a VMF volume but instead use the "vmfsl" type.

Run the following command to create your VFFS volume, you will need to append :1 to the end of the SSD device to specify the partition you created earlier as well as a display name of the volume which I chose vffs-$(hostname -s) which will use the short hostname of the ESXi host

vmkfstools -C vmfsl /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009:1 -S vffs-$(hostname -s)

Step 4 - Once you have your VFFS volume created, you can extend it with additional SSD devices by using vmkfstools and specifying the -Z option. The syntax for the command is the SSD device partition you wish to add followed by the source SSD device containing the VFFS volume.

Here is an example of the command:

vmkfstools -Z /vmfs/devices/disks/naa.6000c29498be5c56231d631d9c6cbee8:1 /vmfs/devices/disks/naa.6000c2932c4ed8a540b6e9f0be9e1009:1

You will be prompted on whether you want to extend and to confirm enter value of 0.

You will need to do this for all SSD devices you partition earlier to be part of the same VFFS volume.

Step 5 - To confirm that everything was configured correctly, we will use vmkfstools to query our VFFS volume by running the following command and specifying the path to our VFFS volume:

vmkfstools -Ph /vmfs/volumes/vffs-vesxi55-10

From the output we should see the filesystem for the volume is of type VFFS and we should also see the three SSD devices that is backing this VFFS volume as shown in screenshot above.

Step 6 - Finally to make this new VFFS volume visible to the ESXi host, we will need to refresh the ESXi storage system and we can do so by running the following vim-cmd:

vim-cmd hostsvc/storage/refresh

At this point, we now have a fully configured VFFS volume. If you jump right into the vSphere Web Client expecting to see your new Virtual Flash Resource on your newly configured ESXi host, you might be in for a surprise! You will actually NOT see the VFFS volume that we just configured which stumped me initially.

It turns out simply creating a VFFS volume does not automatically equate to configuring a Virtual Flash Resource. You still need to configure the ESXi host to add the Virtual Flash Resource based on your VFFS volume and in my opinion that seems to be quite odd and counter-intuitive. Today there is no CLI command to add the Virtual Flash Resource, you would need to use either the vSphere Web Client or use the vFRC vSphere API. If you login to the vSphere Web Client and configure a Virtual Flash Resource, you will see the VFFS volume that we have created and you just need to select it and it will automatically add it.

This is not very ideal if you want to completely automate vFRC configurations and I decided to leverage my knowledge of the vFRC vSphere APIs and create a very simple python script that would call into the ESXi host's MOB and issue the HostConfigureVFlashResource() method. This was sort of a quick/dirty way to call the vSphere API and add in the Virtual Flash Resource.

Disclaimer: These scripts are provided as examples, please test these scripts in your development/test environment before running them in production.

To make this really useful I have created two scripts that can be embedded into either a kickstart script or executed manually. The script will automatically perform the above operations above as well as configure the Virtual Flash Resource without any user input/intervention.

The main script is called configurevFRC.sh which is a shell script that performs the majority of the work and it then it calls the python script which is called addVirtualFlashResource.py (ensure you change the password variable in the script) for adding the Virtual Flash Resource. You need to download both scripts and run them on the ESXi Shell.

Here is the contents of configurevFRC.sh (you can download both scripts using the links above):
Here is a sample execution of configurevFRC.sh script:

In the future I hope we can completely automate vFRC configurations from the command-line as we can using the vSphere Web Client or vSphere APIs. For now, this solution will help get you around the limitations we have in the command-line utilities.

HostConfigureVFlashResource

Exploring the vSphere Flash Read Cache (vFRC) APIs Part 3

by // Leave a Comment

To conclude our 3-part blog series in exploring the vSphere Flash Read Cache (vFRC) APIs, in this last article we will take a look at the vSphere APIs required to live migrate a running Virtual Machine which has been configured with vSphere Flash Read Cache. If you perform this migration using the vSphere Web Client, you will see that you are now presented with a new option in the migration wizard on whether or not to migrate the vFRC cache.

If you choose to migrate the vFRC cache, you have the option to migrate all of the Virtual Machine's vFRC cache or you can specify this on a per VMDK basis by selecting the "Advanced" option. By choosing to migrate the vFRC cache, the migration will of course take longer as it needs to not only transfer the running Virtual Machine, but also the vFRC cache.

To automate this operation from an API perspective, you will need to use the Virtual Machine RelocateVM_Task method. As part of creating the migration spec, there is a new property called migrateCache which can now be specified on each VMDK.

To demonstrate the use of this vSphere API, I have created a vSphere SDK for Perl sample script called migratevFRCVM.pl which accepts the name of the Virtual Machine to migrate, the name of the ESXi host to migrate to and an optional parameter on whether or not to migrate the vFRC cache. By default, the script will migrate the vFRC cache if no option is selected.

Here is an example of migrating a VM along with its configured vFRC cache:

./migratevFRCVM.pl --config .vcenter55-1 --vmname Test-VM --dst_vihost vesxi55-10.primp-industries.com --migrate_cache true

Note: I have simplified the script to apply the --migrate_cache to ALL VMDKs, but as mentioned earlier you can specify this on a per-VMDK basis so you can migrate the vFRC cache for specific virtual disks if you choose to.

Hopefully you have enjoyed this series and now have a better understanding of the vSphere Flash Read Cache APIs. Be sure to check out the other two articles if you have not already.

Exploring the vSphere Flash Read Cache (vFRC) APIs Part 2

by // Leave a Comment

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 vflashHostMgmt.pl 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:

./vflashHostMgmt.pl --config .vcenter55-1 --vihost vesxi55-4.primp-industries.com --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:

./vflashHostMgmt.pl --config .vcenter55-1 --vihost vesxi55-4.primp-industries.com --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:

./vflashHostMgmt.pl --config .vcenter55-1 --vihost vesxi55-4.primp-industries.com --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:

./vflashHostMgmt.pl --config .vcenter55-1 --vihost vesxi55-4.primp-industries.com --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:

./vflashHostMgmt.pl --config .vcenter55-1 --vihost vesxi55-4.primp-industries.com --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.