WilliamLam.com

Quick Tip - Useful Flash Player optimization for the vSphere Web Client & other Flash WebApps

by // 11 Comments

I recently picked up a useful tidbit from engineering on a Flash Player optimization setting that can be helpful when using the vSphere Web Client or any other Flash web application for that matter. The particular setting is the Website Storage Settings which controls the amount of temporary data that can be stored by the Flash Player on your local disk and by default this is limited to 100Kb. This limited storage footprint is actually done on purposes as a security feature of Flash.

However, at some point the Flash Player will reach this limit and prompt the user to allow additional disk space to be consumed and this is where you may see the vSphere Web Client crash and you would to go through the motions of logging back in.

To avoid this scenario, you can change the default 100Kb to unlimited for a particular site which I was recommended so that I would not hit this problem. I do want to stress that this is not a VMware best practice but more of a general Flash Player best practice but I think it is something to be aware of and could help from a usability perspective.

To check your current settings, Adobe has made it very simple by just navigating to the following URL: http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

A panel will load and you will get access to a variety of Flash Player settings including the Website Storage Settings which is what the link above will default to.

You will now be able to browser to the particular website, in our case we will be looking for either the hostname or IP Address of your vSphere Web Client Server and you will be able to see its current usage as well as limit. To change the default, you just need to click on the website and then move the toggle at the top to the far right which will show up as "unlimited". I would recommend you make this change for all your vSphere Web Client servers that you access. It would have been nice to see our vSphere Web Client automatically detect this and recommend the change or automatically default to this setting.

Heads Up: Workaround required for resxtop to function in vMA 5.5

by // 2 Comments

If you are using the latest version of vMA 5.5, there is currently a known issue when using resxtop. After successfully logging into the ESXi host, the command prompt is returned immediately and resxtop is not actually loaded.

Here is a screenshot of the behavior:

I have received word from engineering there is a workaround that is required to get resxtop working, which is to run the following command:

sudo mv /usr/lib/vmware-rcli/lib/ /usr/lib/vmware

Once you have executed the above command (only required once), you now will be able to connect to your ESXi host using resxtop.

Engineering is working on getting the vMA release notes updated as well as a KB article published and we will have fix for this in the a sub-sequent update/patch release of vMA.

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.