Windows 11のシステム情報(msinfo32)を開くと、「仮想化ベースのセキュリティ」の欄に「実行中」と表示されるPCが少なくありません。VMを1台も作ったことがないマシンでもです。
これが意味するのは、次の事実です。そのPCでは、ホストのWindows自体がすでにハイパーバイザーの上で動いています。「仮想化」は、Hyper-VマネージャーでVMを作る人だけの技術ではなくなりました。Windows 11では、対応ハードウェアへのクリーンインストールなど条件を満たす構成で仮想化ベースのセキュリティ(VBS)が既定で有効化されるようになり1、WSL2もWindows Sandboxも、同じWindowsハイパーバイザーを土台にしています。あなたが普段使っているWindowsの下に、もう1枚のソフトウェアの層があるのです。
本連載「Windows仮想化の深層」は、この層で何が起きているのかを、土台から順に追いかけます。
「Windows仮想化の深層」全3回
- 第1回(本記事):ハイパーバイザーとパーティション
Hyper-Vを有効にしたとき、ホストのWindowsがどこで動くことになるのかを追います。 - 第2回:カーネルからも見えないメモリ ── VBS・HVCI・Credential Guard
管理者権限でもカーネルでも読めない秘密を、Windowsがどこに置いているのかを追います。 - 第3回:数秒で起動する仮想マシン ── WSL2・Windows Sandbox・コンテナー
フルVMは重いのに、WSL2やSandboxが軽い理由を、メモリとイメージの共有から追います。
第1回が答える疑問は、ただ1つです。
Hyper-Vを有効にしたとき、ホストのWindowsはどこで動くことになるのか。
対象読者は、Hyper-V・WSL2・Windows Sandboxを使っていて、その足元で何が動いているのかを仕組みから理解したい開発者・運用担当者です。前提環境はx64のWindows 10/11または現行のWindows Serverです(本記事のリング・VT-x/AMD-V・EPT/RVIの説明はx64が前提で、Arm64は例外レベルなど別の仕組みを使います)。前提知識はカーネルモードとユーザーモードの区別程度で、VMの運用経験やハイパーバイザーの開発知識は必要ありません。難易度は中級です。CPUの仮想化支援機能の概念は扱いますが、命令セットの詳細には踏み込みません。
この記事の知識マップ
Hyper-Vを有効にすると、物理CPUとメモリを支配するのはハイパーバイザーになり、ホストのWindowsはルートパーティションとして動く。ハイパーバイザーはSLAT対応CPUとハードウェア仮想化支援を前提とし、ルートパーティションはハイパーコールAPIで子パーティションを作る。デバイスI/Oは子パーティションのVSCからVMBusを経てルート側のVSPへ渡り、合成デバイスとEnlightened I/Oがエミュレーション層を迂回して効率を上げる。エミュレートデバイスの実装とVM管理(VMMS)はルートパーティションが担う。VBS・WSL2・Windows Sandboxも同じハイパーバイザーを土台にし、他社製仮想化スタックはWindows Hypervisor Platform経由で同居する。ハイパーバイザーの動作状態はsysteminfoとHypervisorPresentで、VBSの状態はmsinfo32とWin32_DeviceGuardで確認できる。Windows Serverでディスクリートデバイス割り当てを使う構成では、子パーティションが特定のデバイスへ直接アクセスする。
flowchart LR
accTitle: Hyper-Vハイパーバイザーとパーティションの知識マップ
accDescr: ハイパーバイザーがSLATとハードウェア仮想化支援を前提に動き、ルートパーティションがハイパーコールで子パーティションを作り、VSCとVSPがVMBusで結ばれ、VBSやWSL2やWindows Sandboxが同じ土台に載る関係図
windows_hypervisor["Windowsハイパーバイザー"]
root_partition["ルートパーティション"]
child_partition["子パーティション"]
slat["SLAT"]
hardware_assisted_virtualization["ハードウェア仮想化支援"]
hypercall_api["ハイパーコールAPI"]
virtualization_service_consumer["仮想化サービスコンシューマー"]
vmbus["VMBus"]
virtualization_service_provider["仮想化サービスプロバイダー"]
vbs["仮想化ベースのセキュリティ"]
wsl2["WSL 2"]
windows_sandbox["Windows サンドボックス"]
third_party_virtualization_stack["他社製仮想化スタック"]
windows_hypervisor_platform["Windows Hypervisor Platform"]
systeminfo["systeminfoコマンド"]
hypervisor_present["HypervisorPresentプロパティ"]
enlightened_io["Enlightened I/O"]
emulated_device["エミュレートデバイス"]
synthetic_device["合成デバイス"]
vmms["仮想マシン管理サービス"]
msinfo32["msinfo32(システム情報)"]
win32_deviceguard["Win32_DeviceGuardクラス"]
discrete_device_assignment["ディスクリートデバイス割り当て"]
windows_hypervisor -->|"前提とする"| slat
windows_hypervisor -->|"前提とする"| hardware_assisted_virtualization
root_partition -->|"利用する"| hypercall_api
virtualization_service_consumer -->|"利用する"| vmbus
virtualization_service_provider -->|"利用する"| vmbus
vbs -->|"利用する"| windows_hypervisor
wsl2 -->|"利用する"| windows_hypervisor
windows_sandbox -->|"利用する"| windows_hypervisor
third_party_virtualization_stack -.->|"利用する"| windows_hypervisor_platform
windows_hypervisor -.->|"で確認できる"| systeminfo
windows_hypervisor -.->|"で確認できる"| hypervisor_present
enlightened_io -->|"利用する"| vmbus
root_partition -->|"実装を担う"| emulated_device
virtualization_service_provider -->|"実装を担う"| synthetic_device
synthetic_device -->|"前提とする"| virtualization_service_consumer
root_partition -.->|"利用する"| vmms
vbs -->|"利用する"| slat
vbs -->|"で確認できる"| msinfo32
vbs -->|"で確認できる"| win32_deviceguard
child_partition -.->|"利用する"| discrete_device_assignment
slat -.->|"で確認できる"| systeminfo
hardware_assisted_virtualization -.->|"で確認できる"| systeminfo
図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle
1. まず結論
Hyper-Vと聞くと、「Windowsの上で動くVM実行ソフト」を思い浮かべるかもしれません。実際の構造は逆です。
Hyper-Vを有効にして再起動したときから、物理CPUとメモリを支配するのはハイパーバイザーであり、ホストのWindowsは「ルートパーティション」という名の、特権を持つ最初のパーティションとして、その上で動く。
ハイパーバイザーはハードウェアとOSの間に入る薄いソフトウェア層で、「パーティション」と呼ばれる隔離された実行環境を作り、ハードウェアへのアクセスを調停します。2 ホストのWindowsが入るのがルートパーティション、VMが入るのが子パーティションです。ルートパーティションは特別扱いされますが(物理デバイスへの直接アクセスと管理スタックを持ちます)、物理CPUをじかに支配しているわけではないという点では、子パーティションと同じ立場です。
flowchart TB
accTitle: Hyper-V有効化後の全体構造
accDescr: 物理ハードウェアの直上にハイパーバイザーがあり、その上にホストWindowsが入るルートパーティションと、VMが入る子パーティションたちが並ぶ
hw["物理ハードウェア"] --> hv["ハイパーバイザー"]
hv --> root["ルートパーティション（ホストのWindows）"]
hv --> child1["子パーティション（VMたち）"]
root -.-> stack["仮想化管理スタックとデバイスドライバーを持つ"]
図1: Hyper-Vは「Windowsの上のVMソフト」ではなくWindowsの下に入る層で、ホストOS自身がルートパーティションの中で動く。
「有効化の前後で体感が変わらないのに、そんな大転換が起きているのか」と思うかもしれません。起きています。だからこそ、この構造は普段意識されないのです。本記事では、この1枚の図を、CPU・メモリ・デバイスI/Oの3方向から分解していきます。
2. CPUから見る ── リングの下にもう1つの特権
2.1. リングプロテクションのおさらい
x64のCPUには特権レベル(リング)があり、Windowsはカーネルモードをリング0、ユーザーモードをリング3で動かします。アプリが直接ハードウェアを触れないのは、リング3からは特権命令が実行できないためです。
では、リング0で動くOSカーネルを複数個、同じ物理CPUの上で安全に同居させるにはどうすればよいでしょうか。どのカーネルも「自分がCPUを支配している」つもりで書かれています。全員にリング0を渡せば衝突し、渡さなければ動きません。
flowchart TB
accTitle: 複数のOSカーネルがリング0を要求する問題
accDescr: ホストとゲストのカーネルはどちらもリング0の全権を前提に書かれており、従来のリングの階段だけでは同じ物理CPU上に安全に同居させられない
k1["ホストのカーネル（リング0前提）"] --> want["物理CPUの支配権を要求"]
k2["ゲストのカーネル（リング0前提）"] --> want
want --> conflict["従来のリングだけでは両立できない"]
conflict --> need["リング0より上の調停者が必要"]
図2: リングの階段は1つのOSを前提に作られており、複数のカーネルの同居にはもう1段上の特権が要る。
2.2. 仮想化支援機能 ── ハイパーバイザー専用モード
この問題を解くのが、CPUの仮想化支援機能(Intel VT-x/AMD-V)です。Hyper-Vはこの機能を持つプロセッサを必須要件としています。2 仮想化支援機能は、従来のリングとは別の軸で「ハイパーバイザー用の実行モード」と「ゲスト用の実行モード」を追加します。俗に「リング-1」と呼ばれることもある、リング0よりさらに強い特権です。
- ゲストのカーネルは、これまでどおりリング0で動きます。書き換えは不要です。
- ただしそのリング0は「ゲスト用モードの中のリング0」であり、物理CPU全体を支配しているわけではありません。
- ゲストがハイパーバイザーの介入を要する特定の操作(介入対象として設定された命令や、例外・違反)に当たると、CPUが自動的にハイパーバイザーへ制御を移します(VM Exit)。ハイパーバイザーが処理を終えると、ゲストへ戻します(VM Entry)。通常のメモリアクセスは、SLATの変換が通るかぎりVM Exitなしで素通りします。
割り込みも同様です。パーティションは物理プロセッサに直接触れず、割り込みはハイパーバイザーが受けて各パーティションへ振り向けます。2
flowchart TB
accTitle: ゲスト実行とVM Exitの流れ
accDescr: ゲストのカーネルとアプリはゲスト用モードのリング0とリング3で動き、通常のメモリアクセスはSLATの変換で素通りする一方、介入対象として設定された操作や例外に当たるとVM Exitでハイパーバイザーに制御が移り、処理後にVM Entryでゲストへ戻る
guest["ゲスト用モードで実行中（リング0のカーネルも含む）"] --> op{"介入が要る操作?（設定された介入・例外）"}
op -->|いいえ| cont["そのまま実行を継続"]
op -->|はい| exitEv["VM Exit（CPUが制御を移す）"]
exitEv --> hvp["ハイパーバイザーが処理"]
hvp --> entry["VM Entryでゲストへ復帰"]
entry --> guest
図3: ゲストOSは書き換えなしでリング0のまま動き、必要なときだけCPUがハイパーバイザーを呼び出す。
この往復は、メモリ連載で追った「ページフォルトでカーネルへ入り、同じ命令へ戻る」流れとよく似ています。CPUが例外・遷移の仕組みで制御を横取りし、上位の管理者に判断させてから元へ戻す。Windowsの深層では、この形が繰り返し登場します。
2.3. Type 1とType 2 ── どこに載っているかの違い
ハイパーバイザーは、ハードウェアの直上で動くType 1(ベアメタル型)と、ホストOSの上で動くType 2(ホスト型)に大別されます。Hyper-VはType 1です。3 VirtualBoxや(単体で動かす場合の)VMware WorkstationはType 2に分類されます。
Type 1と聞くと「ホストOSがないサーバー専用の構成」を想像しがちですが、Hyper-Vの場合は違います。ホストのWindowsは消えるのではなく、ルートパーティションの中へ「引っ越す」のです。Hyper-Vを有効化して再起動すると、ブートの過程でまずハイパーバイザーが起動し、その上でホストWindowsがルートパーティションとして立ち上がります。
flowchart TB
accTitle: Type 1とType 2のハイパーバイザーの違い
accDescr: Type 2ではハードウェアの上にホストOSがありその上にハイパーバイザーとVMが載るのに対し、Type 1のHyper-Vではハードウェアの直上にハイパーバイザーがあり、ホストOSもその上のルートパーティションに入る
subgraph t2 ["Type 2（ホスト型）"]
hw2["ハードウェア"] --> hostos["ホストOS"]
hostos --> hv2["ハイパーバイザー"]
hv2 --> vm2["VM"]
end
subgraph t1 ["Type 1（Hyper-V）"]
hw1["ハードウェア"] --> hv1["ハイパーバイザー"]
hv1 --> root1["ルートパーティション（ホストOS）"]
hv1 --> vm1["VM"]
end
vm2 ~~~ hw1
図4: Type 2ではホストOSの上にハイパーバイザーが載るのに対し、Type 1のHyper-Vでは順序が逆転してホストOS自身が1枚下の層の上に載る。
有効化前後で起きる変化を、起動の時間軸で見るとこうなります。
flowchart TB
accTitle: Hyper-V有効化後のブート順序
accDescr: 電源投入後、ブートの過程でまずハイパーバイザーが起動し、その上でホストWindowsがルートパーティションとして立ち上がり、VMやVBSなどはさらにその後で開始される
poweron["電源投入・ブート開始"] --> bhv["ハイパーバイザーが先に起動"]
bhv --> broot["ホストWindowsがルートパーティションとして起動"]
broot --> blater["VM・VBS・WSL2などはその上で開始"]
broot -.-> feel["利用者の体感はこれまでどおり"]
図5: ログオン画面が出る前に順序の逆転は終わっており、ホストOSは最初からハイパーバイザーの上で立ち上がる。
3. パーティション ── 隔離の単位
3.1. ルートパーティションだけが持つ役割
パーティションは、ハイパーバイザーが提供する隔離の論理単位です。2 ただし、全パーティションが対等ではありません。ルートパーティションだけが持つものがあります。
- 物理デバイスへの直接アクセス。 ディスク、NIC、GPUなどのデバイスドライバーは、ハイパーバイザーではなくルートパーティション内のWindowsが持ちます。なお、Windows ServerのHyper-Vには特定のPCIeデバイスを子パーティションへ直接割り当てる構成(ディスクリートデバイス割り当て)があり、その場合ルートは当該デバイスを手放します(クライアント版Windowsでは利用できません)。4
- 仮想化管理スタック。 VMの作成・起動・停止を司るVMMS(仮想マシン管理サービス)や、VM1台ごとに立ち上がるワーカープロセス(vmwp.exe)は、ルートパーティションのユーザーモードで動きます。5 これらはHyper-VのVM管理機能の一部なので、VBSやWSL2のためにハイパーバイザーだけが動いているホストでは存在しないことがあります。
- 子パーティションの作成権。 ルートパーティションは、ハイパーコールAPI(ハイパーバイザーへの呼び出しインターフェイス)を通じて子パーティションを作ります。2
この設計には理由があります。あらゆるデバイスドライバーをハイパーバイザー本体に入れると、ハイパーバイザーが巨大化し、不具合や攻撃の入口も増えます。ハイパーバイザーはCPUとメモリの調停という最小限の仕事に徹し、デバイスの面倒はルートパーティションのWindowsに任せる。この役割分担が、Hyper-Vの薄さを支えています。
flowchart TB
accTitle: ルートパーティションと子パーティションの役割分担
accDescr: ルートパーティションは仮想化管理スタックと物理デバイスドライバーを持ってハイパーコールで子パーティションを作成し、子パーティションは通常構成では仮想デバイスだけを見て、Windows Server向けのディスクリートデバイス割り当てでは割り当てられたデバイスへ直接アクセスする
subgraph rootp ["ルートパーティション"]
vmms["VMMSとワーカープロセス"]
drv["物理デバイスドライバー"]
end
subgraph childp ["子パーティション"]
gos["ゲストOS"]
vdev["通常構成では仮想デバイスのみ見える"]
end
vmms -->|ハイパーコールで作成・管理| childp
hv2["ハイパーバイザー（CPU・メモリの調停に徹する）"] --- rootp
hv2 --- childp
図6: デバイスドライバーと管理スタックをルートパーティション側に置くことで、ハイパーバイザー本体は薄く保たれる。
3.2. 子パーティションから見える世界
子パーティションのゲストOSは、通常の仮想デバイス構成では物理ハードウェアを直接見ることができません(前節で述べたWindows Server向けのディスクリートデバイス割り当てで割り当てられたデバイスだけが例外です)。見えるのは、仮想プロセッサ、自分専用の(ように見える)メモリ空間、そして仮想デバイスです。仮想デバイスへの要求は、VMBusまたはハイパーバイザー経由でルートパーティションへ転送されます。2 一方、CPU時間の配分やSLATによるメモリ変換は、ルートを経由せずハイパーバイザーが直接担います。ルートが仲介するのはデバイスI/Oであって、すべての物理資源ではありません。
flowchart TB
accTitle: 子パーティションから見える世界
accDescr: ゲストOSに見えるのは仮想プロセッサ、パーティション私有のメモリ空間、仮想デバイスであり、仮想デバイスへの要求はVMBusなど経由でルートパーティションに転送され、CPU時間とメモリ変換はハイパーバイザーが直接担い、Windows Server向けのディスクリートデバイス割り当ての構成では割り当てられたデバイスにのみ直接アクセスする
gos2["子パーティションのゲストOS"] --> vcpu["仮想プロセッサ"]
gos2 --> gpa2["私有のメモリ空間"]
gos2 --> vdev2["仮想デバイス"]
vdev2 -->|"VMBusなど経由"| rootx["ルートパーティションへ転送"]
gos2 -.->|直接は見えない| phys2["物理CPU・RAM・実デバイス"]
phys2 -.-> dda2["DDA構成（Windows Server）では割り当てデバイスのみ直接アクセス"]
vcpu ~~~ phys2
図7: 通常の仮想デバイス構成ではゲストに見えるものは全て仮想の窓で物理への通路は調停役を通り、Windows ServerのDDAで割り当てたデバイスだけが例外になる。
ここで重要なのは、ホストのWindowsで動いているアプリにとって、この構造はほぼ透過だという点です。Win32 APIの呼び出しも、ページフォルトの処理も、これまでどおりルートパーティション内のWindowsカーネルが処理します。ハイパーバイザーが介入するのは、設定された介入対象や例外に当たる場面に限られます。
4. メモリから見る ── アドレス変換がもう一段増える
4.1. 3種類のアドレス
メモリ連載の第1回では、仮想アドレスがページテーブルを経て物理アドレスへ変換される流れを追いました(「仮想アドレスが物理RAMに変わる瞬間」)。仮想化環境では、この変換の下にもう一段が加わり、アドレスは3種類になります。
| アドレス | 略称 | 誰が管理するか |
|---|---|---|
| ゲスト仮想アドレス | GVA | ゲストOSのページテーブル |
| ゲスト物理アドレス | GPA | ゲストOSが「物理」と信じているアドレス |
| システム物理アドレス | SPA | ハイパーバイザー(実際のRAM上の位置) |
ゲストOSは自分のページテーブルでGVAからGPAへ変換します。しかしゲストが見ているGPAは本当の物理アドレスではなく、各パーティション専用の私的なメモリ空間です。2 GPAを実際のRAM上の位置(SPA)へ対応付けるのは、ハイパーバイザーの仕事です。
4.2. SLAT ── 二段変換をハードウェアで
この二段目の変換をソフトウェアだけで行うと、ゲストのページテーブル更新をハイパーバイザーが逐一追跡する必要があり、性能面で現実的ではありません。そこでCPUには、二段目の変換表をハードウェアで引く仕組みが用意されています。これがSLAT(Second Level Address Translation)で、Intel EPT(拡張ページテーブル)やAMD RVIが該当します。現行のHyper-Vは、SLAT対応の64bitプロセッサを必須要件としています。4
flowchart TB
accTitle: SLATによる二段のアドレス変換
accDescr: ゲスト仮想アドレスはゲストOSのページテーブルでゲスト物理アドレスへ変換され、さらにハイパーバイザーが管理するSLATでシステム物理アドレスへ変換されて実際のRAMに到達する
gva["ゲスト仮想アドレス（GVA）"] -->|ゲストOSのページテーブル| gpa["ゲスト物理アドレス（GPA）"]
gpa -->|"SLAT（EPT/RVIの変換表）"| spa["システム物理アドレス（SPA）"]
spa --> ram["物理RAM"]
gpa -.-> note["ゲストが物理と信じているだけの層"]
図8: ゲストのページテーブルの下にハイパーバイザー管理の変換表がもう一段入り、CPUは両方をハードウェアでたどる。
SLATはVMの実行効率のためだけの機能ではありません。第2回で見るVBSは、「特権レベルごとに異なるSLAT変換表を持てる」という性質を、セキュリティ境界の材料として使います。カーネルにすら見せないメモリを作れるのは、この二段目の変換をハイパーバイザーが握っているからです。ここは連載全体の伏線になるので、「変換表の管理者はハイパーバイザー」という一点だけ覚えておいてください。
5. デバイスI/Oから見る ── VMBusと2種類のデバイス
5.1. エミュレートデバイスの限界
子パーティションにデバイスを見せる古典的な方法は、実在のハードウェア(たとえば古いIDEコントローラー)をソフトウェアで完全に模倣することです。ゲストOSの標準ドライバーがそのまま使えるため互換性は高いのですが、ゲストがI/Oポートを叩くたびにVM Exitが発生し、性能は伸びません。
flowchart TB
accTitle: エミュレートデバイスのI/Oが遅い理由
accDescr: ゲストがI/Oポートを操作するたびにVM Exitでハイパーバイザー側へ制御が移り、デバイスをソフトウェアで模倣してからゲストへ戻る往復が繰り返されるため遅い
gio["ゲストがI/Oポートを操作"] --> vex["VM Exitが発生"]
vex --> emu2["デバイスをソフトウェアで模倣"]
emu2 --> back["VM Entryでゲストへ復帰"]
back -->|次のポート操作でまた繰り返し| gio
図9: 1回のディスクアクセスの裏でこの往復が何度も走り、互換性の代金は性能で払うことになる。
5.2. VMBusとVSP/VSC ── 仮想化前提の高速通路
そこでHyper-Vは、仮想化を前提に設計された「合成デバイス」の仕組みを持ちます。登場人物は3つです。2
- VMBus:パーティション間の論理的な通信チャネル。共有メモリを利用した高速なパーティション間通信を提供します。3
- VSP(Virtualization Service Provider):ルートパーティション側に常駐し、子からのデバイス要求を受けてルート側のデバイス/バックエンドのスタックへ橋渡しするサービス。要求は物理デバイスへ届くことも、仮想ディスクや仮想スイッチなどホスト側のバックエンドで処理されることもあります。
- VSC(Virtualization Service Consumer):子パーティション側のゲストOSに入る合成デバイスドライバー。要求をVMBus経由でVSPへ送ります。
ゲストOSのストレージ要求を例にすると、流れは次のようになります。ゲストアプリのWriteFileはゲストカーネルのI/Oスタックを降り、最下層で(実在ハードの代わりに)VSCに到達します。VSCは要求をVMBusに載せてルートパーティションのVSPへ渡し、VSPがルート側のI/Oスタックへ要求を流します。仮想ディスク(VHDX)構成なら、この書き込みはホスト上のVHDXファイルへの書き込みとして処理され、最終的に物理ディスクへ届きます。この方式はEnlightened I/O(仮想化を自覚したI/O)と呼ばれ、デバイスエミュレーションの層を迂回することで効率を上げています。2
flowchart TB
accTitle: 合成デバイスのI/O経路
accDescr: 子パーティションのアプリのI/O要求はゲストカーネルを経てVSCに届き、VMBusでルートパーティションのVSPへ渡り、VSPが橋渡しするルート側のI/Oスタックで、物理デバイスドライバー経由で実デバイスに届くことも、仮想ディスクや仮想スイッチなどホスト側のバックエンドで処理されることもある
app["子パーティションのアプリ"] --> gk["ゲストカーネルのI/Oスタック"]
gk --> vsc["VSC（合成デバイスドライバー）"]
vsc -->|VMBus| vsp["VSP（ルートパーティション側）"]
vsp --> rio["ルート側のI/Oスタック"]
rio --> pdrv["物理デバイスドライバー"]
rio --> hb["ホスト側バックエンド（仮想ディスク・仮想スイッチなど）"]
pdrv --> dev["物理デバイス"]
図10: 合成デバイスでは、ゲストのI/OがVMBus経由でルートパーティションに渡り、ルート側のスタックを経て実デバイスやホスト側のバックエンドへ届く。
つまり、VMのディスクI/Oやネットワークが速いかどうかは、ゲスト側だけでなくルートパーティション側のI/Oスタックとデバイスドライバーの状態にも左右されます。VMの性能問題を調べるときにホスト側の観測が欠かせないのは、経路が実際にホストを通っているからです。
flowchart TB
accTitle: エミュレートデバイスと合成デバイスの対比
accDescr: エミュレートデバイスは実在ハードの模倣でゲスト標準ドライバーが使えるが遅く、合成デバイスはVMBus前提の専用ドライバーで高速という対比
dev2{"子パーティションに見せるデバイス"} --> emu["エミュレートデバイス"]
dev2 --> syn["合成デバイス"]
emu -.-> emuP["実在ハードを模倣・互換性重視"]
emuP -.-> emuC["I/Oのたびに介入が必要で遅い"]
syn -.-> synP["VMBus前提の設計で高速"]
synP -.-> synC["ゲストに対応ドライバーが必要"]
図11: 2種類の仮想デバイスのうち、OSインストール直後の互換性はエミュレートが、常用時の性能は合成デバイスが担う。
6. VMを使わない人にも他人事ではない理由
ここまでの構造は、「VMを立てる人の話」に見えるかもしれません。しかし冒頭のとおり、現在のWindowsではハイパーバイザーは日常の一部です。
- 仮想化ベースのセキュリティ(VBS)。 Windowsハイパーバイザーを使って隔離環境を作り、そこにセキュリティ機能を収容します。Windows 11では、対応ハードウェアへのクリーンインストールなど条件を満たす場合に既定で有効です。1 詳細は第2回で扱います。
- WSL2。 軽量ユーティリティVMの中で本物のLinuxカーネルを動かします。6
- Windows Sandbox。 ハイパーバイザーで分離された使い捨てのWindows環境です。7 どちらも第3回で扱います。
flowchart TB
accTitle: 同じハイパーバイザーに載る日常の機能
accDescr: Hyper-VのVMだけでなく、クリーンインストールなど条件を満たすデバイスで既定有効なVBS、WSL2、Windows Sandboxまでが同じWindowsハイパーバイザーを土台にしている
base["Windowsハイパーバイザー"] --> f1["Hyper-VのVM"]
base --> f2["VBS（クリーンインストール等で既定有効）"]
base --> f3["WSL2"]
base --> f4["Windows Sandbox"]
f2 -.-> daily["VMを使わないPCでも動く理由"]
図12: 土台は1つであり、「仮想化はVMを使う人の話」という前提がこの図で崩れる。
もう1つ、実務でよく踏むのが他社製仮想化ソフトとの共存です。CPUの仮想化支援機能はハイパーバイザーが排他的に使うため、Windowsハイパーバイザーが動いている環境では、VirtualBoxなどが従来方式(自前でCPUの仮想化支援を使う方式)で動けません。このためにWindows Hypervisor Platformという公開APIが用意されており、他社製の仮想化スタックはWindowsハイパーバイザーの上に載る形で動作できます。8 現行のVirtualBox/VMwareとWSL2が共存できるのはこの仕組みのおかげですが、方式の切り替えに伴う性能差や機能差が「Hyper-V(またはVBS)を有効にしたら仮想化ソフトの調子が変わった」という形で観測されることがあります。
flowchart TB
accTitle: CPU仮想化支援の所有者と他社製仮想化ソフトの経路
accDescr: Windowsハイパーバイザーが動作中はCPUの仮想化支援機能をハイパーバイザーが占有し、WHPに対応した他社製仮想化ソフトはWindows Hypervisor Platform経由でその上に載って動く一方、WHP非対応の実装は動作できないか機能が制限される
vt["CPUの仮想化支援（VT-x/AMD-V）"] --> hvon{"Windowsハイパーバイザーは動作中?"}
hvon -->|いいえ| direct["他社製ソフトが直接利用できる"]
hvon -->|はい| own["ハイパーバイザーが占有"]
own --> whp["Windows Hypervisor Platform"]
whp --> third["WHP対応の他社製ソフトはこの上で動く"]
third -.-> nowhp["非対応の実装は動作不可か機能制限"]
図13: 仮想化支援機能の所有者は1つで、ハイパーバイザー動作中に同居できるのは公開API(WHP)に対応した他社製ソフトに限られる。
7. 自分の目で確かめる
自分のPCでハイパーバイザーが動いているかどうかは、手元で確認できます。
まず、管理者権限なしで実行できる確認です。
# ハイパーバイザーの上で動いているか
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
# VBSの状態(msinfo32の「仮想化ベースのセキュリティ」と同じ情報源)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
-ClassName Win32_DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus
VirtualizationBasedSecurityStatusは、VBSの動作状態を数値で返します(2が「実行中」)。9
1つ注意があります。HypervisorPresentが示すのは「ハイパーバイザーの上で動いているか」だけで、ルートか子かは区別しません。VMの中のWindowsで実行しても、子パーティションとしてTrueが返ります。物理PC上のWindowsでTrueなら、そのWindowsはルートパーティションの中にいる──と、実行環境と合わせて読みます。
次に、コマンドプロンプトからの定番です。
systeminfo
出力末尾の「Hyper-Vの要件」を見ます。ハイパーバイザーがまだ動いていないマシンでは、SLAT対応・仮想化支援の有効/無効などの要件が個別に表示されます。すでにハイパーバイザーが動いているマシンでは、要件の代わりに「ハイパーバイザーが検出されました。Hyper-Vに必要な機能は表示されません。」と1行だけ表示されます。4 つまりこの1行は、あなたのWindowsが何らかのハイパーバイザーの上で動いていることの表明です。HypervisorPresentと同じく、物理PCならルートパーティションの中、VMの中なら子パーティションとして、という読み分けが要ります。
systeminfoの要件がすべて「はい」でも、それはハードウェア側の準備が整っているという意味です。Hyper-Vの機能自体はPro・Enterprise・Educationエディションで利用でき、Homeにはありません。10
GUIなら、msinfo32の「システムの要約」で「仮想化ベースのセキュリティ」の行を確認します。タスクマネージャーのCPU欄にある「仮想化: 有効」は、ファームウェアで仮想化支援機能が有効かを示すだけで、ハイパーバイザーが動作中かどうかとは別の情報である点に注意してください。
flowchart TB
accTitle: ハイパーバイザー動作状態の確認手順
accDescr: systeminfoでハイパーバイザーが検出されましたと出ればハイパーバイザーの上で動作中（物理PCならルートパーティション）であり、Hyper-Vの要件一覧が出ればまだ動いていないのでSLAT・VMモニターモード拡張・DEPなど全要件を確認するが、全要件がはいでもそれはハードウェア側の準備であってHyper-Vの機能にはエディション要件もある
start2["systeminfoを実行"] --> q1{"Hyper-Vの要件の欄は?"}
q1 -->|ハイパーバイザーが検出されました| running["ハイパーバイザー動作中（物理PCならルート内）"]
q1 -->|要件が一覧表示される| notyet["ハイパーバイザーは未動作"]
notyet --> q2{"要件はすべて「はい」?"}
q2 -->|すべてはい| can["ハードウェア側の準備は整っている"]
can -.-> ed["Hyper-VにはPro/Enterprise/Educationも必要"]
q2 -->|いいえがある| uefi["UEFI/BIOS等で該当項目を確認"]
図14: systeminfoの「Hyper-Vの要件」欄は、動作状態の確認と事前要件の確認を1つで兼ねる。
8. 実務で避けたい3つの誤読
8.1. 「Hyper-Vを有効にしていないから、うちのPCに仮想化は関係ない」
Hyper-Vの機能(管理ツールとVM実行環境)を有効化していなくても、VBSが有効ならWindowsハイパーバイザーは動いています。ドライバーの互換性問題、性能検証、他社製仮想化ソフトのトラブルを調べるときは、機能の有効化状態ではなく、HypervisorPresentとVBSの動作状態を確認してください。
8.2. 「タスクマネージャーに『仮想化: 有効』と出ているからHyper-Vが動いている」
あの表示はファームウェア設定(VT-x/AMD-Vが使える状態か)の話です。ハイパーバイザーの動作状態はsysteminfoの「ハイパーバイザーが検出されました」で判断します。逆に、タスクマネージャーで「無効」なら、Hyper-VもWSL2も有効化できないので、UEFI/BIOSの設定を先に確認します。
flowchart TB
accTitle: 混同しやすい3つの確認項目
accDescr: タスクマネージャーの仮想化欄はファームウェア設定、Windowsの機能の一覧はインストール状態、systeminfoやHypervisorPresentは動作状態を示し、それぞれ別の質問に答えている
q3{"何を知りたい?"} --> a3["ファームウェアで仮想化支援は有効か"]
q3 --> b3["Hyper-Vの機能を入れたか"]
q3 --> c3["ハイパーバイザーは今動いているか"]
a3 -.-> a3t["タスクマネージャーのCPU欄"]
b3 -.-> b3t["Windowsの機能の有効化画面"]
c3 -.-> c3t["systeminfoとHypervisorPresent"]
図15: 3つは独立した質問であり、どれか1つの表示から他の2つを推測すると誤読になる。
8.3. 「VMが遅いのはゲストOSの問題」
合成デバイスのI/Oは、VMBusを通ってルートパーティションのVSPに渡り、ルート側のデバイス/バックエンドのスタック(物理ドライバーのほか、仮想スイッチや仮想ディスクの処理)を経由します。ゲスト内のカウンターだけを眺めても、ボトルネックがホスト側のストレージやNICにあれば見つかりません。VMの性能問題は、ゲストとホスト(ルートパーティション)の両側から観測するのが原則です。
9. まとめ
- Hyper-Vを有効にすると、ハイパーバイザーがハードウェア直上で動き、ホストのWindowsはルートパーティションとして動きます。2
- ゲストOSのカーネルはリング0のまま動き、介入対象として設定された操作や例外だけがVM Exitでハイパーバイザーに渡ります。通常のメモリアクセスはSLATの変換で素通りします。
- ルートパーティションだけが物理デバイスドライバーと仮想化管理スタックを持ち、ハイパーコールで子パーティションを作ります。2
- メモリはGVA→GPA→SPAの二段変換になり、二段目はSLAT(EPT/RVI)がハードウェアで担います。現行Hyper-VはSLAT必須です。4
- デバイスI/Oは、VSC→VMBus→VSPという合成デバイスの経路が主役で、性能はホスト側のI/Oスタックにも依存します。2
- Windows 11では、クリーンインストールなど条件を満たすデバイスで既定有効になるVBSにより、VMを使わないPCでもハイパーバイザーが動いていることが珍しくありません。1 動作状態は
HypervisorPresentとsysteminfoで確認できます。
第1回の全体像は、この1枚に集約されます。
flowchart TB
accTitle: 第1回の全体像
accDescr: ルートパーティションと子パーティションの下にハイパーバイザーがあり、CPUは仮想プロセッサのスケジュールで配分され(VM Exitは設定された介入・例外のみ)、メモリはSLATの二段変換で調停され、合成デバイスのI/OはVMBusで転送されてルートパーティションのVSPが処理し、エミュレートデバイスとディスクリートデバイス割り当ては別経路を持つ
up["ルートパーティションと子パーティション"] --> hvS["ハイパーバイザー"]
hvS --> cpuS["CPU:仮想プロセッサを配分"]
hvS --> memS["メモリ:SLATで二段変換"]
hvS --> devS["デバイス:合成はVMBusで転送"]
cpuS -.-> cpuN["VM Exitは介入時のみ"]
devS --> vspS["ルート側のVSPが処理"]
devS -.-> devN["エミュレートとDDAは別経路"]
図16: CPUのスケジュールとメモリ変換はハイパーバイザーが直接担い(VM Exitは介入時のみ)、合成デバイスのI/OはVMBusの先でルートパーティション(VSP)が仲介する。
続きは第2回「カーネルからも見えないメモリ ── VBS・HVCI・Credential Guard」です。
ハイパーバイザーがSLATの変換表を握っているという本記事の伏線を回収し、「管理者権限でもカーネルでも読めないメモリ」をWindowsがどう作っているのかを追います。
関連記事
- Windowsメモリの深層(第1回) ── 仮想アドレスが物理RAMに変わる瞬間:ページフォルトの一部始終
- Windowsの「メモリ使用量」は何を表しているのか ── Working Set・Private Bytes・Commit・ページファイルを正しく読む
- Windows Sandboxで業務アプリ検証環境を作る
- WindowsのP/Eコアとプロセッサスケジューリング
関連する相談領域
合同会社小村ソフトでは、Windowsアプリケーションの検証環境設計、仮想化環境での性能調査、ドライバーや周辺機器の互換性問題の解析を扱っています。
参考リンク
-
Microsoft Learn, Silicon assisted security. VBSがハードウェア仮想化を使ってセキュアカーネルを通常のOSから分離すること、Windows 11の新規インストールでは前提条件を満たすデバイスでVBSとHVCIが既定で有効になることについて。 ↩ ↩2 ↩3
-
Microsoft Learn, Hyper-V Architecture. ハイパーバイザーが分離単位としてパーティションを提供すること、ルートパーティションがハイパーコールAPIで子パーティションを作ること、パーティションが物理プロセッサに直接アクセスせず私的な仮想メモリ空間で動くこと、VMBus・VSP・VSC・Enlightened I/Oの役割、およびハードウェア仮想化支援(Intel VT/AMD-V)が必須であることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12
-
Microsoft Learn, Hyper-V architecture (Performance Tuning). Hyper-VがType 1ハイパーバイザーであること、ルートパーティションが物理I/Oデバイスを所有すること、VMBusが共有メモリを利用した高性能なパーティション間通信を提供することについて。 ↩ ↩2
-
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. SLAT対応の64bitプロセッサとVMモニターモード拡張が必須であること、systeminfoの「Hyper-Vの要件」欄で要件の充足を確認できること、およびハイパーバイザー動作中は「ハイパーバイザーが検出されました」と表示されること、ディスクリートデバイス割り当てで特定デバイスを子パーティションへ直接割り当てられることについて。 ↩ ↩2 ↩3 ↩4
-
Microsoft Learn, Appendix B: Hyper-V Architecture and Feature Overview. VMMS(仮想マシン管理サービス)が子パーティション内のVMの状態管理を担い、VMごとにワーカープロセス(VMWP)がルートパーティションのユーザーモードで起動されることについて。 ↩
-
Microsoft Learn, Comparing WSL Versions. WSL2が軽量ユーティリティVMの中で本物のLinuxカーネルを動かすこと、および現行のVMware・VirtualBoxとの併用に関する注意点について。 ↩
-
Microsoft Learn, Windows Sandbox architecture. Windows Sandboxがコンテナー技術とハイパーバイザーによる分離を組み合わせた軽量なWindows環境であることについて。 ↩
-
Microsoft Learn, Windows Hypervisor Platform. 他社製の仮想化スタックがWindowsハイパーバイザーの上でパーティションを作成・管理するためのユーザーモードAPIが提供されていることについて。 ↩
-
Microsoft Learn, Enable Hotpatch for Azure Arc-enabled servers. Win32_DeviceGuardクラスのVirtualizationBasedSecurityStatusでVBS(仮想セキュアモード)の動作状態を確認できることについて。 ↩
-
Microsoft Learn, Install Hyper-V. Hyper-VがWindows 10/11のProまたはEnterprise等で有効化でき、Homeエディションにはインストールできないことについて。 ↩
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
Windows仮想化の深層(第3回) ── 数秒で起動する仮想マシン:WSL2・Windows Sandbox・コンテナーの軽さの正体
WSL2やWindows Sandboxが数秒で起動して軽いのはなぜか。動的ベースイメージ、ダイレクトマップ、メモリの動的配分、Hyper-V分離コンテナーまで仕組みから解説します。
Windows仮想化の深層(第2回) ── カーネルからも見えないメモリ:VBS・HVCI・Credential Guardの仕組み
対応ハードウェアへのクリーンインストールで既定有効になるVBSは、ハイパーバイザーとSLATでカーネルより強い隔離を作ります。VTL、セキュアカーネル、HVCI、Credential Guardの構造を解説します。
Win32スレッドプールAPI ── CreateThreadpoolWorkで「スレッドを作らない」並行処理
ネイティブコードでCreateThreadを乱立させていませんか。Vistaで刷新されたWin32スレッドプールAPIのwork・timer・wait・ioの4オブジェクト、クリーンアップグループ、コールバックでの禁止事項までを一次情報にもとづいて解説します。
名前付きパイプの実務 ── Windowsプロセス間通信の定番を設計からセキュリティまで
Windowsのプロセス間通信の定番・名前付きパイプを実務目線で解説します。バイト/メッセージモードの選択、複数クライアントを捌くサーバー設計、ACLと偽装のセキュリティ、.NETのNamedPipeStreamまで、一次情報にもとづき整理します。
スリープ復帰で壊れるアプリ ── 電源イベントの仕組みと復帰に強い業務アプリの作り方
ノートPCを開いたら業務アプリの通信が切れていた――原因はスリープを想定しない設計です。WM_POWERBROADCASTによる通知の流れ、Modern Standbyの挙動、切断・再接続の設計、スリープ抑止と調査コマンドまでを一次情報で解説します。
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。
よくある質問
この記事のテーマについて、相談時によくある質問をまとめています。
- Hyper-Vを有効にすると、ホストのWindowsはどこで動くのですか？
- ハイパーバイザーが物理CPUとメモリの配分を直接制御し、ホストのWindowsはルートパーティションと呼ばれる特別なパーティションの中で動きます。物理デバイスの制御は、通常はルートパーティション側のドライバーが担います。ルートパーティションはデバイスドライバーと仮想化管理スタックを持ちますが、物理CPUの支配権はハイパーバイザー側にあります。
- タスクマネージャーの「仮想化: 有効」はHyper-Vが動作中という意味ですか？
- いいえ。あの表示はファームウェアでCPUの仮想化支援機能(Intel VT-x/AMD-V)が有効になっているかを示すものです。ハイパーバイザーが実際に動作しているかは、systeminfoの「ハイパーバイザーが検出されました」の表示や、Win32_ComputerSystemのHypervisorPresentで確認します。
- VMを1台も作っていないのにハイパーバイザーが動いているのはなぜですか？
- Windows 11では、対応ハードウェアへのクリーンインストールなど条件を満たすデバイスで仮想化ベースのセキュリティ(VBS)が既定で有効になっており、VBSはWindowsハイパーバイザーを土台にしています。WSL2やWindows Sandboxを使う場合も同様です。VMの利用とは無関係に、ハイパーバイザーが起動していることは珍しくありません。
- SLATとは何ですか？なぜHyper-Vに必須なのですか？
- SLAT(Second Level Address Translation)は、ゲスト物理アドレスから実際の物理アドレスへの変換をCPUが行う仕組みで、Intel EPTやAMD RVIが該当します。これがないと、ハイパーバイザーがソフトウェアで変換表を維持することになり、性能面で現実的でないため、現行のHyper-Vでは必須要件です。
- Hyper-Vを有効にするとVirtualBoxやVMwareは使えなくなりますか？
- ハイパーバイザーはCPUの仮想化支援機能を排他的に使うため、他社製ハイパーバイザーは従来方式では動けなくなります。ただし現行のVirtualBoxやVMwareは、Windowsハイパーバイザーの上で動くモード(Windows Hypervisor Platform経由)を持っており、最新版どうしの組み合わせであれば共存できます。