Как назначить разрешения ESXi пользователю Windows AD для работы с VMware vMA?
Я следую инструкциям в Официальное руководство по vMA 5.1 (pdf), и меня сбивает с толку следующая операция (описанная на стр. 18 ~ стр. 19).
Я присоединил свою vMA к моему Windows AD velab.chj, перезагружаю vMA и выполняю следующие действия:
Как видите, я не могу выполнить esxcli system version get с удостоверением пользователя Windows AD (chjadmin). Я думаю, что это разумно, потому что хост ESXi не назначил никаких разрешений пользователю AD chjadmin и даже не знает о его существовании.
Итак, мой вопрос: как настроить хост ESXi, чтобы разрешить chjadmin выполнение esxcli команда? Официальное руководство по vMA, похоже, не говорит об этом.
В руководстве по vMA предполагается, что вы уже предприняли шаги для присоединения хоста ESXi к Active Directory и предоставили разрешения, позволяющие запускать эти команды.
Соответствующую документацию можно найти Вот в документации по ESXi и vCenter Server 5.5. Конкретно в разделе vSphere Security - Защита хостов ESXi - Использование Active Directory для управления пользователями ESXi.
Благодаря подсказке Райана в документации. Я нахожу правильное направление.
Во-первых, мне нужно подключить мою машину ESXi к Windows AD, что можно сделать через Viclient.
Во-вторых, согласно документу VMware vSphere, мне нужно создать группу AD с именем Администраторы ESX (без чепухи, вы должны использовать это имя группы) и сделать chjadmin членом этой группы.
Теперь я могу выполнить esxcli с идентификатором пользователя AD:
esxcli --server=172.27.120.147 -u chjadmin -p 123456 system version get
Я подтверждаю, что указанная выше команда не полагается на предварительное условие vifp addserver 172.27.120.147 .... и он выполняет быстро (через две секунды).
Все идет нормально.
ОДНАКО существует другая проблема. Команды vifp выполняются очень медленно.
vifp addserver 172.27.120.147 --authpolicy adauth --username 'velab.chj\chjadmin' # costs 10 seconds
vifptarget -s 172.27.120.147 # cost 30+ seconds
Почему они так долго стоят?
Что еще хуже, прежде чем я выполню vifptarget -c выйти из целевой контекст ESXi по умолчанию , каждое нажатие Enter в командной строке стоит 20+ секунд. Что случилось внутри?
Я быстро понимаю, что внутри PS1 может быть что-то странное. Оказывается, да.
Команда
LD_PRELOAD=`__get_ld_preload_without_vmalibs` /opt/vmware/vma/bin/vitargetquery.sh
выполняется так долго, 20+ секунд. Может кто-нибудь помочь объяснить это?
Кстати: мой настроенный PS1 (дословно из командной строки Bash):
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\] "
[Обновление] медленное выполнение команд vifp решено
Чтение Bash-источника /opt/vmware/vma/bin/vifptarget и /opt/vmware/vma/bin/vitargetquery.sh, Я обнаружил, что они оба выполняют настоящий двоичный fastVmaTargetCheck как это /opt/vmware/vma/sbin/fastVmaTargetCheck 172.27.120.147 где тратится большая часть времени.
Поскольку у меня нет исходного кода для fastVmaTargetCheck, Мне пришла в голову идея обнюхивания пакетов на машине vMA и, наконец, раскрыть причину. fastVmaTargetCheck 172.27.120.147 Безусловно, выдает обратный поиск в DNS для 172.27.120.147 с таймаутом примерно в 12 секунд, а у моего DNS-сервера в интрасети не было зоны обратного просмотра, поэтому он перенаправлял запрос на DNS-серверы Интернета, которые также истекли. Команды vifp выполняют такой запрос много раз, поэтому я видел медленное выполнение. Решение - добавление зоны обратного просмотра 120.27.172.in-addr.arpa на мой DNS-сервер, чтобы дать vMA мгновенный ответ (неважно положительный или отрицательный), и задержка выполнения исчезнет.