Uma ferramenta desconhecida está limpando nossas máquinas virtuais e não podemos identificá-lo

18

Uma visualização de console de uma VM do Windows 2008 R2, no vSphere, está mostrando a seguinte tela:

"Operação 2 de 2" "Limpando o disco"

Alguém pode aconselhar sobre o que é este programa?

Algumas informações sobre esse mistério:

Várias VMs agora são afetadas. O sintoma é após a reinicialização "OS não encontrado" mensagem está aparecendo.

  • As VMs estão sendo executadas no ESXi. VMs estão sendo executados em um datastore específico
  • Netapp NFS Montar o disco em uma caixa de trabalho não mostra nenhuma tabela de partição, ainda não foi capaz de fazer o despejo hexadecimal.
  • A VM não foi totalmente redefinida, teria que ser uma reinicialização por software iniciada pelo sistema operacional
  • NÃO há iso montado Não havia acesso "não convidado" à VM, portanto precisaria ser RDP ou similar
  • Os backups são realizados usando o software de backup netapp durante a noite
  • O NFS em questão é thin-provisioned no back-end (nível de matriz) e ficou sem espaço logo depois de termos visto esses problemas.
por Rqomey 24.07.2014 / 13:35

2 respostas

10

Infelizmente, parece que não conseguimos chegar ao fundo da aplicação, mas para obter algum algum valor deste incidente, quis criar uma resposta de referência. Isso é centralizado no gerenciamento de VMware e camada virtual. Muitos administradores estão segregados e não conseguem acesso de convidado ou armazenamento rapidamente, e isso é para eles :)

O

link parece ser a melhor correspondência para uma aplicação real, que @MosheKatz encontrou.

Se isso acontecer no futuro, a investigação deve ser assim:

  • Você percebe algumas mas nem todas as VMs falharam. Você suspeita que isso é devido a um problema de armazenamento (como geralmente a causa mais provável)
  • Primeiro, tente isolar um fator comum. Todas as VMs com falhas compartilham o mesmo armazenamento de dados? Neste caso eles estavam, mas algumas máquinas estavam ok, então descartamos problemas óbvios de hardware.
  • Verifique todas as VMs quebradas para ver se havia um fator comum (hora, função etc.). Neste caso não houve.
  • Verifique se há outros eventos incomuns. Algo levantou uma bandeira aqui:

    • O armazenamento NFS era thin-backed (no nível da matriz). Isso significa que, embora ex. 200GB é apresentado para os hosts ESXi, na verdade, apenas 100GB estão disponíveis. Apenas a matriz tem esse conhecimento no entanto. O que descobrimos foi que várias VMs foram pausadas porque ficaram sem espaço em disco. Embora essa possa ter sido a causa raiz, nossa primeira ação foi alocar mais armazenamento no back-end, para remover isso como um problema.
  • Depois que isso foi resolvido (uma simples alteração na interface do usuário) e as VMs pausadas foram reiniciadas com sucesso, voltamos ao problema original. Montamos os discos virtuais das VMs quebradas para uma VM funcional e vimos que não havia nenhuma tabela de partição nos discos. Nós não tínhamos um visualizador de hexadecimais disponível, então tivemos que assumir que os discos estavam vazios.

  • O sistema de monitoramento alertou para uma nova VM que não respondia. Isso foi ótimo, já que uma carga de VMs tinha minutos antes de ter se tornado insatisfatória devido ao problema de espaço em disco, portanto, o fato desta nova VM ter sido encontrada rapidamente foi um sinal de boa administração de monitoramento.

  • Abrimos um console, verificamos o convidado e vimos a captura de tela acima.

    • Nesse estágio, fui até a sala de bate-papo de falhas do servidor para ver se o programa poderia ser identificado, enquanto meu colega de armazenamento verificava todos os logs e eventos da camada virtual para garantir que não houvesse nenhuma operação de armazenamento em execução.
  • O que deveríamos ter feito era suspender a VM, permitir que o arquivo de suspensão fosse escrito e analisar o despejo para ver se o programa em execução poderia ser identificado. Suspenda a VM no PDF principal VMware KB

No final do dia, sabíamos e ferramentas de infraestrutura virtual não teriam sido relatadas dentro de um convidado como o acima estava fazendo. Poderíamos ver que não havia ISO montado e nenhum evento registrado na VM. Poderíamos ver que a VM não era "hard power cycled", apenas uma reinicialização suave (isso é invisível para a infraestrutura subjacente). Sabíamos que não era o lado do armazenamento, já havíamos decidido isso. Suspeitamos que não fosse automatizado, pois estava acontecendo ao longo de algumas horas em VMs específicas. Nós achamos que não era malicioso, porque o console reportaria o Disk Wipe se fosse :)

Então, a conclusão foi uma limpeza de disco iniciada pelo usuário. Até onde minha investigação foi, mas espero que você tenha achado útil.

Lições aprendidas:

  • Backup e teste suas restaurações
  • Certifique-se de que todos os usuários, usuários particulares de administração, saibam que estão trabalhando em um ambiente thin provisioned e evite qualquer coisa como formatação de disco de write-out (ou seja, gravar cargas de 1s
  • Tenha um bom sistema de monitoramento em vigor.
  • E um novo para mim: em qualquer ambiente virtual grande, tenha uma VM pronta para as ferramentas, mesmo desligada, com as ferramentas de diagnóstico instaladas; desempenho, armazenamento de rede. Se isso estivesse disponível, poderíamos ter montado e executado um dump hexadecimal no disco danificado para ver se estava realmente vazio ou se faltava apenas um mbr. Poderíamos também ter visto se foi escrito com 1's.
por 04.08.2014 / 13:00
-1

Acho que seu problema é um recurso padrão de recuperação de espaço do VMware.

Este artigo pode ajudá-lo: Como esclarecer dúvidas sobre o disco virtual com espaço eficiente

    
por 01.08.2014 / 17:26