Thursday, 26 April 2012
The objective of this white paper is to provide information on storage protocols and how they interoperate with VMware vSphere and related features. Not all supported storage protocols are discussed. Some notable exceptions are ATA over Ethernet (AoE) and shared/switched SAS. However, the protocols that are included in this paper are the ones that VMware is most frequently asked to compare.
VMware frequently is asked for guidance regarding the best storage protocol to use with VMware vSphere®. vSphere supports many storage protocols, with no preference given to any one over another. However, many customers still want to know how these protocols stack up against each other and to understand their respective pros and cons.This white paper looks at common storage protocols from a vSphere perspective. It is not intended to delve into performance comparisons, for the following two reasons:
- The Performance Engineering team at VMware already produces excellent storage performance white papers.
- Storage protocol performance can vary greatly, depending on the storage array vendor. It therefore does not make sense to compare iSCSI and NFS from one vendor, because another vendor might implement one of those protocols far better.
Monday, 23 April 2012
Updated in Version 3.3 (April, 2012)
- GetWebResponse timeout value changed from 5 minutes to 10 minutes (for very big environments)
- New tabpage with HBA information
- On vDatastore tab the definition of the Provisioned MB and In Use MB columns was confusing! This is changed now.
- RVToolsSendMail accepts now multiple recipients (semicolon is used as separator)
- Folder information of VMs and Templates are now visible on vInfo tabpage
- Bugfix: data in comboboxes on filter form are now sorted
- Bugfix: Problem with api version 2.5.0 solved
- Bugfix: Improved exception handling on vCPU tab.
- Bugfix: Improved exception handling on vDatastore tab.
Kudos to fellow vExpert Rob de Veij - get your laters copy here http://www.robware.net
esxplot is a GUI application that lets you explore the data collected by esxtop in batch mode. The program takes a single command line argument which is the esxtop batch mode output file. You can also simply start esxplot without any arguments, and enter a dataset file via the File attribute of the menu bar. Esxplot loads the data in this file and presents the metrics as a hierarchical tree where the values are selectable in the left panel. In the right panel, a graph is plotted (value over time) of the selected metric, in this way, you can “browse” the contents of these somewhat unwieldy files.
Geoff White over at durganetworks has Forked esxplot 1.0, watch github for improvements in performance, stability and features. Currently the esxplot 1.5 ALPHA code is available for download.
Eric, I want to thank you for alerting the community to the fork. The current code base has been reworked under the hood a bit to allow for actual continued development which was difficult with the original, single file version. The forked code is not packaged for the "end user", there isn't an installable package for windows or even an egg or easy install just yet.
What I would like interested parties to do for now is to follow the repository, and try it out when you hear of a feature that you think you would be interested in. I also need folks to test this out on vSphere 5. I've seen an elusive behavior with the 1.0 version where it seemed that data was being reported in a 'skewed' fashion which, if it's a bug in esxplot, it would be somewhat serious.
The problem is that I've observed it on a single vSphere 5 host, and then when I changed the state of the host, (powered off a VM) the problem disappeared. I've added extra debugging code into this fork to try and log any bad data being read in (the 1.0 version would just silently ignore it) to try and catch this. If anyone has seen this using the 1.0 version, please report it to me so we can get to the bottom of this. I need to isolate if this is a bug in esxplot or a bug in the way esxtop is writing the csv in batch mode. So the number one priority for me right now is to get to the bottom of the possible bug.
The number two priority is to fix the way the metric selection works so that it is easier to navigate and so that start-up time and response time will decrease with large data sets (> 150 MB). This work should also allow users to load larger data sets without the program becoming unresponsive. The number three priority is the WHERE clause that I've been alluding to in the past which will allow some limited visibility into the actual data when you are pruning the result set with a search query. You can read about it in the repository wiki. This is also a good time to put in feature requests. For now, you can go over to the github repository and add an issue.
I am not going to move away from wxPython for the 1.x release but I am entertaining a new GUI model for the 2.x version, what i'm currently looking at is jPlot/JQuery and/or QT5. I'm glad the program has been useful to folks over the years, my apologies for not updating it sooner, but this was not a primary job function (still isn't :) but a labor of necessity and love.