WilliamLam.com

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.

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.