不明なツールが仮想マシンをワイプしていて、IDを特定できません
VSphere上のWindows2008 R2 VMのコンソールビューには、次の画面が表示されます。
「操作2/2」「ワイピングディスク」
誰かがこのプログラムが何であるかについてアドバイスできますか？
この謎に関するいくつかの情報：
現在、多くのVMが影響を受けています。症状は、再起動後に「OSが見つかりません」というメッセージが表示された後です。
- VMはESXiで実行されています。 VMは特定のデータストアで実行されています
- Netapp NFS作業ボックスにディスクをマウントすると、パーティションテーブルが表示されず、まだ16進ダンプできません。
- VMはハードリセットではなく、OSが開始するソフトリセットである必要があります
- ISOがマウントされていませんVMへの「非ゲスト」アクセスがなかったため、RDPまたは同様のものである必要があります
- バックアップは、netappバックアップソフトウェアを使用して一晩実行されます
- 問題のNFSは、バックエンド（アレイレベル）でシンプロビジョニングされており、これらの問題が発生した直後にスペースが不足しました。
残念ながら、アプリケーションの概要がわからないようですが、このインシデントからsomeの値を取得するために、参照を作成したいと思いました。回答。これは、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の負荷が数分前に応答しなくなったため、すばらしいことでした。 new VMがすぐに見つかりましたが、これは適切な監視管理の兆候でした。
コンソールを開いてゲストを確認すると、上のスクリーンショットが表示されました。
- この段階で、サーバー障害チャットルームに行き、プログラムを特定できるかどうかを確認しました。ストレージの同僚は、すべての仮想レイヤーのログとイベントをチェックして、自分のエリアからストレージ操作が実行されていないことを確認しました。
- VMを一時停止し、一時停止ファイルが書き出されるようにし、ダンプを分析して、実行中のプログラムを識別できるかどうかを確認する必要がありました。 サスペンドVMコアPDFへVMware KB
結局のところ、上記のように仮想インフラストラクチャツールがゲスト内で報告することはなかったでしょう。 ISOがマウントされておらず、VMに対してイベントがログに記録されていないことがわかりました。 VMは「ハードパワーサイクル」ではなく、ソフトリスタートのみでした（これは基盤となるインフラストラクチャには表示されません）。除外したため、ストレージ側ではないことがわかりました。すでに。特定のVMで数時間にわたって発生していたため、自動化されていなかったと思われます。コンソールがディスクワイプを報告するのは、悪意のあるものではないと推測しました:)
したがって、結論はユーザーが開始したディスクワイプでした。私の調査ではそれだけですが、お役に立てば幸いです。
学んだ教訓：
- 復元をバックアップしてテストする
- すべてのユーザー、特に管理者ユーザーが、シンプロビジョニングされた環境で作業していることを確認し、ディスクの書き込みフォーマット（つまり、1の書き込み負荷）などを回避する必要があります。
- 適切な監視システムを用意します。
- そして私にとって新しいもの：どんな大規模な仮想環境でも、ツールVM準備ができていて、電源がオフで、診断ツールがインストールされている、パフォーマンス、ネットワークストレージがあります。これが利用可能であれば、マウントできたはずです。損傷したディスクに対して16進ダンプを実行して、ディスクが本当に空であるか、または単にmbrが欠落しているかを確認しました。また、1で書き出されているかどうかも確認できました。