WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Script: Updated ghettoVCB and ghettoVCBg2 to Support vSphere 4.1

07.22.2010 by William Lam // 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.

Categories // Uncategorized Tags // ghettoVCB, ghettoVCBg2, vSphere 4.1

vMA 4.1 - Authentication Policy (fpauth vs adauth)

07.21.2010 by William Lam // 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

I will try to explain the following two scenarios listed above.

In this example, vMA was not joined to an Active Directory Domain and we are adding a vCenter target to vMA using a local administrator account on vCenter server (by default, fpauth is assumed):

[vi-admin@tancredi ~]$ sudo vifp addserver manaslu.primp-industries.com
Enter username for manaslu.primp-industries.com: administrator
*protected email*'s password:
This will store username and password in credential store which is a security risk. Do you want to continue?(yes/no): yes

We can verify the target was added using fpauth by running the following command:

[vi-admin@tancredi ~]$ vifp listservers -l

esx4-1.primp-industries.com ESX fpauth
esxi4-3.primp-industries.com ESXi fpauth
manaslu.primp-industries.com vCenter fpauth

Next, we will set the fastpass target to the newly added vCenter server:

[vi-admin@tancredi ~]$ vifptarget -s manaslu.primp-industries.com

[vi-admin@tancredi ~][manaslu.primp-industries.com]$

If we run "esxcfg-nics -l" against an ESX(i) host that is being managed by this vCenter, we would do the following (note: user context is vi-admin):

[vi-admin@tancredi ~][manaslu.primp-industries.com]$ esxcfg-nics -l --vihost esxi4-3.primp-industries.com

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 02:00.0 e1000 Up 1000Mbps Full 00:50:56:ac:69:95 1500 Intel Corporation PRO/1000 MT Single Port Adapter

In this first example, we are relying solely on vi-fastpass authentication, where a vi-adminXX account is created on the target. The credentials to this account is generated by vMA and stored in the local credential store.

In this example, vMA has been joined to an Active Directory Domain and we are adding a vCenter target using Active Directory credentials:

[vi-admin@tancredi ~]$ sudo vifp addserver reflex.primp-industries.com --authpolicy adauth
Enter username for reflex.primp-industries.com: PRIMP-IND\primp

Note: As of writing this, there is a typo in vMA 4.1 documentation on the syntax to use when specifying the username when prompted. You will need to use DOMAIN\username, if you decide to use the --username, then you need to add a second "slash" to escape the first (e.g. DOMAIN\\username)

We can verify the target was added using adauth by running the following command:

[vi-admin@tancredi ~]$ vifp listservers -l

esx4-1.primp-industries.com ESX fpauth
esxi4-3.primp-industries.com ESXi fpauth
manaslu.primp-industries.com vCenter fpauth
reflex.primp-industries.com vCenter adauth

Next, we will set the fastpass target to the newly added vCenter server but before we do so, we need to login to vMA using a valid Active Directory account.

[primp@tancredi ~]$ vifptarget -s reflex.primp-industries.com

[primp@tancredi ~][reflex.primp-industries.com]$

Now if we run "esxcfg-nics -l" against an ESX(i) host that is being managed by this vCenter, we would do the following (note: user context is DOMAIN account):

[primp@tancredi ~][reflex.primp-industries.com]$ esxcfg-nics -l --vihost himalaya.primp-industries.com

Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic0 06:00.0 e1000e Up 1000Mbps Full 00:30:48:d9:58:6a 1500 Intel Corporation 82574L Gigabit Network Connection
vmnic1 07:00.0 e1000e Down 0Mbps Half 00:30:48:d9:58:6b 1500 Intel Corporation 82574L Gigabit Network Connection

In this second example, we are relying solely on Active Directory authentication, where credentials of the user that is logged into vMA are being used. Unlike in the first example, if you were in the vi-admin context and tried to execute the same command, you will notice you are prompted for credentials. This is the intended and expected behavior of the two scenarios.

However, if you do not want to join vMA to an Active Directory Domain but would still like to perform an unattended authentication from vi-admin context, then you need to setup a Kerberos ticket for the target. The details on configuring this is outlined in vMA 4.1 user guide, please refer to the document for more details.

One thing to note which I actually ran into, is that when you join your vMA host to Active Directory Domain, you must reboot vMA after joining to the domain. If you do not, you will run into issues when trying to add a target using adauth authentication policy.

Categories // Uncategorized Tags // vi-fastpass, vifp, vma, vSphere 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.

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

  • « Previous Page
  • 1
  • …
  • 546
  • 547
  • 548
  • 549
  • 550
  • …
  • 561
  • Next Page »

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

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • 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

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