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

Uma visualização do 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:

Agora, várias VMs são efetuadas. O sintoma é após a reinicialização da mensagem "SO não encontrado".

• As VMs estão sendo executadas no ESXi. As VMs estão sendo executadas em um armazenamento de dados específico
• Netapp NFS A montagem do disco em uma caixa de trabalho não mostra nenhuma tabela de partição, ainda não foi possível fazer o dump hexadecimal.
• A VM não foi redefinida por hardware, precisaria ser uma redefinição por software iniciada pelo SO
• NÃO há montagem iso Não havia acesso "não convidado" à VM, portanto, seria necessário ser RDP ou similar
• Os backups são realizados usando o software de backup netapp durante a noite
• O NFS em questão possui provisionamento thin no back-end (nível da matriz) e ficou sem espaço logo após ver esses problemas.

Infelizmente, parece que talvez não cheguemos ao fundo do que era o aplicativo, mas para obter algum valor com esse incidente, eu queria criar uma resposta de referência. Isso é centralizado no VMware e no gerenciamento de camada virtual. Muitos administradores estão segregados e não podem obter acesso de convidado ou armazenamento rapidamente, e isso é para eles :)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swf parece ser a correspondência mais próxima a um aplicativo real, encontrado pelo @MosheKatz.

Se isso aconteceu no futuro, a investigação deve ser a seguinte:

• Você percebe que algumas mas nem todas as VMs falharam. Você suspeita que isso ocorra devido a um problema de armazenamento (como geralmente a causa mais provável)
• Primeiro, tente isolar um fator comum. Todas as VMs com falha compartilham o mesmo armazenamento de dados? Nesse caso, 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 (tempo, função etc.). Nesse caso, não havia.

• Verifique se há outros eventos incomuns. Algo levantou uma bandeira aqui:

• • O armazenamento do NFS era feito com backup fino (no nível da matriz). Isso significa que, embora por exemplo. 200 GB são apresentados aos hosts ESXi; na verdade, apenas 100 GB estão disponíveis. Somente a matriz possui esse conhecimento no entanto. O que descobrimos foi que várias VMs foram pausadas porque estavam sem espaço em disco. Embora essa tenha 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 em pausa foram reiniciadas com êxito, retornamos ao problema original. Montamos os discos virtuais das VMs quebradas em uma VM em funcionamento e vimos que não havia tabela de partição nos discos. Como não havia um visualizador hexadecimal disponível, assumimos que os discos estavam vazios.

• O sistema de monitoramento alertou para uma nova VM que simplesmente não respondeu. Isso foi ótimo, como uma carga de VMs teve minutos antes de ficar sem resposta devido ao problema de espaço em disco; portanto, o fato de essa nova VM ter sido encontrada rapidamente era um sinal de boa administração de monitoramento.

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

• • Nesta fase, fui à sala de bate-papo de falhas do servidor para ver se o programa podia ser identificado, enquanto meu colega de armazenamento verificou todos os logs e eventos da camada virtual, para garantir que não houvesse operação de armazenamento em execução em nossa área.
• O que deveríamos ter feito foi suspender a VM, permitir que o arquivo de suspensão fosse gravado e analisar o despejo para ver se o programa em execução poderia ser identificado. Suspender a VM para o núcleo do PDF VMware KB

No final do dia, sabíamos que as ferramentas de infraestrutura virtual não teriam sido relatadas em um convidado como o descrito acima. Vimos que não havia ISO montado nem eventos registrados na VM. Pudemos ver que a VM não era "hard power cycled", apenas uma reinicialização suave (isso é invisível para a infraestrutura subjacente). Nós sabíamos que não era o lado do armazenamento, porque já tínhamos descartado isso. Suspeitamos que não fosse automatizado, pois acontecia 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 :)

Portanto, 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:

• Faça backup e teste suas restaurações
• Certifique-se de que todos os usuários, em particular os usuários administrativos, saibam que estão trabalhando em um ambiente thin provisioned e evite algo como formatação de disco de gravação (por exemplo, cargas de gravação de 1)
• Tenha um bom sistema de monitoramento em vigor.
• E um novo para mim: em qualquer ambiente virtual grande, tenha uma ferramenta pronta para VM, mesmo desligada, com ferramentas de diagnóstico instaladas; desempenho, armazenamento em rede. Se isso estivesse disponível, poderíamos ter montado e realizado um despejo hexadecimal no disco danificado para ver se ele estava realmente vazio ou apenas faltando um mbr. Também poderíamos ter visto se estava escrito com 1's.

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

Este artigo pode ajudá-lo a: Limpar questões de disco virtual com economia de espaço