O VMWare ESXi parou de responder

Question

Eu tenho um servidor doméstico com um Q6600 Quad Core e 8 GB de RAM rodando com VMWare ESXi 3.5 por cerca de 8 meses agora. Tenho 2 datastores, com 1TB (SATA HDs) cada um, um com 150GB grátis e outro com 240GB grátis. Eu tenho 9 VMs rodando 24x7 nele. Tudo estava indo bem até ontem.
Fora do blues, parei de receber respostas das VMs no ESXi. No início, eu poderia conectar usando o cliente de infra-estrutura, mas, quando se eu tentasse obter informações de qualquer VM, eu iria receber uma mensagem que a VM não pôde ser alcançada. Olhando para as informações do Host, ele me mostrava informações de rede, cpu, memória, mas quando eu tentava acessar o armazenamento de dados, ele normalmente deixava de responder. Eu só consegui abrir o datastore localizado onde o ESXi é instalado uma vez e todas as VMs estavam lá. Agora, não consigo mais me conectar a ele e realmente não sei o que fazer.
Atualizar Fiz várias reinicializações no host, e o problema se repete. Eu me conecto através do cliente de infra-estrutura mas, após alguns segundos, ele não responde. Depois de um tempo, agora não consigo me conectar mais com o cliente End Update
Qual é o melhor curso de ação para diagnosticar o problema? Eu posso acessar a tela do ESXi sem problemas, mas não sei o que fazer. Eu estava pensando em reinstalá-lo, talvez com a versão 4.0, mas não tenho certeza se devo fazer isso. Onde (e como) posso acessar qualquer coisa que possa me ajudar a descobrir o que está errado?
Tks

Nova atualização Eu reconfigurei a configuração de volta ao padrão e consegui me conectar com o VI Client. Eu recoloquei uma das minhas VMs e comecei a inicializá-la, mas tive problemas novamente; a VM tentou inicializar e acabou travando, e o cliente VI parou de responder e não consegui me conectar a ela novamente. Seguindo o conselho do @pehrs, entrei no modo não suportado e verifiquei a mensagem / var / log / e encontrei um monte de erros de leitura. Abaixo está uma amostra:

Aug 31 02:59:36 vmkernel: 0: 00: 28: 41.882 cpu0: 2179) StorageMonitor: 196: vmhba33: 0: 0: 0 status = 2/0 0xb 0x0 0x0
Aug 31 02:59:37 vmkernel: 0: 00: 28: 42: 357 cpu0: 5279) < 3 > ata4: transageld ATA stat / err 0x71 / 04 para SCSI SK / ASC / ASCQ 0xb / 00/00
31 de ago de 02:59:37 vmkernel: < 4 > ata4: status = 0x71 {DriveReady DeviceFault SeekComplete Erro 0: 00: 28: 42.357 cpu0: 5279)}
última mensagem repetida 1 vezes

Eu também tenho alguns DriveStatusError em algumas linhas do mesmo arquivo. Agora, observando o /var/log/vmware/hostd-0.log, estou recebendo alguns erros depois de abrir com êxito os arquivos vmdk da primeira VM que eu anexei novamente:

[2010-08-31 02: 44: 15: 199 Aviso 'PropertyCollector' 213004] Falha de GetPropertyProvider para haTask-ha-folder-vm-vim.Folder.registerVm-45
[2010-08-31 02: 45: 05: 693 Aviso 'PropertyCollector' 98311] Falha de GetPropertyProvider para haTask-16-vim.VirtualMachine.powerOn-49

Eu recebo vários outros erros de GetPropertyProvider depois disso, então alguns tempos limite ... Parece claro que eu tenho um problema de HD. O que posso fazer para salvar minhas VMs? Posso fazer uma verificação nos HDs? Se sim, como? Obrigado! Fim da atualização

    

Answer 1

Eu suspeito que você esteja usando drives de nível de consumidor para o seu armazenamento? Em caso afirmativo, eles têm sistemas de recuperação de erros internos que interrompem o volume enquanto a recuperação de erros está sendo tentada. Quando isso ocorre, toda a veiculação de armazenamento pode ser atrasada por um período considerável de tempo (mais de 10 segundos).

Em unidades de nível corporativo, esse "recurso" é desabilitado ou nunca incluído, na suposição de que a recuperação de erros será tratada no nível da matriz RAID (RAID implicitamente assumido para implantações corporativas). Por exemplo, a Western Digital refere-se a esse recurso (ou remoção de um recurso!) Como TLER - Recuperação de Erro com Tempo Limitado. Em termos práticos, isso significa que um drive com TLER habilitado não irá parar por um longo período de tempo para executar a recuperação / remapeamento do setor / o que for.

Portanto, se você estiver executando discos de consumo, há uma boa chance de você ter acertado um erro em um de seus discos e está repetidamente paralisando enquanto tenta recuperar.

Soluções para isso podem ser um pouco complicadas - não sei se algum verificador de erros de disco de terceiros suportará o VMFS e não correria o risco de puxar os discos e digitalizá-los com QUALQUER COISA, a menos que esteja descarte o volume.

    

Answer 2

Por que não apenas reinicializar a máquina host? Se você não puder reinicializá-lo a partir do console, basta desligá-lo. É uma medida drástica, mas tive que fazê-lo em mais de uma ocasião.

    

Answer 3

Tem certeza de que instalou o framework .NET necessário? Eu acredito que o VI Client requer o .NET 3.5.

Eu vi isso no meu último show, onde um laboratório estava tentando executar uma caixa ESXi autônoma. Ele poderia se conectar, mas seria interrompido, desconectado ou interrompido. Estávamos no limite, mas em algum momento ele acabou instalando um framework .NET adicional e isso resolveu o problema completamente.

Sim, sei que parece loucura.

    

Answer 4

Você tem acesso por tempo suficiente para controlar as VMs? Nesse caso, você pode tentar desabilitar as VMs sistematicamente para determinar se uma VM está de alguma forma em jogo com essa situação.

    

Answer 5

No ESX 3.5, se você editou manualmente seus arquivos .vmx (como em um editor de texto) e digitou algo incorretamente, isso quebraria o console do VI. Pior, isso aconteceria com todos e quaisquer consoles VI, independentemente de quem cometesse o erro, e não daria nenhuma mensagem, aviso ou erro. (Eu briguei com o nosso representante da VMware sobre isso, mas eles disseram que esse era o comportamento esperado ...)

Recomendo que você descubra todas as VMs que estavam sendo modificadas manualmente antes que tudo ficasse de lado, por todos do seu time. E depois validá-los.

Isso é especialmente doloroso se você trabalha com pessoas que não sabem escrever e digitar com precisão ...

    

Answer 6

tente enviar SSH para a máquina em questão.

pelo menos, se o console SSH não desligar no mesmo período de tempo, você poderá determinar se a interface cliente / servidor do vSphere está desativada ou se o próprio servidor está com problemas.

De qualquer forma, isso soa como um servidor ESXi "morto" para mim. Tente atualizar para um 4.0 que eu considero um último esforço e / ou tente reparar a instalação se for possível, mas ...

parece frenético