概要
タイトルどおり。デュアルブート中 の Windows 11 Pro で シャットダウンがおわらず困った。
この記事の結論としては、身もふたもないが「ホストOS再起動」です。
原因的には、Hyper-V統合サービスであるShutdown が誤ったハードウェア構成あるいは仮想マシンの設定によって妨げられていることです ( 「仮想ハードウェア構成のキーファクター」の表を参照 )。統合サービスのShutdown や Backup が失敗すると、「正常稼働中」という Status 表示が狂ってしまう (意図した通りに Status が表示されない)ようです。( 飽くまでChatGptを使用した 筆者の推測です )
以下、ChatGPT を一部使用して書いています。
<このように書いてある場合、<>内の記事は ChatGPTをあらわします>
本編
まず以下の確認 (Powershell)
Status が停止っぽいやつになるはずだが、なっていない
Get-VM -Name "<VM名>" | Select-Object Name, State, Status
-
State は “Off” ( GUI の Hyper-V マネージャー 側も VM の [状態] はオフ )
-
なのに Status は「正常稼働中」
Microsofへの 悪口 : Status とStateの違いェ...
Microsoft、何を考えているんだ...
いつも思うんだが、Microsoftの技術っていじめか？というほど、何考えてこんな複雑なもの生み出しているのか、理解に苦しむ。たぶんめっちゃ頭いい人たちが作っているんだろうな。スペックが私低すぎて付いていけません。
Microsoftへの悪口が毎度過ぎますが Copilot ( ChatGpt ) にきいてみた
Q1. Hyper -V のVM State と Status は何が違うのか？この差って Microsoft のVM 特有の事象ですか？
A. Hyper-V における 「State」 と 「Status」 は、似ているようで異なる意味を持つ重要な指標です。
「State」とは？
VM の現在の動作状態を示します。これは Hyper-V マネージャーや PowerShell の Get-VM コマンドで確認できます。「Status」とは？
VM の状態に関する補足情報やエラーの有無を示します。GUI 上では「状態」欄に表示されることもありますが、PowerShell では Get-VM の Status プロパティで確認できます。Microsoft 特有の概念？
はい、これは Hyper-V 固有の設計です。他の仮想化プラットフォーム（例：VMware ESXi）では似たような概念はありますが、用語や扱い方が異なります。Hyper-V は Windows OS と密接に統合されているため、統合サービスや PowerShell との連携が強みであり、それが「Status」のような詳細な状態表示につながっています。
Q2. State ともう一つのStatus 、似ている状態ごとに整理して比較表にしてｋださい。
A. Hyper-V の 「State」 と 「Status」 は紛らわしく感じることもありますが、役割がしっかり分かれていて、監視や自動化を行う際に見分けて使うのが重要です。以下に よく似た状態ごとに整理して比較表 を作成しました：
下記表の内容は ChatGPT
🧮 Hyper-V 「State」 vs 「Status」 比較表
| 状態カテゴリ | State（動作状態） | Status（補足状態／健全性） | 補足説明 |
|---|---|---|---|
| ✅ 正常稼働中 | Running | Operating normally | OS が稼働し、統合サービスも正常 |
| 🔄 起動・停止中 | Starting / Stopping | No status または Transitioning | 状態移行中。Status は空白の場合あり |
| ⏸️ 一時停止／保存中 | Paused / Saved | No status または Waiting for resources | メモリ不足や手動操作による一時停止 |
| 🧩 非応答・障害 | Running | Unresponsive / Integration services not running | 仮想マシン自体は稼働しているが、OS側が応答なし／統合サービスに問題あり |
| ⚠️ 構成エラー | Off / Critical | Configuration error / Unsupported configuration | 設定ミスや互換性のない仮想ハードウェア構成 |
| 🔁 移行・バックアップ | Running または Saving | Backing up / Migration in progress | ライブマイグレーションやバックアップ処理中 |
📌 ポイントまとめ
- 「State」は基本的に VM の電源状態や動作ステータス
- 「Status」はその裏で起きている 補足的なプロセスやエラー状況
- 同じ「State」でも、「Status」が異なることで健康状態や問題の有無が一目で分かる
(筆者的) ここまでのまとめ
※ [私は ロボット ではありません。]
- 今の状態をまとめると、「OS が稼働し、統合サービスも正常に稼働している。が、設定ミスや互換性のない仮想ハードウェア構成があるかもしれない」です。
っつーわけで、設定や仮想ハードウェア構成を復習がてら見直してみます。やってやろうじゃないの、Microsoft に頭を洗脳させます。どんとこい。
以下、Microsoft エンジニアが書きそうな (※) Intelligent な文体にチェーンジ。
※勝手なイメージです。Microsoft Lovers は読まないでね♡ (WSLは好きです)
設定、仮想ハードウェア構成 の見直し
まず、何の設定が Microsoft VM アーキテクチャにとって重要かを定義することから始めます。
Microsoft 仮想化技術 において、重要なキーファクターは以下の要素に分けられます：
下記、Copilot
仮想ハードウェア構成のキーファクター
| カテゴリ | 要素 | 重要性の理由 |
|---|---|---|
| CPU | 仮想プロセッサ数 / NUMA構成 | VMのパフォーマンスと互換性に直結。NUMAの誤設定は起動失敗の原因にも |
| メモリ | 動的メモリ / 固定メモリ / 最小・最大値 | メモリ不足による Paused 状態や統合サービスの不具合を防ぐ |
| ストレージ | 仮想ディスクの種類（VHD/VHDX） / 接続方式（IDE/SCSI） | OSの起動可否やパフォーマンスに影響。特に IDE に OS を置くと互換性問題が起きやすい |
| ネットワーク | 仮想NIC / MACアドレス / 仮想スイッチの種類 | 統合サービスや外部通信の可否に関係。MAC 重複やスイッチ未接続は Unresponsive の原因に |
| セキュリティ構成 | Secure Boot / TPM / Generation | Gen1/Gen2 の違いや Secure Boot の有効化が OS 起動に影響。Linux では特に注意が必要 |
| ブート構成 | 起動順序 / ISO / PXE / EFI | Off 状態から起動できない場合、ブート構成の誤りが原因であることが多い |
| 統合サービス | Heartbeat / Time Sync / Shutdown / Backup | Status に 正常稼働中 を表示させるための必須要素。未インストールやバージョン不一致で誤表示が起きる |
以上、Copilot
キーファクターの分解
メモリ
- まず、メモリ。4 GB で ALma Linux 9 を VM 環境で構築しました。ですが、筆者はそれと知らずGUI 版をインストールしてしまい、あとで Copilot ( ChatGpt ) にきいたら少ないかもしれません。この辺りは下にも書きました。最初にシャットダウンしようとしたら
StateStatus (数日でもう Status とどっちだったか忘れました ) が “正常稼働中” になったまま終わらなかったので、メモリとかが影響してるのかも。
AlmaLinux 9 を 4 GB で稼働させる構成は、**ミニマルな用途（CLIベースやライトなWebサーバー）**であれば成立しますが、GUI環境や複数のサービスを立ち上げる予定がある場合はかなり逼迫する可能性があります。
可変メモリ（Dynamic Memory）の確認と設定
Hyper-V では「動的メモリ（Dynamic Memory）」という機能があり、VMが必要とするメモリ量に応じてホストからメモリを追加割り当てすることが可能です。
-
確認方法
「Hyper-V マネージャー」で該当VMの設定を開き、「メモリ」項目内に “動的メモリを有効にする” チェックボックスがあります。 -
設定推奨値
初期: 512 MB〜1024 MB
最大: 利用用途に応じて（例えば GUI を使うなら最低 4096 MB 程度
ストレージ
- そして ストレージ。仮想ディスク の問題は、互換性 や パフォーマンス に直結します。したがって、十分なサーバー構成のディスカッションが必要です。
IDE と SCSI コントローラーは、仮想マシンに接続するストレージのインターフェース方式です。それぞれ用途やパフォーマンスに特徴があります。以下のように比較できます：
下記表は ChatGPT
| 比較要素 | IDE コントローラー | SCSI コントローラー |
|---|---|---|
| 💨 パフォーマンス | 基本的・低速。仮想環境では制限あり | 高速・高IO対応。仮想ディスクや仮想DVDに最適 |
| 🔄 柔軟性・拡張性 | デバイス数や構成に制約あり、ホットスワップ不可 | 最大64台接続可能。ホットスワップ対応で運用柔軟 |
🛠 Hyper-V では、IDEは起動ディスク用に一部必須なケースもありますが、性能重視なら SCSI コントローラーが優位です。サーバー用途なら SCSI。
ネットワーク
-
最後に ネットワーク。仮想 NIC、仮想スイッチは VM 技術のうえで特に重要な意味をもち、スペシャリストによる十分な構成が求められます。筆者は、デュアルブートをしているうえで仮想化環境を構築しているので、そちらとの互換性も検討する必要があるかもしれません。
-
また、そのほかの要素についても十分にリサーチしたうえで扱う必要があります。今回、特に関係のありそうなメモリ、ストレージ、ネットワークという基本のハードウェアについて構成の概念を簡単に見直しました。
仮想NIC/ スイッチ
-
イベントビューアでHyper-VMMS の Networkingログを確認します。
イーサネット スイッチ ポートが接続されました -
イベントビューアで Hyper-V-VmSwitch の Operational ログを確認します。
V-Switch 操作 OID_GEN_STATISTICS (131334) の完了に時間がかかりすぎました。操作の種類: OID ホスト VNIC。実行時間 0 ms。キューに入れられた時間 0 ms。予想実行時間は 0 ms 未満です。NicName: C08CB7B8-9B3C-408E-8E30-5E16A3AEB445. NicFriendlyName: Default Switch
→ ホストVNIC (仮想NIC) の動作がタイムアウト (実行時間 0ミリ秒) ? Default Switch は使用していない (今回は 外部仮想スイッチを使用) ため、関係ないかも。
MACアドレス
🛡 MAC アドレス重複を防ぐ仕組み
Hyper-V では、仮想 NIC に対して 動的または静的 MAC アドレスの割り当てが可能です：
- 動的割り当て（Dynamic MAC）
ホスト側で一意な MAC アドレス範囲（デフォルトで 00-15-5D-xx-xx-xx）を持ち、仮想 NIC が作成されるたびにこの範囲内で未使用のものを自動割り当てします。Hyper-V マネージャーや PowerShell で確認・変更可能です。- 静的割り当て（Static MAC）
管理者が手動で MAC アドレスを設定します。重複のリスクがあるため、適切な管理が必要です。加えて、仮想スイッチごとに MAC アドレスの使用状況が追跡され、重複のチェックも行われます。動的設定であれば、Hyper-V が範囲内で重複がないように割り当てるため、通常は問題になりません。
そのほか
- イベントビューアで Hyper-V-Worker の Admin ログを確認します。
'AlmaLinux9WebTest' は、シャットダウン統合コンポーネントで次のパラメーターを指定してシャットダウンされました: 強制 = false、理由 = '' (仮想マシン ID 3A3CF2F0-C174-4CDD-B753-AB8B25EDC279)
原因:
強制操作なしでシャットダウンすることはできません。
この問題を解決するにはどうすればいいのでしょうか？この問題は、誰かが仮想マシンでコンソールセッションを開いたことが原因で発生します。
Hyper-Vの観点から見ると、この一連のイベントの問題は、ユーザーがまだ仮想マシンにログインしていることです。ログインしていること自体は問題ではありません。Hyper-Vマネージャーでは、ログインしている場合でも仮想マシンをシャットダウンできます。問題は、誰かがログインしている間、仮想マシンのコンソールがロックされていたことです。
対処法:
1つ目は、コンソールを開いて仮想マシンにログインし、ロックを解除することです。その後、VMコンソールからシャットダウンを開始するか、Hyper-Vマネージャーを使用して仮想マシンをシャットダウンできます。
2つ目の方法は、PowerShellを使用して強制的にシャットダウンすることです。管理者特権でPowerShellセッションを開き、次のコマンドを入力します。
Stop-VM -Name <仮想マシン名> -Force
警告: 仮想マシンは既に指定された状態になっています。
参考:
成功したやり方
ホストの再起動で、強制シャットダウン。
やり方 : ホストの再起動、あるいは、再起動後に管理者特権でPowerShellセッションを開き、次のコマンドを入力して強制シャットダウン (あるいはすでにされているか確認)します。
Stop-VM -Name <仮想マシン名> -Force
警告: 仮想マシンは既に指定された状態になっています。
→上記の場合、再起動によってすでに強制シャットダウンされていると思われる。
Powershellで強制シャットダウンした時の反応↓
Stop-VM -Name <仮想マシン名> -Force
Shutting Down
0%
[
参考:
https://redmondmag.com/articles/2023/10/31/why-hyperv-vms-sometimes-fail-to-stop.aspx
箸休め：デュアルブート 。Hyper-V 。兼用は辞めようかな
試したこと
1.再度、接続。
- VM 右クリック→接続→変化なし
2.VMMS (仮想マシン管理サービス) が実行中かどうか確認
- 「開始中」または「停止中」の状態の場合、シャットダウンが終わらない可能性がある
PS C:\windows\system32> Get-Service -Name vmms
Status Name DisplayName
------ ---- -----------
Running vmms Hyper-V Virtual Machine Management
3.イベントビューアー、特に Hyper-V およびシステムログの確認
-
イベントビューアーで Hyper-V やシステム関連のログを確認するには、以下の手順で進める
- イベントビューアーを起動: Win + R → eventvwr と入力 → Enter
- Hyper-V のログにアクセス
- 左ペインから：
- アプリケーションとサービスログ
└ Microsoft
└ Windows
└ Hyper-V-VMMS
└ Admin
4.ホストの再起動
起動後確認
Get-VM -Name "AlmaLinux9WebTest" | Select-Object Name, State, Status