I recently noticed a thread in the vMA forums regarding an issue using resxtop on vMA 4.1 to view VM disk statistics on an ESXi 4.0 hosts. The thread was started on July 26th 2010 and as far as I could tell, no resolution was ever provided. A recent comment that was left on Oct 14th 2010 by another user experiencing the same behavior got my attention while browsing the VMTN forums. I decided to perform a small test to see if this was in fact an issue and it turns out it maybe a bug in resxtop running on vMA 4.1.

The test environment consists of the following:

• 1 x vESXi 4.0u2 running 1 VM
• 1 x vESXi 4.1 running 1 VM
• 1 x vMA 4.0
• 1 x vMA 4.1

Here is a screenshot of running esxtop locally within Tech Support Mode (Busybox console) on the ESXi 4.0 hosts and you can see, the VM disk statistics are visible and present:

Here is a screenshot of running esxtop locally within Tech Support Mode (Busybox console) on the ESXi 4.1 hosts and you can see, the VM disk statistics are visible and present:

Now here is a screenshot of running both vMA 4.1 (on top) and vMA 4.0 (on bottom) connecting to an ESXi 4.0 host running a single virtual machine called VM2. I use resxtop to connect to the ESXi 4.0 and select "v" option or VM disk statistics and as you can see from the screenshot, no statistics are being displayed when using vMA 4.1:

I perform the same exact test but now connecting to an ESXi 4.1 host using both vMA 4.1 (on top) and vMA 4.0 (on bottom) and what is actually surprising is, the VM disk statistics shows up for both vMA 4.0 and vMA 4.1:

It looks like something changed in the resxtop binary between vMA 4.0 and vMA 4.1 that causes the the VM disk statistics on ESX(i) hosts running on 4.0 not to be visible. I have not found any VMware KB articles documenting this issue nor found anything in vMA's release notes in which this configuration is not supported. This looks like a bug to me and I will try follow-up with the vMA's product manager to get an official word.

Note: I used ESXi since it was quicker to deploy for this test, but the issue affects both ESX and ESXi 4.0 when using resxtop from vMA 4.1

UPDATE:  After further investigation, I found out the issue is in fact with vCLI 4.1 installation and not with vMA 4.1. To confirm, I spun up a CentOS VM and installed and individually tested vCLI 4.0u2 and vCLI 4.1 and experience the same behavior as in vMA. I have already reported the issue to vMA product manager and hopefully we can get this resolved in either a patch or an updated released.

For those that use VMware's vMA vi-fastpass authentication (vifpinit which is now vifptarget) which allows a user to perform an operation on an ESX(i) or vCenter host without having to provide credentials each time, may notice a change with the resxtop command. In vMA 4.0, if you initialized a fastpass target you could run resxtop against the host without having to provide additional credentials to the host.

In vMA 4.1, this functionality has actually been downgraded, that is right, a feature de-enhancement.

As you can see, even if you have initialized a fastpass target, you will need to specify both the username and password each time you call resxtop. resxtop only supports manual credentials and does not support other types of authentication mechanisms such as a configuration file, session file or passthrough auth. This can definitely slow things down if you are trying to troubleshoot multiple hosts and want to switch between them utilizing the fastpass authentication.

What is actually more interesting is this seems to be a feature that has been in the works over the 3 major releases of vMA, which was formally known as VIMA. Let's take a trip down memory lane regarding this feature in the vMA/VIMA release notes:

VIMA 1.0 - Oct 27, 2008 - Feature not supported and marked as a known issue.

vMA 4.0 - May 21, 2009 - Feature supported but may run into an issue with non-fastpass targets which has been resolved in this release.

vMA 4.1 - July 13, 2010 - Feature has been removed, requires both --username and --password each time.

 
Even though I consider this a bug, VMware did document this change as a "known issue" in the release notes. I am not sure if this feature will be resolved in a future release, but it just seems odd that we are taking one step backwards in terms of functionality.