WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / resxtop & vi-fastpass Downgraded Feature In vMA 4.1

resxtop & vi-fastpass Downgraded Feature In vMA 4.1

07.19.2010 by William Lam // 4 Comments

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.

More from my site

  • resxtop bug in vCLI 4.1 not vMA 4.1
  • How to configure and use vMA's vi-fastpass with fpauth and adauth on vSphere 4.1
  • Why you should upgrade from vMA 4.0 to vMA 4.1
  • vMA 4.1 - Authentication Policy (fpauth vs adauth)
  • vMA 4.1 - Active Directory IntegrationTip

Categories // Uncategorized Tags // resxtop, vma, vSphere 4.1

Comments

  1. *protectedB. Riley says

    07/19/2010 at 1:53 pm

    Ouch. Looks like I'll be using 4.0 for the foreseeable future. Thanks for the heads-up.

    Reply
  2. *protectedvirtunix says

    07/19/2010 at 2:58 pm

    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.

    Reply
  3. *protectedAnonymous says

    07/27/2010 at 8:36 am

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

    Reply
  4. *protectedWilliam says

    07/28/2010 at 5:54 am

    @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

    --William

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025