Eu tenho um ESXi 5.5.0 autônomo b2143827. Ele está sendo executado em um Dell R710 com 144 GB de RAM. Tem aproximadamente 20 VMs nele.
No momento, não consigo acessar o console por meio do cliente VMWare vSphere ou SSH. Ele apenas age como se o servidor não existisse. O host retornará em horários aparentemente aleatórios e eu posso acessar o host via SSH e o cliente vSphere, mas ele simplesmente sairá da rede novamente em um momento indeterminado no futuro. Posso acessá-lo através do console de emergência no próprio host físico ( Alt+F1).
No entanto, todas as VMs estão ativas e funcionando. Mas cerca de 10 vezes por dia, todas as VMs vão cair fora da rede entre 15 segundos e 5 minutos. Então eles vão voltar muito bem e tudo continua funcionando.
Eu fiz o seguinte:
- Estava em uma compilação anterior, atualizei para b2143827. Isso não fez diferença
/sbin/services.sh restart- isso não ajuda a situação- Reiniciou o host físico. Isso não fez diferença.
- No console físico (
Alt+F1), fiz o ping de outro dispositivo físico na rede. Não descarta nenhum pacote. - No console físico, fiz ping em uma máquina virtual no host. Sofre aproximadamente 80% de perda
- De uma máquina remota, posso executar ping no endereço IP de gerenciamento com 0% de perda de pacotes
- A partir de uma máquina remota, posso executar ping em uma VM no host e posso ver o host sair e voltar à rede de vez em quando
- Eu observei
tail -f /var/log/hostd.logpor um tempo e não vi nada de desagradável acontecendo lá - O sistema é instalado em um cartão SD. Desliguei o servidor,
DDtransferi o cartão para outro cartão e inicializei-o no novo cartão. O mesmo problema. - Tentei um switch de rede diferente
- Executei o Dell Update Manager e atualizei cada firmware para a versão mais recente.
Eu estou em uma perda para onde ir a partir daqui. Este servidor operou perfeitamente nos últimos 2,5 anos. O VMWare costumava ser instalado em uma unidade física, mas há 6 meses ele foi transferido para o cartão SD para que pudéssemos reconfigurar as unidades físicas.
Sugiro atualizar o firmware das placas de rede Broadcom em seu servidor Dell PowerEdge. O fato de você estar vendo um problema de conectividade externa, além de pings específicos da VM, aponta para um problema de NIC.
Em relação à inicialização SDHC, eu realmente defendo apenas o uso de inicialização SD/USB em servidores ESXi que são membros de um cluster vSphere e possuem armazenamento compartilhado. Devido ao modo de falha dessas placas no ESXi, não há vantagem em usá-las para inicializar sistemas autônomos. Veja as diferenças entre os modos instalável e integrado do ESXi .
Após 3 dias de solução de problemas ininterrupta, descobri que o problema é ... espere ... nosso Cisco ASA se cagando e inundando a rede com tráfego falso.
Como estávamos executando comutação bastante básica e o ambiente do servidor é 100% virtualizado, não notamos nada dentro da pilha de rede.
O maior arenque vermelho que sofri aqui foi fazer ping no sistema operacional convidado de seu host. Eu teria pensado que isso era totalmente autônomo contra os NICs físicos, mas aparentemente não.
Acabei descobrindo o problema espelhando a porta de gerenciamento no switch e observando o tráfego de / para ele com o Wireshark, e vendo o tráfego sair da porta de origem, mas nunca, nunca, chegar ao destino. Como não consegui vê-lo dentro da própria rede, levei apenas mais 4 horas para isolar o ASA como a origem do problema.
Desde a remoção do ASA da rede, tudo correu bem.
Acontece que o ASA não se cagou, alguém criou uma regra NAT mutilada que não tinha
no-proxy-arp, então começou a responder às solicitações ARP em todo o /24 interno. Excluindo essa regra e dando um pontapé inicial na bunda da pessoa que a adicionou e agora temos o que, por que e quem.Isso também explica por que a rede somente host não estava funcionando conforme o esperado. O ASA estava respondendo à solicitação ARP, portanto, o host não sabia que deveria fazer uma solicitação de rede somente do host.