Vmware esxi

В 2021 году уже известно, что Zabbix предлагает в качестве средства комплексного мониторинга инфраструктуры VMware набор шаблонов, использующих функционал Low Level Discovery (LLD) и элементы типа Host prototype, в которых создаются стандартные списочные сенсоры из известных vCenter'у. Однако отнюдь не все вендоры оборудования корректно публикуют сенсоры или счетчики своих устройств в доступном для vCenter виде. Здесь рассматривается в подробностях настройка мониторинга для всё ещё поддерживаемых, но не отображающих состояние в vCenter контроллерах дисковой подсистемы Adaptec SmartRAID. Способ получения данных может быть пригоден и для других вендоров.

Итак, задача. Есть несколько хостов ESXi, купленных порознь у разных вендоров, с разным наполнением, и есть охота заиметь под них одинаковый мониторинг. Часть хостов выдает информацию в vSphere web client, но неструктурировано - никаких красивых группировок сенсоров по слову "storage" и близко нет, другая часть вообще ничего не выдает. При этом необходимое ПО установлено! Пример:

[root@esxi-8:~] esxcli software vib list
<snip>
scsi-aacraid 6.0.6.2.1.59002-1OEM.600.0.0.2494585 Adaptec_Inc VMwareCertified 2020-08-14
arc-cim-provider 3.07-23850 Adaptec VMwareAccepted 2021-02-15
arcconf 3.07-23850 Adaptec VMwareAccepted 2021-02-15

Как видим, в списке есть и драйвер для контроллера (здесь Adaptec RAID 8805), и утилита управления arcconf, и "родной" провайдер данных для внешних служб (далее "CIM провайдер") arc-cim-provider, все последних версий. Версия VMware на хосте 6.7U3, и сенсоров состояния подсистемы хранения в ней нет. Однако, если есть провайдер, то как-то можно получить от него данные - этим и займемся.

Во-первых, как получать эти данные. В документации на VMware, помимо всего прочего, сказано, что есть сервис sfcb, который запускается при установке стороннего CIM-провайдера, и сервис openwsman, представляющий собой сервер WS-Management, к тому же, умеющий работать с более примитивными запросами CIM или WBEM. А для работы с данными протоколами есть вполне серьезный клиент pywbem, возвращающий данные в любом удобном виде. Для своей реализации мониторинга я взял более привычную мне среду программирования bash и wbemcli в качестве средства обращения к хосту ESXi.

Чтобы получить данные от хоста, необходимо на нем авторизоваться, но локального root, естественно, заббиксу никто давать не будет. Поэтому на каждом хосте, подлежащем отслеживанию, нужно создать пользователя с ограниченным доступом, но в то же время имеющего доступ к подсистеме CIM, которая в VMware ограничена дополнительно. m4ce, создавший свой вариант шаблона для ESXi-хоста, выложил инструкцию, как правильно создать пользователя для Zabbix на ESXi-хосте версий 6.х (для более ранних необходимы слегка другие команды):

/usr/lib/vmware/auth/bin/adduser -s /sbin/nologin -D -H zabbix -G rootecho "secure_zabbix_password" | /usr/lib/vmware/auth/bin/passwd --stdin zabbixvim-cmd vimsvc/auth/role_add CIM_ReadOnly Host.Cim.CimInteraction System.Anonymousvim-cmd vimsvc/auth/entity_permission_add vim.Folder:ha-folder-root 'zabbix' false CIM_ReadOnly true

Инструкция слегка избыточна, так как, если когда-то мониторинг по CIM/WBEM/WS-Man уже настраивался, роль пользователя, подобная CIM_ReadOnly, может существовать, но на чистой системе подобных ролей не найдено.

Далее самое интересное. Дело в том, что сенсоры, которые собирает VMware vCenter, находятся в пространстве имен WBEM "по умолчанию", оно же "root/cimv2", а так как информации о дисках там нет, либо она в кривом виде, нужно найти правильное пространство имен, где эти данные есть, и правильные имена классов устройств, которые нужно отслеживать. Вторая часть несколько проще - беглым поиском находятся имена классов CIM_DiskDrive, CIM_StorageVolume, CIM_Controller, от которых можно отталкиваться в поисках фактических элементов. А с первой поможет вот этот документ от VMware (PDF), содержащий ссылки на ужасно обрезанную документацию по вендорским провайдерам. Но она есть, и вуаля - для Adaptec CIM Provider найдено пространство имен "root/pmc/arc/smi_15". Из того же документа можно узнать пространства имен и для других вендоров, пусть иногда и не напрямую - например, для Emulex пространство имен "root/emulex".

Теперь у нас есть вся необходимая информация, чтобы начать собирать какие-то данные с хоста. Но данные из wbemcli возвращаются в очень громоздком и нечитаемом виде, мало того, адресуются элементы в командной строке не очень легко, к тому же, в Zabbix нужно суметь передать структуру обнаруженных данных через тот же механизм LLD. Для этого я написал скрипт, который умеет две вещи - отдавать найденные инстансы некоего класса из определенного пространства имен в Zabbix, и отдавать необработанные данные wbemcli при запросе конкретного инстанса. Скрипт представляет собой обертку над вызовами wbemcli einи wbemcli gi, с форматированием данных в режиме обнаружения в формат, приемлемый для Zabbix'a. Шаблон для его использования находится там же, в нем настроены некоторые основные параметры отслеживаемых физических и логических дисков - для физических это состояние, температура (два варианта - один для сервера с HDD, второй для сервера с SSD, они заполняют разные параметры!), флаг состояния SMART (тоже два), счетчик оставшегося ресурса SSD и счетчики аппаратных ошибок, для логических - только состояние, и некоторые базовые триггеры на их основе. Дополнения и тесты на не-Adaptec системах приветствуются.

Напоследок: Если вы не сумели найти правильное пространство имен, в поисках поможет то, что "пространство имен" - это тоже класс, с именем __namespace, перечисление экземпляров которого можно начать с пространства "root".

Этой небольшой статьей-заметкой мы хотели бы завершить серию публикаций, посвященных истории виртуализации в Enterprise-сегменте рынка. Сегодня поговорим о VMware, компании, которая на сегодняшний день является фактическим законодателем в мире виртуализации. Давайте посмотрим, как выглядели одни из самых ранних продуктов VMware: GSX и ESX.

VMware была основана в 1998 году. Её первым коммерчески успешным продуктом считается VMware Workstation, выпущенный в 1999 году и предназначенный для работы на клиентском железе.

Для серверных рабочих нагрузок в следующие 2 года был с нуля разработан продукт VMware GSX Server. Его название это сокращение от более длинного рабочего имени Ground Storm X. Первая коммерческая версия 1.0 датируется 2001-м годом. Устанавливалась она поверх Windows Server или SUSE Linux, что характеризует ее как гипервизор 2-го типа.

Усовершенствованная версия GSX Server 2.0 увидела свет через год, летом 2002-го. Под своим оригинальным именем продукт просуществовал вплоть до декабря 2005-го, когда была выпущена последняя коммерческая версия 3.2.1.

Гипервизор завоевал популярность благодаря широкому списку поддерживаемого оборудования (от сервера до обыкновенного десктопа) и простоте установки и первичной настройки. Кроме того в GSX наличествовали встроенные NAT и DHCP-сервер, что существенно облегчало процесс настройки сети.

Затем GSX Server был переименован в VMware Server и стал распространяться совершенно бесплатно. В списке поддерживаемых гостевых систем появились и 64-битные ОС, а гипервизор получил возможность выделять машинам несколько vCPU. VMware Server появилась 12 июля 2006-го и официально поддерживалась вплоть до 2011-го.

Сладкий плод виртуализации понравился инженерами VMware. Гипервизоры 2-го типа это хорошо, но 1-й тип способен дать гораздо больше возможностей!

Параллельно с GSX Server шла разработка нового гипервизора типа 1. В отличие от предшественника, его уже можно было установить на голое серверное железо без ОС-посредника.

Продукт получил рабочее название VMware Scalable Server. В настоящее время он известен уже под именем ESXi. Ниже приводим скриншот, приблизительно датированный 1999-2000 годом.

Уже совсем скоро, к 2000-му, проект получил новое название: VMware Workgroup Server. А в марте 2001-го компания официально выпустила VMware ESX 1.0 Server. ESX это аббревиатура от Elastic Sky X. Забавно, но придумали его вне стен VMware. Сотрудники компании прекрасно разбирались в компьютерах, но ничего не смыслили в рекламе и маркетинге. Специально нанятое агентство предложила лаконичный вариант Elastic Sky. Инженеры взбунтовались: как это, новый коммерческий продукт, в названии которого нет ни малейшей технарской изюминки?!

И добавили в конце загадочный X. Почему? Вероятно, чтоб никто не догадался!. Да и звучит более круто. Забавно, как точно это имя попало в цель: вряд ли в далеком 2001-м кто-то придумывал его с оглядкой на облачные вычисления.

Впоследствии вокруг нового продукта сформировался целый отдел, самым известным сотрудником которого был Джон Аррасджид, один из авторов и ведущий архитектор vCloud Architecture Toolkit (vCAT).

VMware ESX Server стал первым на рынке гипервизором 1-го типа для Intel x86. В нем были впервые реализованы многие функции, ставшие едва ли не стандартом: живая миграция виртуальных машин, High Availability, автоматический балансировщик нагрузки, инструменты управление питанием и т.п.

В течение нескольких лет ESX и GSX были одновременно доступны широкой аудитории. GSX целился в более приземленную аудиторию: малый бизнес, небольшие государственные учреждения, в то время как ESX стал флагманским продуктом для Enterprise-сектора. Однако по-настоящему серьезно ESX начал использоваться лишь к 2006 году.

Среди прочего ESX имел сервисную консоль. Ее роль выполняла виртуальная машина на Linux, через которую можно было управлять хостом и другими ВМ. Для установки дополнительно программного обеспечения сторонних производителей (например, сервисов резервного копирования) предполагалось использовать программы-агенты.

Еще до того, как ESX начал серьезное распространение в бизнес-среде, началась разработка его преемника, уже без сервисной консоли. К сентябрю 2004-го внутри компании состоялась презентация первой полнофункциональной версии продукта под названием VMvisor (VMware Hypervisor). Через 3 года этот продукт появится на рынке под общеизвестным именем ESXi.

На выставке VMworld 2007 компания представила VMware ESXi версии 3.5. Прошлые версии программы существовали только в недрах VMware и не демонстрировались широкой публике.

ESXi занимает гораздо меньше места, чем ESX, и может быть установлен во флэш-память. Фактически, его уже можно рассматривать как часть сервера на это намекает буква i в его названии. Она означает Integrated, интегрированный.

Вплоть до выхода vSphere 4.1 VMware предлагала клиентам два варианта: VMware ESX с Linux-консолью и ESXi с меню настройки сервера. Поддержка ESX официально завершилась с выпуском vSphere 5.

Программное обеспечение, как и гипервизор, несколько раз меняло названия. Например, VMware VMcenter настолько редко и давно использовалось, что по нему даже толком ничего не гуглится. Разумно предположить, что это одно из внутренних наименований продукта. Оно фигурирует, например, на этом скриншоте:

Весь дальнейший путь VMware хорошо известен всякому пользователю или системному администратору, который хотя бы раз сталкивался с виртуализацией. Пул решений компании велик и разнообразен, а перспективные разработки, такие как Tanzu, не так давно начали появляться вне тестовых стендов.

Многие администраторы VMware ESXi сталкивались с такой проблемой, как фиолетовый экран смерти. Самое неприятное в этой проблеме, что у вас возникает недоверие к своей собственной инфраструктуре. В голове постоянно крутятся мысли о том, что такая же проблема может повториться и на другом сервере.

Что такое PSOD?

PSOD расшифровывается, как Purple Screen of Diagnostics, часто называемый Purple Screen of Death от более известного Blue Screen of Death, встречающегося в Microsoft Windows.

Это диагностический экран, отображаемый VMware ESXi, когда ядро обнаруживает фатальную ошибку, при которой оно либо не может безопасно восстановиться, либо не может продолжать работу.

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

Данный экран отображается в консоли сервера. Чтобы увидеть его, вам нужно будет либо находиться в центре обработки данных и подключить монитор, либо подключиться удаленно с помощью внеполосного управления сервером (iLO, iDRAC, IMM и т.д. в зависимости от вашего вендора).

Почему появляется PSOD?

PSOD- этосбой в ядре. Все мы знаем, что ESXi не основан на UNIX, но механика сбоя соответствует определению UNIX. Ядро ESXi (vmkernel) запускает эту меру безопасности в ответ на события или ошибки, которые невозможно исправить, это будет означать, что продолжение работы может создать высокий риск для служб и виртуальных машин. Проще говоря: когда хосты ESXi чувствуют, что они повреждены, они совершают харакири и, истекая пурпурной кровью, пишут предсмертную записку с подробным описанием причин, по которым они это сделали!

Наиболее частые причины PSOD:

1. Аппаратные сбои, в основном связанные с RAM или CPU. Обычно они выдают ошибку MCE или NMI.

MCE исключение проверки компьютера, которое представляет собой механизм в ЦП для обнаружения и сообщения о проблемах с оборудованием. В кодах, отображаемых на фиолетовом экране, есть важные детали для определения основной причины проблемы.

NMI немаскируемое прерывание, то есть аппаратное прерывание, которое не может игнорироваться процессором. Поскольку NMI является очень важным сообщением об отказе HW, ответ по умолчанию, начиная с ESXi 5.0 и более поздних версий, должен запускать PSOD. Более ранние версии просто регистрировали ошибку и продолжали. Как и в случае с MCE, фиолетовый экран, вызванный NMI, предоставляетважные коды, которые имеют решающее значение для устранения неполадок.

2. Программные ошибки

неверное взаимодействие между компонентами ESXi SW (см.KB2105711)

условия гонки (см.KB2136430)

из ресурсов: память, динамическая область памяти, буфер (см.KB2034111,KB2150280)

бесконечный цикл + переполнение стека (см.KB2105522)

неверные или неподдерживаемые параметры конфигурации (см.KB2012125,KB2127997)

3. Некорректно функционирующие драйвера;ошибки в драйверах, которые пытаются получить доступ к некорректному индексу или несуществующему методу (см.KB2146526,KB2148123)

Какое влияние оказывает PSOD?

Когда возникает сбой, хост выходит из строя изавершает работу всех служб, работающих на нем, вместе со всеми размещенными виртуальными машинами. Виртуальные машины отключаются резко ине завершаютсвою работу корректно. Если хост является частью кластера и вы настроили HA, эти виртуальные машины будут запущены на других хостах в кластере. Помимо простоя и недоступности виртуальных машин во время их простоя, грязное завершение может повлиять на некоторые критически важные приложения, такие как серверы баз данных, очереди сообщений или задания резервного копирования.

Кроме того, все другие службы, предоставляемые хостом, будут прекращены, поэтому, если ваш хост является частью кластера VSAN, PSOD также повлияет на vSAN.

Что делать?

1. Проанализируйте сообщение на фиолетовом экране.

Одна из самых важных вещей, которые нужно сделать при появлении фиолетового экрана - это сделать снимок экрана. Если вы подключаетесь к консоли удаленно (IMM, iLO, iDRAC, ), будет легко сделать снимок экрана, если нет такой возможности, хотя сфотографируйте экран на телефон. На этом экране много полезной информации о причине сбоя.

2. Обратитесь в службу поддержки VMware.

Прежде чем приступить к дальнейшему исследованию и устранению неполадок, рекомендуется обратиться в службу поддержки VMware, если у вас есть контракт на поддержку. Параллельно с вашим расследованием они смогут помочь вам в проведении корневого анализа причин (RCA).

3. Перезагрузите затронутый хост ESXi.

Чтобы восстановить сервер, вам необходимо перезагрузить его. Я бы также посоветовал оставить его в режиме обслуживания, пока вы не выполните полный анализ RCA, пока не будет определена и исправлена ошибка. Если вы не можете позволить себе держать его в режиме обслуживания, по крайней мере, точно настройте свои правила DRS, чтобы на нем работали только второстепенные виртуальные машины, чтобы в случае возникновения другого PSOD влияние было минимальным.

4. Получите coredump

После загрузки сервера вы должны собрать дамп ядра -coredump. Coredump, также называемый vmkernel-zdump, представляет собой файл, содержащий журналы с более подробной информацией, чем та, что отображается на фиолетовом экране диагностики, и будет использоваться при дальнейшем устранении неполадок. Даже если причина сбоя может показаться очевидной из сообщения PSOD, которое вы проанализировали на шаге 1, рекомендуется подтвердить ее, просмотрев журналы из coredump.

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

а. Во временномразделе

b. В виде файла.dumpв одном из хранилищ данных хоста

c. В виде файла.dumpна vCenter через службу netdump

Coredump становится особенно важным, если конфигурация хоста должна автоматически сбрасываться после PSOD , и в этом случае вы не увидите сообщение на экране. Вы можете скопировать файл дампа с хоста ESXi с помощью SCP, а затем открыть его с помощью текстового редактора (например, Notepad ++). Он будет вмещать содержимое памяти на момент сбоя, и первые его части будут содержать сообщения, которые вы видели на фиолетовом экране. Служба поддержки VMware может запросить весь файл, но у вас лишь будет возможность извлечь только журнал vmkernel, который более нагляден:

5. Расшифруйте ошибку.

Устранение неполадок и анализ причин позволяют почувствовать себя Шерлоком Холмсом. Самый важный симптом, с которого вам следует начать, - это сообщение об ошибке, создаваемое фиолетовым экраном.К счастью, количество выдаваемых сообщений об ошибках ограничено:

Exception Type 0 #DE: Divide Error
Exception Type 1 #DB: Debug Exception
Exception Type 2 NMI: Non-Maskable Interrupt
Exception Type 3 #BP: Breakpoint Exception
Exception Type 4 #OF: Overflow (INTO instruction)
Exception Type 5 #BR: Bounds check (BOUND instruction)
Exception Type 6 #UD: Invalid Opcode
Exception Type 7 #NM: Coprocessor not available
Exception Type 8 #DF: Double Fault
Exception Type 10 #TS: Invalid TSS
Exception Type 11 #NP: Segment Not Present
Exception Type 12 #SS: Stack Segment Fault
Exception Type 13 #GP: General Protection Fault
Exception Type 14 #PF: Page Fault
Exception Type 16 #MF: Coprocessor error
Exception Type 17 #AC: Alignment Check
Exception Type 18 #MC: Machine Check Exception
Exception Type 19 #XF: SIMD Floating-Point Exception
Exception Type 20-31: Reserved
Exception Type 32-255: User-defined (clock scheduler)

Поскольку сбой в ядре обрабатывается процессором, для получения дополнительной информации об этих исключениях см. Руководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 1: Базовая архитектура иРуководство разработчика программного обеспечения для архитектур Intel 64 и IA-32, том 3A.

Наиболее распространенные случаи описаны в отдельных статьях базы знаний VMware. Поэтому используйте эту таблицу в качестве индекса для ошибок PSOD:

6. Проверьте журналы

Может случиться так, что причина не очень очевидна при просмотре фиолетового сообщения на экране или журнала дампа ядра, поэтому следующее место, где искать подсказки, - это журналы хоста, особенно во временном интервале, непосредственно предшествующем PSOD.Даже если вы чувствуете, что нашли причину, все же рекомендуется подтвердить ее, просмотрев журналы.

Если вы администрируете корпоративную среду, вероятно, у вас под рукой есть специализированное решение для управленияжурналами(например,VMware Log Insight или SolarWinds LEM), поэтому их будет легко просматривать, но если у вас нет управления журналами, вы можете легкоэкспортировать их.

Наиболее интересные файлы журналов для изучения: