Рубрика: Советы

Борьба с VMware vSphere ESX Agent Manager

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

  1. Перестал работать DRS по причине невозможности создать виртуальные машины vCLS.
  2. Перестало работать обновление хостов с ошибкой «Failed to login to vCenter as extension, Cannot complete login due to an incorrect user name or password».

Изучение БЗ VMware навело на две заметки:

  1. EAM is unable to deploy vCLS VMs when vpxd-extension certificate has incorrect extended key usage values (85742)
  2. «Failed to login to vCenter as extension, Cannot complete login due to an incorrect user name or password», ESX Agent Manager (com.vmware.vim.eam) solution user fails to log in after replacing the vCenter Server certificates in vCenter Server 6.x/7.x (2112577)

Что-то подсказывало, что корень у причины один!

Подали советуемые команды, которые починили сертификат расширения:

Отвал FC HBA Emulex 8/16-Gb/s после обновления VMware ESXi 7.0 update 3

После обновления до актуальной буквы VMware ESXi 7.0 update 3  у нас неожиданно отвались 8-гигабитные FC HBA на базе Emulex LPe12000.

При разборе полётов было выяснено, что в Emulex Drivers for ESXi 7.0 с релиза 14.0.326.12 прекращена поддержка адаптеров LPe12000-series, LPe15000-series и LPe16000-series.

Соответственно, последними версиями с поддержкой данных адаптеров являются lpfc 14.0.169.25-5vmw и lpfc 12.8.614.16.

После понижения драйверов адаптеры появились.

Всегда говори да!

«Обычно люди обращаются за советом, — говорил Атос, — только для того, чтобы не следовать ему, а если кто-нибудь и следует совету, то только для того, чтобы было кого упрекнуть впоследствии.»

Пришло мне в голову дать вам бесплатный совет: соглашайтесь на практически любую движуху. Приведу пару примеров из своего опыта:

  1. 2009-й год, я работаю обычным системным администратором на заводе. Windows, Exchange и немножко ДрВеба с Симантеком :).
    Тут мне предлагают стать ответственным за администрирование коммутаторов, маршрутизаторов и брандмауэров Cisco. В качестве бонуса еще и немного учат!
    Я, конечно же, соглашаюсь. Коллега из соседнего отдела сомневается и отказывается — зачем ему дополнительный головняк?
  2. 2011 год, в другом месте мне предлагают взяться за администрирование системы MS Lync Server 2010. Тоже учат, ага…
    Там же ближе к 2017 — внедрить систему резервного копирования NetBackup.

Результатом первой возможности стало более глубокое понимание работы сети и сертификат CCNA (хотя, поработав в интернет-провайдере, я осознал — насколько же это были базовые знания). Пару раз помогало тыкать носом сетевиков в их косяки.
Результатом второй и третьей — приличные знания по обеим системам в качестве T-shape специалиста. В результате, в 2020м меня брали на центрального администратора Commvault с хорошим окладом без практического опыта по нему 😉

Я не могу рассказать о текущем стеке, но он не имеет ничего общего с привычным мне VMware/Microsoft. Когда-нибудь я расскажу и эту историю…

Добавление FC-коммутаторов с FabricOS 9.x в Brocade Network Advisor

Disclaimer:  все дальнейшие рассуждения и действия не соответствуют политике технической поддержки Broadcom. Любое использование оборудования вне списков совместимости Broadcom может быть использовано только на свой страх и риск. В статье рассматриваются коммутаторы на основе G620 первого и второго поколения. BNA ничего не знает про новую функциональность FabricOS 9.x и не сможет с ней правильно взаимодействовать.

Для управления FC-фабриками мы используем Brocade Network Advisor, который прекратил свой жизненный путь и заменен на SANNav.

К сожалению, SANNav поставляется по подписки и у нас есть проблемы с её приобретением.

Первой проблемой для нас стало то, что последняя версия BNA 14.4.5 перестала интегрироваться с VMware vCenter 7.0. Пришлось интеграцию удалить.

Второй проблемой — отсутствие поддержки Fabric OS 9.x, которая стала базовой для новых и обновленных коммутаторов.

У нас коммутаторы G620 второго поколения отображались в схеме фабрик как имеющие неправильные имя-пароль для подключения. Изменение настроек в разделе snmp коммутаторов и сервера — задание уровня шифрования для пользователя мониторинга в BNA и коммутаторе, включения информера не помогали.

Просмотр текущих настроек snmp:

Изучение настроек BNA выявило, что для сканирования оборудования фабрик используется аккаунт domain\access_bna, то есть коммутаторы должны позволять вход под доменными учётными записями.

Настроили и для новых коммутаторов RADIUS- авторизацию:

После этого коммутатор стал доступен для мониторинга и отобразился в схеме фабрики.

А вот коммутатор в другой фабрике по-прежнему остался недоступным. В консоли BNA выводилась ошибка с фразой:

Начали выяснять отличия первого коммутатора от второго.
Вспомнили, что на первом ломала и пересоздавали сертификат для подключения по https, а второй избежал этой участи, так как  проблема была в браузере — подключаться необходимо из Windows 10 с установленной кодовой страницей профиля пользователя EN-US.

Просмотр сертификатов для https выдается командой:

Разница видна сразу:

Команда генерации сертификата, по найденному лайфхаку, была:

Примечание: не все советы в интернете оказываются полезными. Помните это, читая и данную статью!

Создали новый сертификат с другим алгоритмом, соответствующий второму коммутатору:

После перегенерации сертификата, BNA увидел коммутатор и в этой фабрике.

Veeam Backup&Replication и восстановление дедуплицированных дисков

При попытке восстановить файлы на дедуплицированных томах из виртуальной машины с помощью Veeam BR FLR процесс восстановления зависает.
При запуске восстановления появляется сообщение:

Это связано с отсутствием компонентов дедупликатора. Добавляем их вручную на сервер Veeam BR:

Повторно восстанавливаем файлы.

Сохранение активации лицензий ПО при замене оборудования в VMware vSphere 6.7+

Disclaimer:  все дальнейшие рассуждения и действия могут нарушать лицензионные соглашения правообладателей. Любое использование нижеследующих рекомендаций должно подтверждаться наличием у вас прав на лицензии. Все действия выполняются на свой страх и риск.

Время от времени серверы устаревают, а на замену им приходит новое оборудование с новыми процессорами.

Для абстрагирования vCPU от физического процессора от оборудования в VMware vSphere много лет развивается технология маскирования флагов процессора:

Обычно, технологии защиты ключей лицензий, разрешенные к использованию в виртуальных средах, используют привязки к:

  1. BIOS/UEFI;
  2. операционной системе;
  3. имени сервера/ПК;
  4. идентификаторам либо серийным номерам жестких дисков;
  5. MAC-адресам сетевых карт;
  6. CPUID, описывающему имя, семейство и модель процессора, доступные SIMD-инструкции.

В соответствии с этим мы можем использовать фиксацию части параметров.

Для фиксации UUID BIOS можно отредактировать VMX-файл:

Также возможны и более хардкорные модификации BIOS/UEFI. Получить данные можно получить через команду wmic bios.

Для привязки по MAC-адресу мы фиксируем адрес с физического сервера лицензий, либо генерируем его сами до получения лицензий. Адрес можно указать в настройках сетевого адаптера либо прописать в VMX-файле:

Parameter Value
ethernetX.addressType static
ethernetX.address MAC_address_of_the_virtual_NIC

В большинстве случаев получается привязать MAC к выключенному адаптеру либо подключенному в пустую виртуальную сеть.

Для сохранения CPUID необходимо собрать следующую информацию:

  • EVC/поколение ЦПУ виртуальной машины в vSphere.
  • Поколение(CPU-Z), название, id и модель процессора в операционной системе (wmic cpu get caption, name, processorid; в Linux /proc/cpuinfo).

После этого в конфигурации выключенной виртуальной машины (vHW>=14) устанавливается нужный уровень Per-VM EVC, при необходимости прописываются в VMX-файл прочие параметры маскинга CPUID (*в примере левые параметры):

Примечание.  При изменении vHW и/или обновлении ESXi версии BIOS/UEFI могут меняться. Изменение BIOS/UEFI, CPUID происходит по время выключения/включения (powercycle) виртуальной машины.

Всегда делайте копию виртуальной машины и VMX-файла перед правками!!!

Отключение Hyper-V с помощью BCDEDIT

Решил на домашнем компе поэкспериментировать с виртуальной машиной. Для этого включил компонент Hyper-V, компьютер ушёл в перезагрузку и больше не захотел загружаться.

После 2-3 сбросов я смог попасть в безопасный режим и удалить компонент в оснастке, но при следующей же перезагрузке Windows сказала, что доудалять не может и восстановила Hyper-V  — и система ушла в цикл.

На просторах Интернета нашёл команду, запрещающую старт Hyper-V (запустить в командной строке от имени администратора):

обратная (если понадобится):

Управляем неуправляемым VMware ESXi

Иногда бывает, что ESXi теряет управление — отваливается от vCenter.

Что с этим делать расписано на русском в статье «Хост VMware ESXi в состоянии Not Responding на сервере vCenter — в чем может быть проблема?»

Опытные админы, обычно, идут в консоль и подают 2-3-4 команды:

либо полный фарш:

Недавно у нас случилась аналогичная ситуация — отвалилось несколько хранилищ (datastore) и ESXi решил прикурить: vCenter отпал, хостовый веб-клиент отпал, вышеупомянутые команды якобы отрабатывали с нулевым результатом. Хорошо хоть виртуальные машины продолжали работать.

В итоге решили перезагрузить хост. Вот только для этого нужно было погасить виртуальные машины — часть выключили штатно изнутри, но некоторым нужно подать команду shutdown снаружи.

Типовые команды для выключения ВМок описаны  в статье «Powering off an unresponsive virtual machine on an ESXi host (1004340)»

Но у нас-то случился клинический случай  и ESXi не отрабатывал команд esxcli. Соответственно, пришлось искать более низкоуровневое решение — localcli.

localcli — это набор команд для работы технической поддержки VMware. Команды localcli эквивалентны командам ESXCLI, но обходят hostd. Команды localcli предназначены только для ситуаций, когда hostd недоступен и не может быть перезапущен.

Предупреждение: Использование LOCALCLI официально не поддерживается. Все действия выполняются на свой страх и риск.
Однако команда очень интересна тем, что при использовании специального внутреннего каталога плагинов появляются некоторые недокументированные пространства имен. Вы можете просмотреть эти пространства имен и открыть для себя некоторые интересные функциональные возможности. Просто войдите в ESXi и используйте команду

результат вывода:

Осталось написать скрипт массового выключения ВМок. Пока думал как написать решил поискать готовые решения и  поисковик выдал примечательную статью о шифровальщиках для VMware vSphere c готовым скриптом New Linux-Based Ransomware Cheerscrypt Targeting ESXi Devices Linked to Leaked Babuk Source Code. В статье косяки с кавычками и апострофами, так что держите верный код:

Ну, а для нашей задачи такой жести не надо, но нужны другая команда и обычное выключение:

Если же перед вами стоят другие задачи, но esxcli не работает, то попробуйте использовать доступные пространства имен для localcli.

Раздувание таблиц vPostgres в VMware VCSA

В СУБД PostgreSQL присутствует эффект раздувания таблиц aka table bloat. Он выражается в падении производительности при интенсивном обновлении данных, например,  при частых UPDATE, INSERT, DELETE. Данное поведение характерно и для СУБД vPostgres в VMware VCSA.

Для диагностики раздувания необходимо выполнить следующие действия:

  1.  Скачать скрипт 51981_check_bloat.sql из БЗ VCSA database storage /storage/db is full or nearly full (51981) (скрипт является копией официального Show database bloat).
  2. Подключиться к БД: /opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB.
  3. Скопировать и вставить содержимое файла и нажать Enter.
  4. Проанализировать отчёт. Если значение колонок tbloat либо ibloat column больше 25, то запланировать обслуживание БД.

Читать далее «Раздувание таблиц vPostgres в VMware VCSA»

Утилита самообслуживания VMware Lookup Service Doctor

Следующая утилита самообслуживания от VMware — Lookup Service Doctor aka lsdoctor.

В результатах диагностики с помощью Утилита самообслуживания VMware vSphere Diagnostic Tool вы  можете получить ссылку на lsdoctor:

Lookup Service Doctor (lsdoctor) — это скрипт, используемый для решения проблем с данными, хранящимися в базе данных PSC, а также с данными, локальными для vCenter (независимо от того, является ли PSC внешним или встроенным). Данный инструмент можно использовать для обнаружения и устранения проблем, которые могут привести к сбоям при изменении топологии (converge, repoint и т.д.), обновлении или сбоям, возникшим в результате технического обслуживания (например, неправильное применение новых SSL-сертификатов).

Прежде чем использовать lsdoctor для внесения каких-либо изменений, убедитесь, что вы сделали надлежащие снимки вашего домена SSO. Это означает, что вы должны одновременно выключить все VC или PSC, которые находятся в домене SSO, затем сделать снимки и снова включить их. Если вам нужно вернуться к одному из этих снимков, выключите все узлы и верните все узлы к снимку. Невыполнение этих шагов приведет к проблемам репликации между базами данных PSC.

Утилита предназначена для использования с vCenter 6.5 и новее. Скачивается из KB Using the ‘lsdoctor’ Tool (80469), тут же размещены подробные инструкции по использованию. Затем распаковывается и заливается на vCenter, запускается справка из папки lsdoctor-master:

Выведутся ключи программы:

Предназначение ключей программы: Читать далее «Утилита самообслуживания VMware Lookup Service Doctor»