Неизвестный инструмент стирает наши виртуальные машины, и мы не можем его идентифицировать

К сожалению, похоже, что мы не можем разобраться в том, чем было приложение, но чтобы получить некоторые ценности этого инцидента, я хотел создать справочный ответ. Это VMware и управление виртуальным уровнем. Многие администраторы изолированы и не могут быстро получить гостевой доступ или доступ к хранилищу, и это для них :)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swf похоже, наиболее близко соответствует реальному приложению, которое обнаружил @MosheKatz.

Если это произошло в будущем, расследование должно быть таким:

• Вы заметили, что некоторые, но не все виртуальные машины вышли из строя. Вы подозреваете, что это связано с проблемой хранения (как правило, это наиболее вероятная причина)
• Сначала попробуйте выделить общий фактор. Все ли разбитые виртуальные машины используют одно и то же хранилище данных? В этом случае они были, но некоторые Машины были в порядке, поэтому мы исключили очевидные проблемы с оборудованием.
• Проверьте все сломанные виртуальные машины, чтобы узнать, есть ли общий фактор (время, функция и т. Д.). В этом случае не было.

• Проверьте наличие других необычных событий. Что-то тут подняло флаг:

• • Хранилище NFS было тонким (на уровне массива). Это означает, что хотя например. Хостам ESXi предоставляется 200 ГБ, фактически доступно только 100 ГБ. Однако это знание есть только у массива. Мы обнаружили, что несколько виртуальных машин были приостановлены из-за нехватки места на диске. Мы думали, что это могло быть основной причиной, поэтому наше первое действие заключалось в выделении большего объема памяти на серверной части, чтобы устранить это как проблему.

• После того как проблема была решена (простое изменение пользовательского интерфейса) и приостановленные виртуальные машины успешно перезапустились, мы вернулись к исходной проблеме. Мы смонтировали виртуальные диски со сломанных ВМ на работающую ВМ и увидели, что на дисках нет таблицы разделов. У нас не было доступной шестнадцатеричной программы просмотра, поэтому пришлось предположить, что диски теперь пусты.

• Система мониторинга предупредила о новой виртуальной машине, которая просто перестала отвечать. Это было здорово, так как загрузка виртуальных машин за несколько минут до этого просто перестала отвечать из-за проблем с дисковым пространством, поэтому тот факт, что эта новая виртуальная машина была обнаружена быстро, был признаком хорошего администрирования мониторинга.

• Мы открыли консоль, проверили гостя и увидели снимок экрана.

• • На этом этапе я пошел в чат-комнату сбоя сервера, чтобы узнать, можно ли идентифицировать программу, в то время как мой коллега по хранилищу проверил все журналы и события виртуального уровня, чтобы убедиться, что из нашей области не выполняются операции с хранилищем.
• Что мы должны были сделать, так это приостановить виртуальную машину, разрешить запись приостановленного файла и проанализировать дамп, чтобы увидеть, можно ли идентифицировать запущенную программу. Приостановить ВМ до основного PDF КБ VMware

В конце концов, мы знали, что инструменты виртуальной инфраструктуры не сообщали бы о гостевой системе, как это делалось выше. Мы могли видеть, что ISO не был смонтирован, и не было зарегистрировано никаких событий для виртуальной машины. Мы могли видеть, что виртуальная машина не была "жестко выключена и снова выключена", а была только мягкая перезагрузка (это невидимо для базовой инфраструктуры). Мы знали, что это не хранилище, поскольку уже исключили это. Мы подозревали, что это не было автоматизировано, поскольку это происходило в течение нескольких часов на определенных виртуальных машинах. Мы догадались, что это не было злонамеренным: почему консоль сообщила об очистке диска, если это было :)

Итак, вывод был инициирован пользователем. Это мое расследование, но я надеюсь, что оно было вам полезно.

Уроки выучены:

• Сделайте резервную копию и проверьте свои восстановления
• Убедитесь, что все пользователи, в частности, администраторы, знают, что они работают в среде с тонкой подготовкой, и должны избегать чего-либо вроде форматирования диска при записи (т.е.
• Создайте хорошую систему мониторинга.
• И новый для меня: в любой большой виртуальной среде иметь готовую инструментальную виртуальную машину, даже выключенную, с установленными средствами диагностики; производительность, сетевое хранилище. Если бы это было доступно, мы могли бы смонтировать и выполнить шестнадцатеричный дамп поврежденного диска, чтобы увидеть, действительно ли он пуст или просто отсутствует mbr. Мы также могли видеть, было ли оно написано с помощью единиц.

Я думаю, что ваша проблема - стандартная функция восстановления пространства VMware.

Эта статья может помочь вам: Отвечая на вопросы об экономном виртуальном диске