У меня есть сервер VMware ESXi, который работает почти 200 дней. Последние несколько дней, когда я пытаюсь подключиться к нему с помощью клиента VMware vSphere, я не могу подключиться. После ввода имени пользователя и пароля я вижу маленькое вращающееся колесо и строку состояния с надписью «Connecting ...», а затем «Loading Inventory ...», а затем я получаю сообщение об ошибке:
Сервер my.host.name не может интерпретировать запрос клиента. (Удаленный сервер возвратил ошибку: (503) Сервер недоступен
Вызов «ServiceInstance.RetrieveContent» для объекта «ServiceInstance» на сервере «my.host.name» завершился неудачно.
Я могу подключиться к серверу VMware ESXi по SSH. Кажется, что все виртуальные машины работают нормально, поэтому я хочу знать заранее, нужно ли мне отключить их для обслуживания !!! Если методы, предложенные в вашем ответе, будут мешать запуску виртуальных машин, четко укажите это, чтобы я знал, что нужно подготовиться к простоям. Спасибо!
Как я могу устранить эту ошибку в VMware ESXi?
(Я бы опубликовал номер версии, но не знаю, как получить его без консоли vSphere!)
РЕДАКТИРОВАТЬ: Примерно через месяц после того, как я задал этот вопрос, сервер по необъяснимой причине перезагрузился. Я не знаю, запаниковал он или что случилось ... но после перезагрузки эта проблема исчезла. Поэтому я не могу проверить / подтвердить какой-либо ответ, если проблема не появится снова (на что я надеюсь, что это не так!)
Вам необходимо перезапустить службы управления vmware. К счастью, это просто (поскольку у вас есть доступ по SSH) и не влияет на виртуальные машины.
Вкратце, SSH к фрейму esx как root
а затем выполните одну из двух следующих команд (в зависимости от того, является ли это esx / i):
Для ESX:
service mgmt-vmware restart
Для ESXi:
/sbin/services.sh restart
Я решил проблему, удалив Widecap Ошибка ServiceInstance.RetrieveContent
Это КБ VMware статья похоже соответствует описанному вами симптому. Убедитесь, что ваш DNS работает с точки зрения сервера ESXi.
Вариант 2. Можете ли вы убедиться, что ваш vCenter Server включен и служба запущена?
Мы столкнулись с аналогичной проблемой, и это закончилось отказом LUN SAN, которые были напрямую подключены через HBA Fibre Channel. очевидно, что один из двух файловых серверов имел событие аварийного переключения, но не переключился при сбое, поэтому хост ESXi не мог объявить эти пути мертвыми и имел приток проблем с блоком уровня LUN с HBA занято, шина занята, команды прерывания засорены в vmkernel. журнал.
Служба поддержки VMware смогла помочь нам разобраться в проблемах после восстановления кластеров файловой системы SAN в активное / активное состояние (NetApp). Шестнадцатеричные ошибки "cat /var/log/vmkernel.log | grep sense | less" показали многочисленные проблемы на уровне LUN (D: 0x2), занятость шины (H: 0x2), занятость HBA (D: 0x8), команды прерывания (H : 0x5) из тайм-аутов, что указывает на то, что файловый агент SAN не был должным образом отработан и по-прежнему сообщает о себе как доступный
После восстановления файлового сервера SAN для путей / LUN мы выполнили команду "/sbin/services.sh restart", которая завершилась, и мы смогли снова подключить vClient к хосту, Интернету и снова присоединить его к существующему кластеру, чтобы очистить " сиротские "" безымянные "виртуальные машины, которые были остатками.
На моем устройстве vCenter 6.5 vpxd
сервисное ядро выгружает и выдает эту ошибку.
Пока только обходной путь / решение: заблокируйте доступ к хосту ESX до тех пор, пока не будут запущены все службы vCenter.
Теперь модуль сценария оболочки / systemd в vCenter создает правила брандмауэра / пакетного фильтра iptables при загрузке. Как только службы vCenter запускаются и средняя загрузка падает ниже 0,5, сценарий удаляет правила iptables. Только теперь vCenter может «видеть» хосты ESX и какое-то время доволен. Если проблема возникает снова, я перезапускаю vCenter.
Сценарий оболочки:
#!/bin/bash
# /usr/local/bin/block-esx-access-on-boot.sh
export ESX_HOSTS="ESX1-IP,ESX2-DNS,ESX3-IP"
export LOAD_THRESHOLD="0.5"
sleep 5
LOAD="$(cut -d' ' -f1 /proc/loadavg)"
echo "Waiting for 1min loadavg ${LOAD} > ${LOAD_THRESHOLD} ..."
while [ "$(echo "${LOAD} > ${LOAD_THRESHOLD}" | bc)" == "0" ] ; do
echo "Waiting for 1min loadavg ${LOAD} > ${LOAD_THRESHOLD} ..."
sleep 3
LOAD="$(cut -d' ' -f1 /proc/loadavg)"
done
echo "Blocking outgoing transfers to ${ESX_HOSTS}"
iptables -A OUTPUT -d ${ESX_HOSTS} -j DROP
iptables -L OUTPUT
while [ "$(echo "${LOAD} < ${LOAD_THRESHOLD}" | bc)" == "0" ] ; do
echo "Waiting for 1min loadavg ${LOAD} < ${LOAD_THRESHOLD} ..."
sleep 60
LOAD="$(cut -d' ' -f1 /proc/loadavg)"
done
echo "Allowing outgoing transfers to ${ESX_HOSTS}"
iptables -D OUTPUT -d ${ESX_HOSTS} -j DROP
iptables -L OUTPUT
Модуль systemd:
# /etc/systemd/system/block-esx-access-on-boot.service
[Unit]
Description=Block ESX Access on Boot
After=network.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/block-esx-access-on-boot.sh
[Install]
WantedBy=multi-user.target
https://gist.github.com/quatauta/a1ac390633006996fbc547da9bd01ef9
Я получил эту ошибку сразу после успешного обновления vcenter 5.0 до 5.1. Я заметил несколько предупреждений (в разделе СОБЫТИЯ (задачи и события)) в vcenter от учетных записей служб, которые я настроил в прошлом для различных элементов (учетные записи svc kaspersky vsheild и orion syslog), которые показывали отказ в доступе. Я добавил эти учетные записи в группу локальных администраторов на vcenter, и мои проблемы исчезли.
Однако, прежде чем я обнаружил это, чтобы найти обходной путь, я бы просто перезапустил службу сервера vmware, и тогда я мог бы без проблем войти в систему и получить доступ к консолям vm. Примерно через 5 минут консоли становились черными, и я больше не мог получить к ним доступ. Если бы я вышел из системы и попытался вернуться в vcenter, я бы получил такую ошибку:
Вызов «ServiceInstance.RetrieveContent» для объекта «ServiceInstance» на сервере «my.host.name» завершился неудачно.
Таким образом, если вы можете войти в vcenter, просмотрите журналы СОБЫТИЙ и посмотрите, есть ли какие-либо предупреждения об отказе в доступе. Если есть, добавьте эти учетные записи в локальную группу администраторов на vCenter.
Мы столкнулись с той же проблемой. Служба поддержки VMWare заявляет, что vCenter не синхронизирован с системой единого входа (SSO). Простая перезагрузка сервера SSO при выключенном сервере vCenter должна решить проблему:
Вот последовательность:
выключите сервер vCenter.
затем перезагрузите поле SSO и дождитесь, пока все службы VMWare вернутся в этот ящик.
включите сервер vCenter
перезапустил службы сервера vcenter в правильной последовательности (каталог, kdc, служба сертификатов, idm, sts, служба inv, а затем служба vc
Получил это после изменения IP-адреса vCenter
Я использовал # 6 https://rlevchenko.com/2016/03/24/vcenter-503-service-unavailable/ чтобы включить оболочку.
ssh на сервер vcenter
Команда> оболочка
vi / etc / hosts изменили IP там
сервис-контроль --stop --all
сервис-контроль - старт - все
Перезагрузка нашего сервера vCenter помогла нам решить эту проблему.
мы не могли vMotion или создавать шаблоны без ошибки 503. Я также видел это в прошлом, когда перезагрузка vCenter не помогает, и нам нужно было перезагрузить хост. Это означает, что виртуальные машины на этом хосте тоже вышли из строя.
Ошибка 503 Service Unavailable - это код состояния HTTP-ответа, который указывает, что сервер временно не может обработать ваш запрос. Эта проблема может возникнуть по многим причинам.
Чтобы решить эту проблему, следуйте базе знаний VMware, в которой объясняется 503 Сервис недоступен