Eu tenho um servidor VMware ESXi que está em funcionamento há quase 200 dias. Nos últimos dias, quando tentei me conectar a ele usando o VMware vSphere Client, não consegui me conectar. Depois de inserir meu nome de usuário e senha, vejo a pequena roda giratória e a linha de status dizer "Conectando ..." e "Carregando Inventário ..." e, em seguida, recebo uma mensagem de erro:
Theserver'my.host.name'couldnotinterprettheclient'srequest.(Theremoteserverreturnedanerror:(503)ServerUnavailable
Call"ServiceInstance.RetrieveContent" for object "ServiceInstance" on Server "my.host.name" failed.
Eu posso acessar o SSH no servidor VMware ESXi. Todas as máquinas virtuais parecem estar funcionando bem, por isso quero saber de antemão se preciso ativá-las para manutenção Se os métodos propostos em sua resposta interferirem na execução das VMs, por favor, indique claramente que então eu sei para se preparar para o tempo de inatividade. Obrigado!
Como posso resolver essa condição de erro no VMware ESXi?
(Eu colocaria o número da versão, mas não sei como obtê-lo sem o console do vSphere!)
EDIT: Aproximadamente um mês depois de fazer essa pergunta, o servidor reinicializou-se inexplicavelmente. Eu não sei se entrou em pânico ou o que aconteceu ... mas depois que foi reiniciado, esse problema se foi. Então eu não posso testar / confirmar qualquer resposta a menos que o problema reapareça (o que eu espero que não aconteça!)
Você precisa reiniciar os serviços de gerenciamento de vmware. Felizmente, isso é fácil (já que você tem acesso SSH) e não afeta as máquinas virtuais.
Em poucas palavras, conecte o SSH ao quadro esx como root e execute um dos dois comandos a seguir (dependendo de se é esx / i):
Para o ESX:
service mgmt-vmware restart
Para o ESXi:
/sbin/services.sh restart
Resolvi o problema ao desinstalar o widecap ServiceInstance.RetrieveContent Erro
Este artigo da VMware KB parece corresponder seu sintoma descrito. Verifique se o seu DNS está funcionando a partir do ponto de vista do servidor ESXi.
Opção 2: você pode verificar se o seu vCenter Server está ativo e se o serviço foi iniciado?
Tivemos um problema semelhante com relação a isso e acabou sendo SAN LUNs com falha que foram conectados diretamente por meio de HBAs Fibre Channel. aparentemente um dos dois arquivadores teve um evento de failover mas não apresentou failover corretamente, portanto, o host ESXi não pôde declarar esses caminhos inativos e teve um influxo de problemas de blocos de nível LUN com ocupado HBA, ocupado por barramento, anular comandos colocados no vmkernel. log.
O suporte da VMware conseguiu acompanhar os problemas depois que os clusters de cabeçote do arquivo SAN foram restaurados para um estado ativo / ativo (NetApp). Os erros hex do "cat /var/log/vmkernel.log | grep sense | less" mostraram vários problemas no nível do LUN (D: 0x2), bus ocupado (H: 0x2), HBA ocupado (D: 0x8), anular comandos (H : 0x5) de tempos limite que apontam para um arquivador SAN que não está sendo corretamente submetido a failover e ainda se reporta como disponível
Após o restaurador do arquivador SAN para os caminhos / LUNs, emitimos o comando "/sbin/services.sh restart", o qual completou & fomos capazes de vClient no host novamente, a web & junte-o de volta ao cluster existente para limpar as VMs "anônimas" "sem nome" que eram sobras residuais.
No meu dispositivo vCenter 6.5, o core vpxd service faz o dump e produz esse erro.
Apenas solução / solução até o momento: bloquear o acesso ao host ESX até que todos os serviços do vCenter sejam iniciados.
Agora, um shell script / systemd unit no vCenter cria regras de filtro de firewall / pacote iptables na inicialização. Depois que os serviços do vCenter são iniciados e a média de carregamento cai abaixo de 0,5, o script exclui as regras do iptables. Só agora o vCenter consegue "ver" os hosts ESX e fica feliz por um tempo. Se o problema reaparecer, reinicio o vCenter.
O script de shell:
#!/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
A unidade do sistema:
# /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
Recebi este erro logo após o upgrade bem-sucedido do vcenter 5.0 para o 5.1. Eu observei vários alertas (em EVENTOS (tarefas e eventos)) no vcenter de contas de serviço que eu tinha configurado no passado para vários itens (kaspersky vsheild e orion syslog svc accounts) que mostravam acesso negado. Eu adicionei essas contas ao grupo de administradores locais no vcenter e meus problemas foram embora.
Antes de descobrir isso, no entanto, para me fornecer uma solução alternativa, eu simplesmente reiniciaria o serviço do servidor vmware e, em seguida, eu poderia fazer o login sem problemas e acessar os consoles da VM. Depois de 5 minutos, os consoles ficariam pretos e eu não conseguiria mais acessá-los. Se eu fiz o logout e tentei voltar ao vcenter, eu receberia este erro:
Chame "ServiceInstance.RetrieveContent" para o objeto "ServiceInstance" no servidor "my.host.name" falhou.
Assim, a regra é que, se você conseguir entrar no vcenter, verifique os registros de EVENT e veja se há alertas de acesso negado. Se houver, adicione essas contas ao grupo de administradores locais no vCenter.
Nos deparamos com o mesmo problema. O suporte VMWare afirma que o vCenter está fora de sincronia com o SSO (Single Sign On). Reinicializações simples do servidor SSO enquanto o servidor vCenter estiver desligado devem resolver o problema:
Veja a sequência:
desligue o servidor vCenter.
em seguida, reinicie a caixa SSO e aguarde até que todos os serviços VMWare voltem a aparecer nesta caixa
ligue o servidor vCenter
reiniciou os serviços do servidor vcenter na sequência adequada (diretório, kdc, serviço de certificado, idm, sts, serviço inv e, em seguida, serviço vc
Eu peguei isso depois de mudar o endereço IP do vCenter
Eu usei o # 6 link para ativar o shell.
ssh no servidor do vcenter
Comando > shell
vi / etc / hosts alterou o IP lá
service-control --stop --all
serviço-controle --start --all
reiniciar o nosso servidor vCenter ajudou a resolver este problema para nós.
não conseguimos criar o vMotion nem criar modelos sem receber o erro 503. Eu também já vi isso no passado, quando a reinicialização do vCenter não ajuda e precisamos reinicializar um host. o que significa que as VMs nesse host também diminuíram.