2026年、AMD EPYC上のWindows Server 2025仮想マシンが起動しない場合の対処法

【適する】Windows Server 2025仮想マシンの起動障害は、AMD EPYCやPVE 9.2を原因と決めつけず、仮想マシンとホストの復旧可能な状態を確保してから、設定を一つずつ確認してください。
本番環境では、クローンまたは保守時間内で再現と切り戻しを検証し、唯一の稼働個体に不可逆な変更を加えない進め方が適しています。

Proxmox VE上でWindows Server 2025を運用し、起動ループや回復エラーが出ている管理者向けです。
PVE 9.2への更新を予定しているチームは、テスト手順と復旧経路を事前に用意してください。複数のWindows仮想マシンを独占型AMD物理サーバーで動かす担当者は、最後の受け入れ確認にも活用できます。

最終更新：2026年10月27日。Proxmox VE 9.2の公式発表、現行管理ガイド、MicrosoftのWindows Server 2025ハードウェア要件を確認しています。 Proxmox VE 9.2の公式発表では、2026年5月21日の公開と、既定カーネルやQEMUなどの更新が案内されています。更新後に起きた個別の起動障害報告は、共通原因が確認された証拠ではありません。

更新前後の記録と復旧点

まず、問題が発生した時点の状態を記録します。PVE 9.2のリリース後にWindows Server 2025の起動不具合を報告する投稿はありますが、いずれも利用環境に依存する個別事例です。Proxmoxコミュニティの報告や関連するReddit上の議論を、すべてのAMD EPYC環境に当てはまる因果関係として扱わないでください。

更新を予定している場合は、変更前の情報を控え、戻せるバックアップがあることを実際に確かめます。仮想マシンの設定だけでなく、稼働中のホストカーネルや更新履歴も記録すると、変更後に比較しやすくなります。

PVE 9.2の更新前に何を試せばよいですか。 本番機に適用する前に、クローンまたは同等の検証環境で更新と再起動を実施し、Windowsの起動、主要サービス、再起動後の状態を確認します。バックアップが存在するだけでなく、復元手順を実行できることまで確かめてください。

バックアップや復元演習の設計を見直す場合は、Proxmox環境のバックアップと復旧に関する記事も確認できます。リンク先ではWindows Serverのライセンス確認を扱っているため、バックアップ手順そのものと混同せず、ライセンス要件の整理に使ってください。

障害の発生層と更新履歴

管理画面に入れない、仮想マシンが起動しない、Windowsの回復画面が表示される、という状態は別の層で起きています。ホストにSSH接続できるか、同じホスト上の他の仮想マシンが稼働しているかを先に確認し、問題がホスト側かゲスト側かを切り分けます。

ホストから情報を採取する場合は、状況を変える操作ではなく、読み取り中心の確認から始めます。次のコマンドはPVEの状態と仮想マシン設定を控える例です。Proxmox VE管理ガイドで対象バージョンに合う管理方法も確認してください。

pveversion -v
qm config <VMID>
journalctl -b -p err

出力を保存するときは、障害発生後の状態だけでなく、更新前の記録と並べて差分を確認します。設定変更やカーネル切り替えを、この情報採取の段階で試す必要はありません。

起動ファームウェアと仮想ディスク

Windows Server 2025の起動ループがAMD EPYC上で起きても、CPUが原因とは限りません。まず、起動方式、起動順、Windowsをインストールしたときの仮想ディスク接続方式が保たれているかを、既存設定と照合します。

回復環境でディスクが見えれば、コントローラーに問題はありませんか。 いいえ。ディスクが表示されることは調査の手がかりですが、適切なドライバーが起動時に読み込まれていることや、ストレージ全体が正常であることまでは証明しません。

Windows側のエラーを調べる際は、MicrosoftのWinREを使った起動障害の診断手順を参照し、表示内容を記録します。インストール後にストレージ方式を変えた記憶がある場合も、まずクローンで元の構成との違いを検証してください。

CPUタイプとホスト更新の分離

次に、仮想マシンに設定されたCPUタイプと、ホストの現在および直前のカーネルを確認します。コミュニティにはPVE 9.2やLinux 7.0の更新後に起動できなくなったという投稿がありますが、現時点で、AMD EPYCが共通原因だと確認されたわけではありません。

AMD EPYC上の起動ループには、CPUタイプの変更が有効ですか。 全環境に適用できる修正とは言えません。変更を試す場合は、クローン上でCPUタイプだけを変え、同一条件で起動結果を比較します。カーネルの切り替えを試す場合も、別の変更を同時に行わず、戻す手順を先に用意してください。

Windows Server 2025の最小ハードウェア要件には、64ビットCPU、最小1.4GHz、メモリ512MB、ストレージ32GBなどの基準が示されています。ただし、これらは最小要件であり、仮想マシンの実運用に必要な割り当て量や、起動障害の原因を判定する基準ではありません。MicrosoftのWindows Serverハードウェア要件を参照し、実際の割り当ては用途とライセンス条件に合わせて設計してください。

Windows Server 2025仮想マシンの障害を、ファームウェアとディスク方式のどちらから調べますか。 起動順とファームウェアが記録どおりかを先に見てから、ディスクが認識されるか、接続方式がインストール時と一致するかを確認します。変更は一項目ずつにし、起動段階とエラー表示がどう変化したかを記録します。

保守時間内の復旧判断と受け入れ確認

以下の条件分岐で、次の作業を決めます。いずれの場合も、本番環境ではバックアップと切り戻しの責任者を決め、停止条件を共有してから着手してください。

• 更新前の構成とバックアップが記録され、クローンで同じ障害を再現できる場合：変更候補を一つだけ選んで検証し、結果を更新前の状態と比較します。
• 特定の変更を加えた直後に障害が始まり、クローンでその差が再現する場合：その変更を戻す候補として扱い、復旧後にWindowsとホストの状態を再確認します。
• 複数の設定や更新が同時に変わり、原因を分けられない場合：CPUタイプ、カーネル、ファームウェア、ディスク方式をまとめて変えず、追加の変更を止めてログと設定差分を集めます。
• 検証済みバックアップや切り戻し手順がない場合：本番VMの変更を続けず、復旧手段を準備してから保守時間を取り直します。

修復後は、Windowsの通常起動、仮想デバイスの認識、必要なサービスの稼働、再起動後の安定性を確認します。WinREで一度起動できたことだけを復旧完了の判定にせず、作業者、変更内容、結果、切り戻しの有無を記録してください。

複数VMを計画する場合も、一台が起動したことだけから搭載可能台数を推定できません。対象の業務負荷、CPUとメモリの割り当て、Windows Serverのライセンス、バックアップと復元の責任分担を別々に見積もります。ストレージとメモリの検討には、サーバーのメモリ・ディスク構成の案内も参考になります。ライセンス条件は利用形態により異なるため、Windows Serverのライセンス確認ガイドで要件を整理してください。

共有型のクラウド環境でCPUの競合が起きる、CPUの割り当てが事業者側の管理下にある、帯域や転送量の費用が読みづらい、ディスクやOSを用途に合わせて選びにくい、といった制約が実際にあるなら、独占型AMD物理サーバーをホストとして使う選択肢があります。一方、短時間だけ使う環境や負荷の軽いVMには、共有型のほうが適する場合もあります。安定した仮想化基盤を継続運用するなら、OSFP Cloudの現在の製品情報で選べるOSとリソース条件を確認し、必要な要件が合う場合に限って移行を検討してください。