ESXi 7 и зависший vmsyslog

Столкнулся с ситуацией, при которой ESXi 7 Update 3g (build 20328353) перестал отправлять логи на удаленный Syslog сервер, а при дальнейшем разбирательстве выяснилось, что локально логи он так же перестал писать и в /scratch/log журналы не обновляются. Место на диске есть.

В ходе диагностики были зафиксированы ошибки в журнале /var/log/.vmsyslogd.err следующего характера:

vmsyslog.main            : CRITICAL] Dropping messages due to log stress (qsize = 25000)

Адекватных KB по версии 7 на данную тематику я не нашел, была только KB по версии 6.5/6.7 с упоминанием данной ошибки, где было написано, что «проблема устранена».

Команда esxcli system syslog config get корректно выдает статус настроек, а esxcli system syslog reload к каким-то положительным результатам не приводит, логи локально писаться не начинают и, тем более, не отправляются на удаленный сервер.

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

vmsyslog.main            : ERROR   ] reloading (3200395)

Что аналогично результату работы esxcli system syslog reload.

Остановить службу и запустить заново из интерфейса ESXi не удается, поскольку:

This service with 'vmsyslogd' is marked as 'required' and cannot be stopped.

Остается применить грубую силу и остановить его принудительно напрямую с хоста:

ps -cC | grep vmsyslog
3418096  3418096  vmsyslogd             /bin/python /usr/lib/vmware/vmsyslog/bin/vmsyslogd.pyc 1

Определяем PID vmsyslog, в данном случае 3418096 и убиваем его:

kill -9 3418096

В логе vmsyslog будет видно, что процесс был убит, а затем автоматически перезапущен:

vmsyslog.main            : ERROR   ] Watchdog 3418095 fired (child 3418096 died with status 9)!
vmsyslog.main            : ERROR   ] Watchdog 3418095 exiting
vmsyslog                 : CRITICAL] vmsyslogd daemon starting (3418940)

После перезапуска логи вновь начинают писаться локально и отправляться на удаленный сервер.

Немного новостей минувшего месяца

За прошедший месяц было несколько интересных мне новостей, которыми хотел бы поделиться и здесь.

Открыта регистрация на VeeamON 2022

В этом году флагманское мероприятие компании Veeam под названием VeeamON пройдет с 16 по 19 мая в гибридном формате, что уже стало привычным за последние пару лет. Желающие посетить лично могут сделать это в Лас-Вегасе, для остальных же доступен виртуальный формат.

Зарегистрироваться можно по ссылке.

Релиз Tanzu Community Edition 0.10

Совсем недавно вышла новая версия TCE 0.10. В данном релизе появился новый тип кластеров под названием Unmanaged, который в будущих версиях должен полностью заменить Standalone кластера (уже deprecated). Unmanaged кластера развертываются быстрее и при этом потребляют меньше ресурсов.

Помимо этого, релиз включает еще несколько новшеств и улучшений о которых можно почитать на официальной странице.

Напомню, что про установку TCE в кластер vSphere я писал здесь.

Релиз Nutanix AOS 6.1 (STS) и Prism Central pc.2022.1

Долгожданный релиз AOS 6.1 с объемным количеством изменений. Почитать можно здесь и более подробно в release notes. Отмечу несколько интересных мне нововведений:

  • Improved Single vDisk Performance;
  • Whole Node Maintenance Mode;
  • VM Centric Storage Policy.

Одновременно с AOS вышла новая версия системы централизованного управления кластерами Nutanix под названием Prism Central. Несколько подмеченных мной нововведений:

  • Category-based Host affinity policy;
  • AHV VM templates;
  • Storage Container Management.

Подробнее в release notes.

В заключении хотел бы поделиться одной недавно обнаруженной KB по базовой диагностике проблем в кластерах Nutanix.

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

Ошибки сайзинга и неочевидные сбои задач Veeam SureBackup

Есть у меня одна совсем маленькая инсталляция – сервер Veeam Backup and Replication и отдельный Linux прокси с репозиторием. Бэкапируется не многим больше двадцати машин и, как можно догадаться из заголовка, резервные копии проверяются на работоспособность с помощью SureBackup.

Основой для написания поста поступило периодическое возникновение ошибок при выполнении задач SureBackup. Практически в каждый запуск задачи одна или несколько машин не проверялись, а в задаче фигурировала не очень детальная ошибка: “Registering. Error: One or more errors occurred”.

Под катом немного процесса диагностики и решение.

Continue reading “Ошибки сайзинга и неочевидные сбои задач Veeam SureBackup”

Проблема при обновлении Veeam Enterprise Manager до версии 11a

Столкнулся с небольшой проблемой при обновлении Veeam EM до версии 11a. Инсталлятор отказывался останавливать службу VeeamRESTSvc и тем самым прерывал процедуру обновления:

[ERROR] Failed to stop service ‘VeeamRESTSvc'. 

В моем случае обновление выполнялось с версии 11 P20210525 под управлением Windows Server 2016 с последними патчами.

Решение под катом.

Continue reading “Проблема при обновлении Veeam Enterprise Manager до версии 11a”

QuickFix. После обновления Veeam Backup & Replication до версии 11, не обновляется AHV прокси до версии 2.1

Если после обновления VBR до версии 11, прокси сервера для AHV находятся в разделе Out Of Date, а при попытке обновления появляется ошибка следующего характера:

Failed to upgrade host components. Error: ‘Failed to upgrade Proxy – AHV Proxy upgrade failed. Error: Updates are not found.’

Стоило читать документацию перед обновлением 🙂 . Процедура обновления под катом.

Continue reading “QuickFix. После обновления Veeam Backup & Replication до версии 11, не обновляется AHV прокси до версии 2.1”

Я собрал все грабли, но установил Veeam Agent на Oracle Linux 6.10

Под катом особенности установки Veeam Agent на сервер Oracle Linux 6.10. Все встреченные в процессе инсталляции ошибки и пути их исправления.

Continue reading “Я собрал все грабли, но установил Veeam Agent на Oracle Linux 6.10”

Nutanix Karbon – Failed to pull image. Service Unavailable при обращении к приватному реестру

На днях посчастливилось протестировать Nutanix Karbon, который позволяет без каких-либо трудозатрат развернуть на площадке Nutanix готовый к использованию кластер Kubernetes.

Процесс развертывания крайне прост и через ~20-30 минут в моем распоряжении был готовый к использованию кластер.

Естественно, в первую очередь захотелось развернуть простейший «Hello World» из местного реестра на базе Harbor, и проверить работоспособность, но первый деплой был, как говорится, комом.

Continue reading “Nutanix Karbon – Failed to pull image. Service Unavailable при обращении к приватному реестру”

Вышел из строя диск на ноде Nutanix? – меняем

Время от времени приходится прибегать к процедуре замены дисков на нодах Nutanix серии NX, и хоть это и крайне простая операция, на некоторые моменты можно обратить внимание.

Continue reading “Вышел из строя диск на ноде Nutanix? – меняем”

Dell OpenManage Enterprise, обновление Firmware и Mount of remote share failed

Недавно столкнулся с проблемой обновления прошивок на серверах Dell R640, оборудованных iDRAC 9 (4.10.10.10) через сервер управления Dell OpenManage Enterprise.

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

История одной проблемы и ее решение ниже.

Continue reading “Dell OpenManage Enterprise, обновление Firmware и Mount of remote share failed”

Принудительная очистка очереди задач в Dell iDRAC

Иногда, в интерфейсе управления Dell iDRAC зависают ранее запущенные задачи, которые препятствуют последующему запуску различных процедур на сервере, например, обновлению Fimrware.

Задачи висят в очереди (jobqueue) на различном проценте выполнения от 1 до 99% и не двигаются дальше. Подобное можно встретить при первоначальной настройке сервера из ранее подготовленного шаблона. В моем случае процесс «встал» на нескольких серверах при конфигурации raid-контроллера.

Если удалить задачу через web интерфейс не получается, перезапуск iDRAC так же не помогает и задачи продолжают находиться в очереди, можно попробовать воспользоваться командным интерфейсом racadm. Для этого необходимо подключиться к iDRAC по SSH.

Получить текущую очередь задач:
jobqueue view

В выводе команды будет необходимый нам ID, например: JID_876343082193

Попытаться удалить задачу:
jobqueue delete -i JID_876343082193

Если задача продолжает находиться в зависшем состоянии, можно принудительно попытаться прервать все задачи в очереди (нужно быть осторожным и не прервать что-то действительно нужное и работающее, те же обновления firmware):
jobqueue delete -i JID_CLEARALL_FORCE

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

Translate »