WilliamLam.com

Script: Updated ghettoVCB and ghettoVCBg2 to Support vSphere 4.1

by // 21 Comments

Check out the latest update to both ghettoVCB and ghettoVCBg2, which now supports vSphere 4.1! There are no new features introduced with these updates but ghettoVCB does include additional logging and debugging functionality to help identify issues that may arise. Unfortunately, with ghettoVCBg2 I had to perform some additional code changes due to undocumented changes in vMA's vi-fastpass Perl library. This initially caused the script to break and the reason was deprecated methods that were removed in the latest release of vMA 4.1. Luckily the fix was not too bad and I had to spend a few hours looking at the new methods that were implemented.

Hopefully everyone enjoys these two releases and if you run into any troubles, please post in respective script's forum.

vMA 4.1 - Authentication Policy (fpauth vs adauth)

by // 5 Comments

I recently wrote an article about vMA 4.1 and Active Directory Integration and today I noticed there were some confusion on the expected behavior of the two types of authentication policy: vi-fastpass authentication versus Active Directory authentication. There are actually a few things to consider:

  • What user context are you trying to execute a command against a target?
  • What authentication policy was used to add the target to vMA?
  • Is vMA host joined to an Active Directory Domain?
USER CONTEXT FPAUTH or ADAUTH vMA in AD DOMAIN
vi-admin fpauth no
DOMAIN\username adauth yes

[Read more...]

resxtop & vi-fastpass Downgraded Feature In vMA 4.1

by // 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.