Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products
Sign In Create an Account Premier Sign In Partner Program Sign In
Contact Us

Your Dell.com Carts

Dell EMC VxRail. На хосте ESXi в vCenter отображается сообщение «not responding» или «disconnected» (исправляется заказчиком)

Summary: В этой статье описано, что проверять или делать с хостами, которые не управляются vCenter, хотя должны. В vCenter эти хосты отображаются в навигаторе с пометками (disconnected) или (not responding) рядом с именем хоста. Шаги, описанные в этой статье, также могут относиться к другим проблемам, связанным с быстродействием хоста, даже если хост не отображается как отключенный в vCenter. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

Хост ранее отображался в кластере в vCenter, но теперь помечен как отключенный или не отвечающий. Управление и мониторинг хоста больше не доступны в веб-клиенте vCenter. Все виртуальные машины, запущенные на этом хосте, либо перемещены на доступные хосты (HA), либо также отображаются как недоступные или отключенные.

Хост отображается с пометкой «disconnected» или «not responding» в веб-клиенте vCenter. Хост может по-прежнему отображаться как работающий, а виртуальные машины (ВМ) могут по-прежнему работать на нем. Однако хостом нельзя управлять из vCenter и он может не отвечать надлежащим образом на другие действия. Виртуальные машины, запущенные на хосте, не могут быть перенесены на другие хосты в кластере с помощью vMotion.

Cause

Эта ситуация возникает из-за того, что некоторые службы на хосте работают неправильно. Хотя существуют и другие причины (ссылки на дополнительные статьи см. в разделе «Примечания» ниже), отсутствие ответа от служб хоста может быть вызвано нехваткой доступных ресурсов хоста (обычно памяти). Хост ESXi выключает службы с интенсивным использованием ресурсов, такие как hostd вместо того, чтобы использовать выделенные ресурсы запущенных виртуальных машин, если это необходимо.

vCenter не может связаться с хостом из-за отсутствия этих служб и общей проблемы с запаздывающим хостом, у которого недостаточно доступных ресурсов для правильной работы. В результате сервер не отвечает на запросы vCenter, а управление или доступ к нему другими способами осуществляется медленно и с трудом. В этих случаях хранилище хоста по-прежнему полностью функционирует в хранилище данных vSAN, и его виртуальные машины обычно продолжают работать надлежащим образом в течение определенного времени. Перезагрузка хоста для восстановления памяти, которая не была должным образом освобождена хостом после использования (утечка памяти), часто является единственным способом восстановления управляемости хоста и повторного подключения его к vCenter.

Для получения дополнительной информации см. подробное описание в разделе «Примечания» ниже.

Resolution

Пользователи.
Если после выполнения приведенных ниже действий по устранению неполадок хост по-прежнему не подключается к vCenter должным образом, возникли вопросы или требуется помощь, обратитесь в службу технической поддержки Dell EMC или к авторизованному представителю службы поддержки, чтобы открыть сервисную заявку.

Начальные проверки. 
  1. Проверьте, работают ли виртуальные машины, которые точно размещены на хосте (они также могут отображаться как отключенные в vCenter).
  2. Попробуйте открыть веб-клиент vSphere на хосте: https://<IP-адрес управления хоста>, сеанс PuTTY или интерфейс пользователя Direct Connection («DCUI»: откройте консоль с помощью IDRAC на платформе Dell или BMC на Quanta). Невозможность подключения через PuTTY или vSphere к хосту, который находится в оперативном режиме (виртуальные машины работают), серьезное отставание в интерфейсе DCUI (или невозможность подключиться к нему), невозможность перезапуска служб или выполнения других команд с помощью командной строки указывает на недостаток доступных ресурсов хоста, как указано в подробном описании.
  3. В интерфейсе DCUI нажмите Alt + F11, чтобы проверить, отображается ли на мониторе хоста проблема hostd service stopped.
  4. Проверьте, можно ли отправить ping-запрос на хост. В противном случае он может не реагировать на экран диагностики («PSOD»), быть отключен (по возможности включите его) или иметь проблемы с сетью.
  5. Если на отключенном хосте не возникает проблем со службами (команда ping выполняется, веб-клиент подключается к хосту, DCUI выглядит хорошо и т. д.), можно попробовать нажать правой кнопкой мыши на хост в навигаторе vCenter в разделе «Hosts and Clusters» и выбрать параметры подключения хоста.
Если на хосте можно выполнять команды:
  1. Проверьте состояние «hostd» и «vpxa»: /etc/init.d/hostd status && /etc/init.d/vpxa status
  2. Попробуйте перезапустить «hostd» и «vpxa»: /etc/init.d/hostd restart && /etc/init.d/vpxa restart
  3. Если команды выполняются, но хост все еще не подключен, попробуйте перезапустить все службы управления:
  • Проверьте LACP (не перезапускайте все службы, если используется LACP, так как это может привести к другим проблемам): # localcli network vswitch dvs vmware lacp config get   
  • Если LACP отсутствует, перезапустите все службы управления на хосте с помощью одной из следующих команд:
    • vSphere 6.5 и более поздние версии: # services.sh restart and tail -f /var/log/jumpstart-stdout.log   
При перезапуске служб журнал не останавливается. По завершении нажмите Ctrl + C (примерно 5–10 минут).
  • В версиях vSphere до 6.5 (код VxRail ниже 4.5.x) выполните команду services.sh restart
  1. Убедитесь, что хост снова подключен после перезапуска всех служб.
Если шаги 3 и 4 помогли, хост должен автоматически повторно подключиться к vCenter. Возможно, потребуется обновить веб-страницу vCenter или вручную снова подключить хост. Необходимо перевести хост в режим обслуживания (обеспечение доступности), выполнив перенос всех запущенных виртуальных машин. Перед перезагрузкой выполните следующие действия, чтобы получить журналы, необходимые для дальнейшего анализа причины:
  1. Создайте дамп hostd из памяти, выполнив команду на хосте: vmkbacktrace -n hostd -c -w
  2. Проверьте наличие дампа с помощью команды ls -alrth /var/core/hostd*
Должны вернуться аналогичные данные: rwx------    1 root     root       32.8M Aug 15 05:10 /var/core/hostd-worker-zdump.001
  1. Подключитесь к хосту с помощью WinSCP, Filezilla и т. д. и скачайте файл.
  2. Перезагрузите хост, убедитесь, что он подключен к vCenter и выглядит нормально, включите виртуальные машины или перенесите виртуальные машины обратно на хост по необходимости. 
Если хост включен и отвечает на запрос ping, но к нему невозможно подключиться через SSH:
  • Попробуйте подключиться к хосту через IDRAC (BMC на Quanta) или KVM для выполнения команд через оболочку консоли. Если это работает, когда PuTTY (или другое подключение SSH) невозможно, попробуйте восстановить подключение, выполнив указанные выше действия.
  • Освободите память, выключив некоторые виртуальные машины хоста. Иногда этого достаточно, чтобы выполнить описанные выше действия без выключения всех виртуальных машин на хосте. При использовании этого метода функции High Availability (HA) могут автоматически перевести подключенные хосты в кластере обратно в оперативный режим.
  • Чтобы проверить состояние памяти, запустите «esxtop» на хосте, затем нажмите «m», чтобы проверить использование памяти.
  • Кроме того, сведения о ручной регистрации виртуальных машин на других хостах см. в статье VMware https://kb.vmware.com/s/article/1006160. Это позволяет минимизировать время, в течение которого виртуальные машины будут отключены до или во время перезагрузки.
Шаги по перезагрузке отключенного хоста для восстановления подключения к vCenter:
  1. Проверьте, какие виртуальные машины работают на хосте с помощью vCenter. Эта информация устарела, так как хост не подключен к vCenter, но обычно можно найти виртуальные машины на хосте, просмотрев те, которые также отображаются как отключенные на вкладке «Related Objects > Virtual Machines/VMs» кластера.
  2. Подключитесь удаленно или через SSH к виртуальным машинам напрямую и выключите их.
Сначала попробуйте выключить наименее важные из них, чтобы проверить, можно ли восстановить службы и повторно подключиться. При необходимости можно зарегистрировать виртуальные машины на другом хосте и включить их (при появлении запроса выберите «I moved it») сразу после завершения работы на отключенном хосте.
  • Windows: Используйте RDP или другое программное обеспечение для доступа к виртуальной машине и выключите ее.
  • Виртуальные машины RecoverPoint. Войдите в систему через PuTTY с учетными данными boxmgmt и следуйте инструкциям по выключению.
  • Secure Remote Services. Подключитесь с помощью PuTTY с учетными данными администратора и выполните команду poweroff или shutdown now.
  • Linux: Команда «shutdown now» выключает виртуальную машину, а команда «shutdown -r now» перезагружает ее.
Альтернативный метод завершения работы виртуальной машины, если у вас есть доступ к командной строке через оболочку PuTTY или DCUI для хоста и нет прямого доступа к виртуальным машинам. См. статью базы знаний https://kb.vmware.com/kb/1014165.
  • Команда, чтобы проверить, запущена ли виртуальная машина на узле и получить World ID: # localcli vm process list.
  • Команда завершения работы виртуальной машины: # localcli vm process kill -t soft -w <worldID>.
При использовании «soft», как в примере выше, выполняется наиболее плавное выключение. Если это не работает, используйте «hard» для немедленного выключения. В качестве крайней меры следует использовать параметр «force».
  1. В vCenter убедитесь, что остальные части кластера исправны, а также что отсутствует повторная синхронизация vSAN или любая другая ситуация, которая препятствует безопасному временному удалению хоста из vSAN для перезагрузки, даже если хост не будет сразу же включен.
  2. По возможности переведите хост в режим обслуживания. Используйте веб-клиент vSphere, если он доступен. Если нет, откройте оболочку из DCUI с помощью клавиш Alt + F1, войдите в систему как root и используйте командную строку, чтобы попытаться перевести хост в режим обслуживания. Убедитесь, что все виртуальные машины на хосте выключены, затем переведите хост в режим обслуживания с помощью командной строки, используя один из следующих вариантов:
  • Обеспечение доступности: esxcli system maintenanceMode set --enable true -m ensureObjectAccessibility.
  • Без миграции данных: esxcli system maintenanceMode set --enable true -m noAction.
  • Полная миграция данных: esxcli system maintenanceMode set --enable true -m evacuateAllData.
Проверьте еще раз, можно ли открыть консоль перед перезагрузкой, так как это будет последний шанс получить журналы до их очистки после загрузки.
  1. Перезагрузите хост с помощью элементов управления IDRAC или BMC или через командную строку с помощью команды reboot.
  2. После того как хост будет включен, он должен снова отображаться в vCenter. Попробуйте подключить его к кластеру вручную, если это не так. Если он по-прежнему не подключается, возможно, потребуется перезагрузить vCenter. Для устройств vCenter, не имеющих встроенного PSC, сначала перезагрузите PSC, а затем VCSA.
  3. Соберите пакет поддержки vCenter (включая журналы хостов) и подготовьте временную шкалу связанных событий, если требуется анализ причины. Сведения о сборе журналов в среде VxRail см. в статье базы знаний https://support.emc.com/kb/333684. Если сервисная заявка открыта в службе поддержки VxRail, необходимы также журналы оборудования с хоста и пакет журналов VxRail Manager.

Additional Information

Подробное описание (поясняет, почему обычно требуется перезагрузка хоста).

Обычно на хосте, который отключен от vCenter, служба hostd недоступна (или остановлена хостом). Эта служба необходима для управления хостом с помощью vCenter. Она требует большого объема памяти, поэтому она отключается, когда хост испытывает нехватку свободной памяти. Некоторые другие службы действуют аналогичным образом. Перезапуск служб (определенных или всех служб управления) на отключенном хосте должен позволить хосту повторно подключиться к vCenter. Однако причина, по которой служба не работает, часто связана с нехваткой ресурсов (ЦП, памяти) для хоста. Если это вызвано чем-то вроде утечки памяти hostd, необходимо выполнить перезагрузку, чтобы хост снова работал должным образом.

Утечка памяти происходит, когда какая-либо система использует системную память, а затем память не может быть повторно освобождена должным образом. Служба «hostd» часто связана с этим поведением, но не всегда. ESXi останавливает эту службу, чтобы предотвратить зависание. Службы управления хостом (не только hostd) также могут перестать отвечать без возможности перезапуститься из-за нехватки доступных ресурсов. После остановки работы hostd (а также vpxa и некоторых других) хост больше не подключается к vCenter. Иногда можно перезапустить службы и повторно подключить хост к vCenter, особенно если сначала удается освободить достаточно ресурсов.

Перезагрузка хоста решает эти проблемы подключения автоматически, так как освобожденная память снова становится доступной, и все службы повторно запускаются во время загрузки. Даже если хост можно снова подключить с помощью перезапуска hostd, vpxa и других служб, лучше всего перенести запущенные виртуальные машины с хоста (теперь это можно сделать, поскольку хост подключен к vCenter), перевести его в режим обслуживания и перезагрузить, чтобы убедиться в том, что все заблокированные ресурсы снова станут доступны. Это поможет избежать возврата хоста в состояние, когда он не отвечает, в краткосрочной перспективе. Кроме того, важно следить за исправлениями и модернизацией ESXi, которые устраняют основные причины утечки памяти и другие проблемы, которые могут привести к тому, что службы перестанут отвечать (или иным образом приведут к отключению хостов).
     
Для наилучшего решения этих ситуаций можно выполнить действия по проверке и устранению неисправностей, описанные в разделе «Решение». Хотя процесс сначала включает действия, незначительно влияющие на хост, в большинстве случаев требуется перезагрузка хоста. Зачастую это неудобно или не подходит заказчику на данный момент. Хост часто может нормально работать в течение некоторого времени, даже если он отключен от vCenter, и виртуальные машины на хосте + участие дисков хоста в vSAN продолжает работать. Лучше всего перезагрузить хост как можно скорее, но если требуется дождаться окна обслуживания или нерабочего времени, это нормально. Хост без памяти со временем выйдет из строя, и перезапуск виртуальных машин вряд ли поможет. Однако если в кластере нет других проблем, отказоустойчивость (высокая доступность, защита vSAN, возможность подключения виртуальных машин к другим хостам и т. д.) должна сохраняться.
 
Хотя перезагрузка хоста является основным способом исправления не отвечающих/отключенных хостов, журналы, необходимые для анализа причины этих проблем, вряд ли будут доступны после перезагрузки. Если можно получить хоть какой-то ответ от хоста, чтобы создать и собрать необходимые журналы, то дальнейший анализ с большей вероятностью сможет выявить основную причину. Если эти журналы нельзя собрать из-за того, что хост не отвечает, или перезагрузка уже выполнена или выбран вариант более быстрого решения (для получения журналов требуется некоторое время, и часто это того не стоит), по-прежнему есть журналы, которые могут помочь сузить поиск причины или помочь в определении оптимальных рекомендаций. Как минимум, следует собрать пакет журналов vCenter с журналами неисправного хоста и одного исправного хоста для сравнения. 

Другие статьи, связанные с не отвечающими и отключенными хостами (в vCenter).
  • Иногда интеллектуальный агент может привести к тому, что хост в vCenter будет показывать «Not Responding». См. статью VMware https://kb.vmware.com/kb/2145106 и статью базы знаний https://support.emc.com/kb/502016.  
  • Недоступность ESXi может быть связана с проблемами между подключаемыми модулями и PTAgent на хостах Dell. См. статью базы знаний https://support.emc.com/kb/504039.  

Affected Products

VxRail Appliance Family

Products

Pivotal Ready Architecture, VxRail 460 and 470 Nodes, VxRail Appliance Family, VxRail Appliance Series, VxRail G410, VxRail G Series Nodes, VxRail E Series Nodes, VxRail E460, VxRail E560, VxRail E560F, VxRail G560, VxRail G560F, VxRail Gen2 Hardware , VxRail P Series Nodes, VxRail P470, VxRail P570, VxRail P570F, VxRail S Series Nodes, VxRail S470, VxRail S570, VxRail Software, VxRail V Series Nodes, VxRail V470, VxRail V570, VxRail V570F ...
Article Properties
Article Number: 000167824
Article Type: Solution
Last Modified: 19 Jan 2024
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.