Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I follow the instruction in Official vMA Guide 5.1(pdf), and I'm baffled by the following operation(described in p18~p19).

snap0390-vmaguide-p18.png

I have joined my vMA to my Windows AD velab.chj , reboot vMA, then operate as follows:

snap0391-cannot-execute-esxcli-as-ADuser.png

As you can see, I cannot execute esxcli system version get with the identity of a Windows AD user(chjadmin). I think that's reasonable, because the ESXi host has not assign any permission to, or even does not know the existence of, the AD user chjadmin.

So, my question is, how to configure ESXi host to allow chjadmin's execution of the esxcli command? The official vMA guide does not seem to talk about this.

share|improve this question

2 Answers 2

up vote 2 down vote accepted

The vMA guide assumes you have already taken steps to join your ESXi host to your Active Directory and granted permissions that would allow the running of those commands.

The relevant documentation can be found here in the ESXi and vCenter Server 5.5 Documentation. Specifically in the section vSphere Security - Securing ESXi Hosts - Using Active Directory to Manage ESXi Users.

share|improve this answer

Thanks to Ryan's documentation hint. I find the correct direction.

First, I have to join my ESXi machine to Windows AD, which can be done via viclient.

Second, according to VMware vSphere's doc, I have to create an AD group named ESX Admins (no nonsense, you have to use this group name) and make chjadmin a member of it.

Now, I can execute esxcli with an AD user identity:

esxcli --server=172.27.120.147 -u chjadmin -p 123456 system version get

I confirm that the above command does not rely on the prerequisite of vifp addserver 172.27.120.147 .... and it executes quickly (in two seconds).

So far, so good.

HOWEVER, another problem exists. The vifp commands executes so slowly.

vifp addserver 172.27.120.147 --authpolicy adauth --username 'velab.chj\chjadmin' # costs 10 seconds
vifptarget -s 172.27.120.147  # cost 30+ seconds

How come they cost so long?

What's worse, before I execute vifptarget -c to quit the default ESXi target context , each press of Enter on the command line costs 20+ seconds. What happened inside?

snap0401-vifptarget-slow-strange.png

I quickly realize there may be something cranky inside PS1. It turns out yes.

snap0403-vma-vifptarget-weird-PS1.png

The command

LD_PRELOAD=`__get_ld_preload_without_vmalibs` /opt/vmware/vma/bin/vitargetquery.sh

executes for so long, 20+ seconds. Can someone help explain this?

BTW: My customized PS1 is(verbatim from Bash command line):

PS1="\n[\[\033[32m\]$(tty) \d \t\[\033[31m\] jobs:\j\[\033[0m\] "'ERR:$?$(if [ $? != 0 ];then echo -e \a; fi)] \n'"[\u @\h \[\033[33m\w\033[0m\]]\n\[\033[1;37;44m\]#\[\033[0m\] "

[Update] vifp commands execution slow problem solved

Reading the Bash source of /opt/vmware/vma/bin/vifptarget and /opt/vmware/vma/bin/vitargetquery.sh, I found that they both execute a real binary fastVmaTargetCheck like this /opt/vmware/vma/sbin/fastVmaTargetCheck 172.27.120.147 where most of the time is consumed.

Since I don't have the source code for fastVmaTargetCheck, I come up with the idea of packet sniffing the vMA machine, and finally reveal the cause. fastVmaTargetCheck 172.27.120.147 unconditionally issues a reverse DNS lookup for 172.27.120.147, with a roughly 12 second timeout, and my intranet DNS server did not have a reverse lookup zone so it forwarded the query to Internet DNS servers which also timeed out. The vifp commands do many times of such query so I saw the slow execution. The solution is, adding reverse lookup zone 120.27.172.in-addr.arpa to my DNS server so to give vMA an instant answer(no matter positive or negative) and the execution lag disappears.

share|improve this answer
    
You may want to create a new question for your new problem. –  Ryan Bolger Mar 18 at 17:12
    
Also, the ESX Admins group in AD isn't a requirement. It's just a default configuration item in ESXi. You can change the group name or remove it entirely if you wish. –  Ryan Bolger Mar 18 at 17:13
    
If I don't create ESX Admins group on AD, how can I assign administrative privileges to my AD user, so that they can execute esxcli commands against the ESXi box? VMware does not seem to give you the freedom of customizing ESX Admins group name. –  Jimm Chen Mar 19 at 7:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.