未知のツールが仮想マシンをワイプしており、識別できません

vSphere上のWindows 2008 R2 VMのコンソールビューには、次の画面が表示されます。

「操作2/2」「ディスクのワイピング」

誰かがこのプログラムが何であるかについてアドバイスできますか？

この謎に関するいくつかの情報：

多くのVMが影響を受けています。症状は、再起動後に「OS not found」メッセージが表示されることです。

• VMはESXiで実行されています。VMは特定のデータストアで実行されています
• Netapp NFS作業ボックスにディスクをマウントすると、パーティションテーブルが表示されず、まだ16進ダンプができません
• VMはハードリセットではなく、OSによって開始されたソフトリセットである必要があります
• マウントされたisoはありませんVMへの「非ゲスト」アクセスはなかったので、RDPまたは類似のものである必要があります。
• バックアップは、netappバックアップソフトウェアを使用して一晩実行されます
• 問題のNFSはバックエンド（アレイレベル）でシンプロビジョニングされており、これらの問題を確認した直後にスペースが不足しました。

残念ながら、私たちはアプリケーションが何であるかを最下位に到達できないように見えますが、このインシデントから何らかの価値を得るために、参照の回答を作成したいと思いました。これはVMwareおよび仮想レイヤー管理中心です。多くの管理者が隔離されており、ゲストやストレージにすばやくアクセスできません。これは彼らのためです:)

http://support.seagate.com/kbimg/flash/laptop/Laptop.swfは、@ MosheKatzが見つけた実際のアプリケーションに最も近いようです。

これが将来発生した場合、調査は次のようになります。

• すべてのVMがクラッシュしているわけではありませんが、一部に気づきます。これはストレージの問題が原因であると思われます（通常は最も可能性の高い原因であるため）
• まず、共通の要因を特定してください。クラッシュしたVMはすべて同じデータストアを共有していますか？この場合は問題ありませんでしたが、一部のマシンは大丈夫だったため、ハードウェアの明らかな問題を除外しました。
• 破損したすべてのVMをチェックして、共通の要因（時間、機能など）があったかどうかを確認します。この場合はありませんでした。

• 他の異常なイベントを確認してください。何かがここでフラグを立てました：

• • NFSストレージはシンアレイされました（アレイレベル）。これは、たとえば ESXiホストには200GBが提示されますが、実際には100GBしか使用できません。ただし、配列のみがこの知識を持っています。私たちが見つけたのは、多くのVMがディスク領域を使い果たしたため一時停止したことです。これが根本的な原因であった可能性があるため、最初のアクションはバックエンドにより多くのストレージを割り当て、これを問題として取り除くことでした。

• これが解決され（単純なUIの変更）、一時停止されたVMが正常に再起動されると、元の問題に戻りました。壊れたVMから動作中のVMに仮想ディスクをマウントしましたが、ディスク上にパーティションテーブルがないことがわかりました。使用可能な16進ビューアがなかったため、ディスクが空であると仮定する必要がありました。

• 監視システムは、応答しなくなったばかりの新しいVMに警告しました。これは素晴らしく、ディスク容量の問題によりVMの負荷が応答しなくなる数分前にあったため、この新しいVMがすぐに検出されたという事実は、適切な監視管理の兆候でした。

• コンソールを開いてゲストを確認すると、上記のスクリーングラブが表示されました。

• • この段階で、サーバーフォールトチャットルームに行ってプログラムを特定できるかどうかを確認し、ストレージの同僚がすべての仮想層のログとイベントをチェックして、その地域でストレージ操作が実行されていないことを確認しました。
• VMをサスペンドし、サスペンドファイルが書き出されるようにし、ダンプを分析して、実行中のプログラムを識別できるかどうかを確認します。コアPDF VMware KB へのVMの一時停止

結局のところ、上記のようにゲスト内で仮想インフラストラクチャツールが報告されないことはわかっていました。ISOがマウントされておらず、VMに対してイベントが記録されていないことがわかりました。VMは「ハードパワーサイクル」ではなく、ソフトリスタートのみであることがわかりました（これは、基盤となるインフラストラクチャからは見えません）。私たちはすでにそれを除外していたので、それがストレージ側ではないことを知っていました。特定のVMで数時間かけて行われたため、自動化されていないと思われます。コンソールがディスクワイプを報告する理由は悪意ではないと推測しました:)

したがって、結論はユーザーが開始したディスクワイプでした。それは私の調査が行った限りですが、あなたがそれが有用であるとわかったことを望みます。

教訓：

• 復元のバックアップとテスト
• すべてのユーザー、詳細管理ユーザーが、シンプロビジョニング環境で作業していることを確認し、書き込みディスクのフォーマット（1の書き込み負荷など）を避ける必要があります。
• 適切な監視システムを設置してください。
• 私にとって新しいもの：大規模な仮想環境では、診断ツールがインストールされた状態で、ツールVMの準備ができており、電源がオフになっている場合もあります。パフォーマンス、ネットワークストレージ。これが利用可能な場合、損傷したディスクに16進ダンプをマウントして実行し、実際に空であるか、単にmbrがないかを確認できます。また、1で書き出されているかどうかも確認できました。

あなたの問題はVMwareの標準的なスペース再生機能だと思います。

この記事はあなたを助けるかもしれません：Space-Efficient Virtual Diskの質問をクリアする