Update VMware vCenter 6.0U3b to 6.5U1(c,d,e)

Дождавшись зелененькой галочки на пересечении 6.0U3 и 6.5U1(c,d,e), я решил выполнить обозначенное обновление в полном соответвии с матрицей обновлений от VMware

.... и на выходе получил:

"A problem has occurred. The source vCenter Server might have been Powered of durring this process..."

Огорчился, скачал 6.5U1d, повторил - результат аналогичный
Опять огорчился, скачал 6.5U1с, повторил - результат аналогичный

Решил посмотреть, что на эту тему пишут уважаемые люди. На vcdx133.com нашел "решение" аналогичной проблемы, которое заключается в следующем:

Rollback to vCSA 6.0

1. Verify the upgrade was a failure and you want to rollback to vCSA 6.0.

2. Power-off the vCSA 6.5 instance.

3. Power-on the vCSA 6.0 instance.

4. Verify the rollback was completely successful and all services that rely on vCSA 6.0 are correctly functioning.

5. Delete the vCSA 6.5 instance.

...and repeat

Repeat я уже делал - не помогло, действуем по следующей инструкции:

1. Громко с матами ругаемся на качество кода VMware

2. Игнорируем сообщение об ошибке

3. Перегружаем в ручном режиме "новый vCenter"

4. Получаем обновленный до 6.5U1(c,d,e) и корректно работающий vCenter (с успешно импортированными настройками, с/без статистикой по ивентам, тасками, статистикой производительности)

5. Громко с матами ругаемся на качество кода VMware

Platform Services Controller and vCenter Server services.

В последнее время очень частно сталкиваюсь с нежеланием использовать vCenter Server Appliance в качестве замены еще не умершему, но уже плохо пахнущему vCenter Server Windows Edition.  Доводы приводят разные: начинают от недостаточной масштабируемости (которая в 6.0u1 эквивалентна Windows Edition), продолжают за невозможность делать резервные копии vPostgres DB (KB2091961 c готовыми скриптами остается большой тайной VMware, доступ только по тайным приглашениям), вспоминают про ADAM, SSL3 и всякие другие штуки, недоступность которых в vCenter Server Appliance осталась давно позади.

Большая часть таких возражений парируется документацией к vCenter Server Appliance. Однако, встречаются и достаточно обоснованные возражения: "отсутсвие возможности управления отдельными сервисами в vCenter Server Appliance". Под управлением подразумевается классическое: если не работает перегрузите.

Естественно такая возможность есть. Для этого необходимо подключится по SSH и можно делать так:

1. Остановить все сервисы  >service-control --stop --all

2. Запустить все сервисы >service-control --start --all

3. Проверить кто жив, а кто не очень >service-control --status

4. Можно останавливать и запускать и отдельные сервисы  >service-control --stop/start <service name>


а вот и список этих самых <service name> с разделением по vCenter Server и Platform Services Controller и названиями ролей

Service	<service name>	vCenter Server	PSC
VMware AFD Service	vmafdd
VMware Certificate Service	vmcad
VMware Component Manager	vmware-cm
VMware Content Library Service	vmware-vdcs
VMware Directory Service	vmdird
VMware ESX Agent Manager	vmware-eam
VMware HTTP Reverse Proxy	vmware-rhttpproxy
VMware Identity Management Service	vmware-sts-idmd
VMware vCenter Inventory Service	vmware-invsvc
VMware License Service	vmware-cis-license
VMware Message Bus Configuration Service	vmware-mbcs
VMware Performance Charts	vmware-perfcharts
VMware Postgres	vmware-vpostgres
VMware Security Token Service	vmware-stsd
VMware Service Control Agent	vmware-sca
VMware Syslog Collector	vmware-syslog
VMware System and Hardware Health Manager	vmware-vws
VMware vAPI Endpoint	vmware-vapi-endpoint
VMware vCenter Configuration Service
VMware vCenter Workflow Manager	vmware-vpx-workflow
VMware VirtualCenter Server	vmware-vpxd
VMware vService Manager	vmware-vsm
VMware vSphere Auto Deploy Waiter	vmware-rbd-watchdog
VMware vSphere ESXi Dump Collector	vmware-netdumper
VMware vSphere Profile-Driven Storage	vmware-sps
VMware VSAN Health Service	vmware-vsan-health

nbbf: vShield Manager & Specify a vCenter user

Один известный производитель ПО для виртуализации продолжает радовать багами фичами в своих продуктах.
Ролевой доступ, казалось бы, куда уж проще, но нет.

Возникла необходимость предоставить доступ сетевому инженеру к vShield Manager.
Пошел на SSO, сделал учетку и добавил ее через интерфейс vShield Manager.

Красота. Высылаю login | password. А мне вот так в ответ:

Думаю, ладно промазал с паролем два раза. Меняю пароль еще раз, высылаю сетевику, а он мне - "ничего не изменилось". Сетевики люди специфические, особенные - проверил сам, результат - "ничего не изменилось"

В поисках решения вопроса с очередной фичей логики было мало, но был результат. 

Чтобы доступ заработал пришлось дать доступ Администратора на объект "виртуальная машина"

Красота... при полном отсутствии логики.

VMware Log Insight offline logs analysis

Бекапы делают трусы (с)

...а лог коллекторы настраивают неудачники, у которых все постоянно ломается. Настоящим инженерам, руководствующимся в своей практике лучшими рекомендациями вендоров, лог сервера не нужны.

Log Insight дело хоть и полезное, но не дешевое. Убедить кошелек купить его, на случай если вдруг что-то поломается, сложно. Вот и вспоминают о нем, когда уже сломалось и надо быстро проанализировать и починить вчера.

При всем этом, Log Insight предназначен для онлайн агрегирования логов из добавленных источников, но никак не для offline анализа не инспектируемых логов. Говоря по-простому: если вы предварительно добавили ESXi хосты, vCenter, то на Log Insight попадут только логи с момента добавления, и если после добавления что-то сломалось, то вся аналитическая мощь Log Insight к вашим услугам. Если не добавили, то, естественно, ковырять вам логи в поисках счастья  в текстовом редакторе. Попробуем эту несправедливость исправить.

На старте есть самая отвратительная ситуация: централизованное логирование на хостах настроено не было (даже в виде vSphere Syslog Collector). В наличие у нас есть стандартный набор логов, хранившийся в /scratch/log. А это куча лог файлом непонятного назначения. Разобраться с назначением каждого из логов можно здесь.

Для эффективного анализа всего это мусора на понадобится:
VMware Log Insight - 1 шт.
Datаgram SyslogAgent - 1 шт.
vm c Windows на борту - 1 шт.

1. Выгружаем логи из /scratch/log на vm c Windows.
2. Настраиваем Datаgram SyslogAgent:

Datаgram SyslogAgent имеет одну особенность. Если мы сразу настроим его на уже заполненные файлы с логами, он ничего не отправит на Log Insight, поэтому в начальных настройках указываем пустые файлы с необходимыми нам именами.

Создаем новое Application, выбираем тип лога Static, указываем путь к пустому файлу.

Если получаем ошибку, значит все идет хорошо:

Добавляем парсинг даты и времени и для удобства идентификации имя процесса:

3. Рестартуем лог агента. Ждем пока агент обработает пустой файл.

4. Копипастим в пустой файл содержимое реального лога, анализ которого хотим провести.

5. Идем на Log Insight и видим дивное диво: Log Insight скушал наши 21388 offline событий:

Теперь в их можно эффективно искать, фильтровать и анализировать. О создании фильтров я писал здесь на примере анализа курсов валют НБРБ.

Однако, как оказалось, Log Insight и сам молодец. В горе мусора, которую мы в него загрузили, он смог самостоятельно найти errors, warnings специфические для ESXi. Эти находки он нам и показал на вкладке VMware - vSphere General- Problems:

Менюшечка эта совершенно интерактивная, а значит, выбрав для необходимого типа ошибок пункт Interactive Analytics:

мы получим всю информацию по всем ошибкам данного типа:

 P.S> желтенький треугольник с восклицательным знаком, присутствующий на многих картинка, обозначает, что одна или несколько нод кластера  Log Insight в данный момент недоступна. Но об этом потом ;)

VMware vCenter Log Insight делегирование прав

Что всегда компания VMware умела делать "хорошо" ? именно то, что написано в теме.

VMware vCenter Log Insight не стал исключением, благо хотя бы в 1.5 была добавлена интеграция с ActiveDirectory. Но на этом с настройками для удобного управления правами и доступом было покончено. В версии 2.0 ничего не изменилось.
Мы имеем целых 2 различных типа доступа: Normal и admin

Методом исключений предполагаем, что те, кто попадает под гордое название "Admin" совсем "ненормал". Группы отличаются лишь отсутствием вкладки Administration для группы Normal User. Т.е., как и ожидалось, делегирования прав нет. Можно, конечно, настраивать вид с помощью "Dashboards", однако это никак не спасает от самой возможности смотреть все. Наличие большого числа Content Packs для различных устройств и сервисов усугубляет печальность ситуации.
Интеграция с AD проходит достаточно просто и прозрачно (необходимо и достаточно учетной записи с правами только на чтение)
До интеграции с AD:

...после:

печали добавляет как отсутствие поиска по AD, так и отсутствие проверки наличия группы\пользователя в AD.

Достаточно странное исполнение с учетом позиционирования продукта. =(

VMware vCenter Log Insight Agent

Совсем недавно VMware выкатила в публичный доступ v.2.0 Log Insight. Оно стало быстрее, толще, умнее. О всех новых плюшечках и рюшечках можно почитать здесь. Вскоре последовал давно ожидаемый Windows Content Pack, а вместе с ним и VMware vCenter Log Insight Agent. Появилась надежда, что больше колдовать с Datagram SyslogAgent не придется.
Некое смятение в ощущение полной и нераздельной радости внесло емкое сообщение при инсталляции агента:

Разумная политика VMware нелюбви с некрофилам идет в разрез с удовлетворение хотелок пользователей. К сожалению, даже port, созданный средствами ThinApp не заведется на w2k3 и хр.

Скачать Windows Content Pack можно здесь. Установка достаточно прозрачна и происходит через меню Log Insight>Content Packs>Import Content Pack

После импорта вы получите доступ к всяческой служебной информации с описанием ошибок, уведомлений и т.п.

Дальше необходимо установить VMware-vCenter-Log-Insight-Agent-2.0.3-1879692 на сервера с Windows, указав при этом адрес Log Insight server.

Если все прошло хорошо (для дружбы агента и сервера используется порт за номером 9000), то вскоре вы увидите:

а потом и вот такую красоту

и всякие разные другие красивости и полезности.

Наибольший интерес представляет поле "Agent Configuratiom" в меню Agents. Естественно, за нас подумали и про автоматизацию настроек клиентов. Только вот нигде не написали про синтаксис этого Agent Configuratiom. Но тут все просто, примерно так:

[server]

proto=cfapi

hostname=192.168.3.244

port=9000

; Force reconnect agent every 30 minutes.

reconnect=30

[storage]

max_disk_buffer=200

[logging]

; The level of debug messages to enable: 0..2

debug_level=0

[winlog|Application]

channel=Application

[winlog|Security]

channel=Security

[winlog|System]

channel=System

и т.д. в зависимости от ваших хотелок.

ну и напоследок: 

 логи агента хранятся c:\ProgramData\VMware\Log Insight Agent\log\