Isso parece ser um problema de hardware para mim, por exemplo, ram ruim. Tente executar o disco Offline Diagnostics para o seu modelo de servidor (se você não tiver um, faça o download de um ISO em hp.com)
Instalei o ESXi 4.0 em um HP Proliant g5 com um processador Xeon de 64 bits e aproveitei a licença gratuita para trabalhar em uma escola pública. Eu criei duas instâncias do servidor 2003 a partir do zero, uma para ser o DC, DHCP, o outro para ser um servidor de arquivos e backup DNS / DHCP. Eu tinha ambos os convidados funcionando bem, configurar minhas contas de usuário, transferi os dados, etc etc
Uma vez eu entrei em uma máquina cliente para o domínio, eu iria encontrar que ambos os meus convidados do Windows iria travar. Às vezes, seria por cinco ou mais minutos, uma vez que foi durante a noite. O estado "trancado" significa que, até onde eu sabia, todos os serviços foram interrompidos; dhcp não mais entregou IP's, DNS parou de funcionar, eu não podia RDP no servidor. O host ESXi, meu servidor HP, ainda estava funcionando bem. O VSphere estava funcionando, e eu podia ver o desempenho dos convidados individuais.
Eu tentava desligar os hosts de dentro do VSPhere, e os hosts começavam a desligar, mas ficavam em 95%, e ficavam Dessa forma, às vezes apenas por 10 minutos, outros por horas. Várias vezes tive que reiniciar o ESXi do console para reiniciar minhas máquinas.
Agora, alguém pode me dizer o que está acontecendo e como posso corrigi-lo ou tomar medidas para evitar isso? Eu contratei um consultor para vir dar uma olhada nisso, alguém que tem experiência e conhecimento em que confio, e ele me disse que nunca tinha visto nada assim antes. Ele falou com um amigo dele que é certificado pela VM, e ele também disse que nunca tinha ouvido falar dessa questão. Obrigado pelas suas respostas e farei o meu melhor para responder o mais rápido possível. Atualmente, o servidor está desligado e eu reinstitui as caixas de 2000 anos do meu Server 2000, e estou pensando em instalar o ESXi 3.5. Alguém sabe que um host criado em 4.0 funcionará em 3.5? Eu realmente gostaria de evitar ter que reconstruir essas contas! Eu sei que 4.0 funciona neste servidor, como eu tenho outro servidor em outra escola com o mesmo hardware exato executando 4.0 bem.
Isso parece ser um problema de hardware para mim, por exemplo, ram ruim. Tente executar o disco Offline Diagnostics para o seu modelo de servidor (se você não tiver um, faça o download de um ISO em hp.com)
Os registros estão mostrando alguma coisa? E quanto à atividade de rede para as VMs do VSphere?
Minha próxima coisa que eu tentaria fazer é instalar algum tipo de sniffer de pacotes se nada aparecer nos logs. Se o sistema estiver em todo responsivo, você pode tentar executar o wireshark diretamente no sistema, verificando se ele atualizará a tela antes de desacelerar ou travar. Talvez rodar o tcpmon de sysinternals possa dar uma pista.
Caso contrário, tente configurar uma VM com o Linux e direcione-a (ou redirecione o tráfego de rede das VMs) para ver o que ela pode ver com o wireshark.
Se o tráfego de rede estiver errado, talvez seja necessário encontrar uma maneira de identificar o que está acontecendo; se fosse apenas um conflito de nome ou algum tipo de problema de replicação do AD, ele estaria nos logs.
Observamos a degradação quando há processos pesados de backup acontecendo na rede, mas você não mencionou nada sobre a replicação de arquivos ou algo do tipo.
Isso é viável na sua situação?
Quando isso acontece, você pode entrar em um console no host (não tenho certeza se o ESXi fornece um console ou não) e verificar se o processo está órfão ou não. Se o processo que é a VM for órfão, será necessário reinicializar o host para limpar o processo.
Eu já vi isso acontecer algumas vezes no ESX 3.5 e 4.0. Se os convidados são upgrades de 3.5, então você precisa ter certeza de que a versão do hardware foi atualizada, assim como as ferramentas do cliente. Eu suponho que você instalou as ferramentas do cliente nos convidados?
Não tenho motivos para suspeitar que exista um problema de compatibilidade, mas verifiquei os próprios servidores e todo o hardware do componente (especialmente NICs, visto vários problemas com NICs no meu tempo) para compatibilidade com o ESXi 4 VMware HCL ?
Este é um processador de dois núcleos? Como você configurou suas máquinas virtuais, como o homem vCPU escolheu para cada um? Eu sei que 3.5 tem problemas com seu tempo de inicialização se você selecionou mais de 1 vCPU em cada máquina, e você não obteve nenhum desempenho de qualquer maneira.
Eu encontrei situações no passado em que algo em uma política de grupo resultava em uma máquina travando periodicamente (no meu caso, estava aplicando GPOs específicos do Vista para gerenciamento de energia em uma máquina Win7 IIRC), então eu sugeriria uma rápida olhada para ver se a entrada no domínio causou um problema sutil.
Verifique o seguinte:
Quais os instantâneos atualmente deixados abertos na VM convidada? Instantâneos em DCs não são uma boa ideia, mas, em geral, deixar um snapshot aberto por muito tempo pode levar a travamentos de VM, especialmente em servidores DCs SQL e Exchange.
Qualquer hardware incomum conectado à VM, e. Disquete, passagem USB ou portas seriais? Desvie os dispositivos para o mínimo que você precisar.
Execute um conjunto de testes no hardware do servidor. Há uma suíte decente no smartstart da HP para os G5s. Se você ainda tiver suporte no hardware, ligue para a HP e veja se o pessoal de suporte deles tem algum conselho (eles são muito bons, IMO).
Troque os blocos de memória RAM por outro conjunto, se houver algum disponível.
De que tipo de discos as VMs estão sendo executadas? SAN ou local? Controlador de estoque ou um discreto? Você descartou problemas com a mídia de instalação?
Editar: acabou de lembrar ... verifique suas configurações de NIC no servidor host. Eu me lembro vagamente de ter problemas com um dos recursos da NIC (descarregamento de TCP?) Sendo ativado na NIC host e precisando desativá-lo no ESX 4.0.
Eu tenho o problema relacionado acima (ESXi 4), mas isso só aconteceu com as 3 VMs que não conseguem desligar, mas ficaram com 95%. Percebeu que o problema foi devido a SEP10, mas o primeiro e segundo vm que instalou com a Symantec não tem o problema, exceto o terceiro. Exclua vm reinstalar e continua a mesma e sempre será a 3ª vm.