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.

4 thoughts on “resxtop & vi-fastpass Downgraded Feature In vMA 4.1

  1. just felt onto it today, deployed a vMA 4.1 and noticed the same issue 🙁
    i was planning to blog about, but it seems you’ve been faster hehe 🙂
    hoping this issue will be fixed soon.

  2. That’s certainly annoying.
    vMA 4.1 also still uses HW Version 4 und has a tiny /var/log partition.

  3. @Anonymous

    Actually vMA 4.0 was also on HW Version4, this is done for compatibility if you wanted to run vMA on VI 3.5 which is supported. Also, /var/log is approximately the same size from vMA 4.0, it’s only 2MB smaller. Yes the default for /var/log is small but you can easily increase the size or add another VMDK for dedicated logs


Thanks for the comment!