Hyper-V 2012 R2仮想マシン上のINACCESSIBLE_BOOT_DEVICE
Hyper-V 2012 R2クラスター、4つのDell PowerEdge R620サーバーがFC接続を介してDell PowerVault MD3600Fストレージアレイに接続されています。すべてが非常に簡単です。すべてのサーバーがWS2012R2を実行し、クラスターは数か月前に新しく構築されました。すべてのドライバーとファームウェアは最新であり、Windowsは利用可能な最新のパッチに更新されています（2日前にリリースされたものでも）。全体を管理するSCVMM 2012 R2サーバーもありますが、これは当面の問題には実際には重要ではないようです。
このクラスターではいくつかのVMが実行されています。それらの一部は、Windows Server 2008 R2を実行する第1世代のVMですが、それらのほとんどは、Windows Server 2012 R2を実行する第2世代のVMです。これらにも、利用可能な最新のアップデートが含まれています。これらは実際にはクラスターのすぐ後に作成されたテンプレートからデプロイされており、Microsoftが新しいパッチをリリースするときに定期的に更新されます。
すべてがかなりうまく機能しますが、（つまり、識別できる理由や原因がない場合）a VMは起動に失敗し、恐ろしいINACCESSIBLE_BOOT_DEVICEエラーコードでクラッシュします。これは起動時にのみ発生します（または再起動）：いいえVM=実行中にクラッシュしました。
これが発生するたびに、障害のあるVMを再度起動する方法はありません。これは、2週間前にVMまだ本番ワークロード（新しく導入されたもの）で、それを機能させるために非常に急いでいたため、単純にスクラッチして新しいものを導入しましたが、問題の根本的な原因は見つかりませんでした。
その後、2日前に、パッチを適用した後に複数のVMを再起動したときに、再び発生しました。それらの3つは回復しませんでしたが、他のいくつかは問題なく起動しました。
障害のあるVMは、セーフモードでも起動できません。ただし、（システム自体から、つまりWindows DVDからではなく、ローカル（仮想）ディスクから、つまり仮想ディスクに実際にアクセスできることを意味して）Windows回復環境を起動すると、すべてが問題ないように見えます。ブートマネージャは正しくリストします。ブートするシステム（bcdedit /enum all /vの出力は実際には動作中のVMの出力と同じです）、すべてのボリュームにアクセスでき、chkdskでもエラーはまったく表示されません。唯一の異常は、bootrec /scanosまたはbootrec /rebuildbcdを実行しているときに、ツールがWindowsインストールを検出できないことを示しています（C：ボリュームは存在し、完全に読み取り可能です）。
これは（少なくとも今のところ）WS2012R2ジェネレーション2 VMでのみ発生したため、EFIエミュレーションやEFIブートローダーの問題が原因であると想定しています。ただし、これは私の側の仮定にすぎません。
私が更新について言及した理由は、私は これは以前に起こった を知っているためであり、- KB2919355 がそれを担当しました。また、Microsoftは最近、別のメガアップデート KB300085 をリリースしました。これは、ホスト、仮想マシン、およびWS2012R2テンプレートの両方にも適用されました。
（偶然にも、この更新プログラムがリリースされた翌日、MicrosoftはAzureクラウドプラットフォーム全体の世界的なクラッシュを経験しました。これは、私たちのクラスターに起こっていることといくつかの印象的な類似点があります。しかし、私はここで推測しているだけです）。
マイクロソフトで既にサポートケースを開いていますが、ここにも投稿しています。もちろん、マイクロソフトがソリューションを提供している場合は、VMがオンラインに戻ったらすぐに投稿します。
私たちは問題をMicrosoft Premier Supportにエスカレートし、カーネルデバッグスペシャリストに対応してもらいました。彼は何かがゲストVMからすべてのHyper-Vドライバーをアンインストールし、完全に起動できなくなったことを発見しました。彼は、ファイルシステムとVMのレジストリにドライバーを手動で挿入することで、そのうちの1つを起動させることができ、いくつかの重要なデータ（証明機関でした）を取得することができました。ただし、VMは完全にサポートされていない状態になっていたため、再構築することにしました。重要なデータが存在しない他のすべてのVMも再構築しました。
whatが実際にドライバーのアンインストールを引き起こしたのは、ケースがまだ開いており、原因はまだ見つかっていません。問題は、使用したテンプレートに潜在していました。それは、そのテンプレートを使用してデプロイされたすべてのVMにすぐに影響を与えるためです。別のテンプレートを作成しましたが、このテンプレートは同じ問題を示していなかったので、問題なく動作しています...しかし、そもそも何が問題の原因であるのかはまだわかりません。
更新：
しばらくすると、[〜＃〜]最終的に[〜＃〜]が何が起こったかを見つけました（以前にこの回答を更新するのを忘れていました）。
誰かまたは何かがベーステンプレートのHyper-V統合サービスを強制的に更新したようです。これは、すでにそれらを持っている、まったく同じOSに基づいています。ホストの解放。これにより、ゲストシステムで潜在的な問題が発生しました。これらのドライバーは重複している、または置き換えられているため、削除する必要があります。ただし、このイベントは、Windowsが定期的な自動クリーンアッププロセスを実行するときに、可変時間間隔の後にのみトリガーされます。これにより、最終的に各テンプレートのすべてのHyper-Vドライバーが完全にアンインストールされ、VMがそのテンプレートからインスタンス化され、完全に起動できなくなりました。
誰がまたは何がこの更新を実行したか（Integration Servicesセットアップディスクを挿入してセットアップを実行することはできません。これは、インストーラーが既にインストールされていることを正しく検出して終了するためです）、私たちは手がかりがありません。よりよく知っているはずの誰かが手動で PowerShell または [〜＃〜] dism [〜＃〜] を使用して実行したか、SCVMMが原因でした。