Una herramienta desconocida está limpiando nuestras máquinas virtuales y no podemos identificarla

Una vista de consola de una máquina virtual Windows 2008 R2 en vSphere muestra la siguiente pantalla:

"Operación 2 de 2" "Limpiar disco"

¿Alguien puede aconsejar sobre qué es este programa?

Alguna información sobre este misterio:

Varias máquinas virtuales ahora se ven afectadas. El síntoma es después de que aparece el mensaje de reinicio "SO no encontrado".

• Las máquinas virtuales se ejecutan en ESXi. Las máquinas virtuales se ejecutan en un almacén de datos particular
• Netapp NFS Montar el disco en un cuadro de trabajo no muestra una tabla de particiones, aún no ha podido realizar un volcado hexadecimal.
• La máquina virtual no se restableció por completo, tendría que ser un restablecimiento parcial iniciado por el sistema operativo
• No hay montaje iso No había acceso "no invitado" a la VM, por lo que necesitaría ser RDP o similar
• Las copias de seguridad se realizan utilizando el software de copia de seguridad netapp durante la noche
• NFS en cuestión tiene un aprovisionamiento delgado en el back-end (nivel de matriz) y se quedó sin espacio justo después de que vimos estos problemas.

Desafortunadamente, parece que no podemos llegar al fondo de lo que era la aplicación, pero para obtener algún valor de este incidente, quería crear una respuesta de referencia. Esto es VMware y la gestión de capa virtual centrada. Muchos administradores están segregados y no pueden obtener acceso de invitado o almacenamiento rápidamente, y esto es para ellos :)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swf parece ser la coincidencia más cercana a una aplicación real, que encontró @MosheKatz.

Si esto sucediera en el futuro, la investigación debería ser la siguiente:

• Observa que algunas, pero no todas, las máquinas virtuales se han bloqueado. Sospecha que esto se debe a un problema de almacenamiento (ya que generalmente es la causa más probable)
• Primero intente aislar un factor común. ¿Todas las máquinas virtuales bloqueadas comparten el mismo almacén de datos? En este caso lo eran, pero algunas máquinas estaban bien, por lo que descartamos problemas obvios de hardware.
• Verifique todas las máquinas virtuales rotas para ver si hubo un factor común (tiempo, función, etc.). En este caso no lo hubo.

• Verifique otros eventos inusuales. Algo levantó una bandera aquí:

• • El almacenamiento NFS tenía respaldo delgado (en el nivel de matriz). Esto significa que aunque, por ejemplo. Se presentan 200 GB a los hosts ESXi, de hecho, solo 100 GB están disponibles. Sin embargo, solo la matriz tiene este conocimiento. Lo que encontramos fue que varias máquinas virtuales se detuvieron porque se habían quedado sin espacio en disco. Pensamos que esta podría haber sido la causa raíz, por lo que nuestra primera acción fue asignar más almacenamiento en la parte posterior, para eliminar esto como un problema.

• Una vez que esto se resolvió (un simple cambio de interfaz de usuario) y las máquinas virtuales en pausa se reiniciaron con éxito, volvimos al problema original. Montamos los discos virtuales de las máquinas virtuales rotas en una máquina virtual que funcionaba y vimos que no había una tabla de particiones en los discos. No teníamos un visor hexadecimal disponible, así que tuve que asumir que los discos ahora estaban vacíos.

• El sistema de monitoreo alertó a una nueva VM que simplemente no respondió. Esto fue genial, ya que una carga de VM tenía minutos antes de dejar de responder debido al problema de espacio en disco, por lo que el hecho de que esta nueva VM se encontró rápidamente fue una señal de una buena administración de monitoreo.

• Abrimos una consola y revisamos al invitado, y vimos la captura de pantalla anterior.

• • En esta etapa, fui a la sala de chat de fallas del servidor para ver si se podía identificar el programa, mientras que mi colega de almacenamiento revisó todos los registros y eventos de la capa virtual, para asegurarme de que no se ejecutara ninguna operación de almacenamiento desde nuestra área.
• Lo que deberíamos haber hecho fue suspender la máquina virtual, permitir que el archivo de suspensión se escriba y analizar el volcado para ver si se puede identificar el programa en ejecución. Suspender VM a PDF central VMware KB

Al final del día, sabíamos que las herramientas de infraestructura virtual no habrían informado dentro de un invitado como lo estaba haciendo anteriormente. Pudimos ver que no había ISO montado, y no se registraron eventos en la VM. Pudimos ver que la VM no fue "un ciclo de energía dura", solo un reinicio suave (esto es invisible para la infraestructura subyacente). Sabíamos que no era el almacenamiento, ya que ya lo habíamos descartado. Sospechamos que no estaba automatizado, ya que sucedía en el transcurso de unas horas en máquinas virtuales específicas. Supusimos que no era malicioso, ¿por qué la consola informaría sobre Disk Wipe si fuera :)

Entonces, la conclusión fue un borrado de disco iniciado por el usuario. Hasta aquí llegó mi investigación, pero espero que les haya resultado útil.

Lecciones aprendidas:

• Copia de seguridad y prueba tus restauraciones
• Asegúrese de que todos los usuarios, en particular los usuarios administradores, sepan que están trabajando en un entorno de aprovisionamiento delgado y que deben evitar algo como el formato de disco de escritura (es decir, escribir cargas de 1's
• Tener un buen sistema de monitoreo en su lugar.
• Y una nueva para mí: en cualquier entorno virtual grande, tenga una VM lista para herramientas, incluso apagada, con herramientas de diagnóstico instaladas; rendimiento, almacenamiento en red. Si esto estuviera disponible, podríamos haber montado y realizado un volcado hexadecimal en el disco dañado para ver si realmente estaba vacío, o simplemente faltaba un mbr. También podríamos haber visto si fue escrito con 1's.

Creo que su problema es una característica estándar de recuperación de espacio de VMware.

Este artículo puede ayudarte: Cómo resolver preguntas sobre el disco virtual con espacio reducido