Windows仮想化の深層(第1回) ── あなたのWindowsはどこで動いているのか:ハイパーバイザーとパーティション

小村 豪

doi:10.5281/zenodo.22170920

Windows仮想化の深層(第1回) ── あなたのWindowsはどこで動いているのか:ハイパーバイザーとパーティション

2026年08月22日 02:00 · 更新日: 2026年09月05日 · 小村豪 · Windows, 仮想化, Hyper-V, ハイパーバイザー, SLAT, VMBus

更新履歴(1件・最終更新 2026年09月05日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年09月05日: 技術的な主張と条件はそのままに、全3回のつながりと各回の問いを冒頭で示し、役割分担、保護範囲、軽量化の仕組み、動作確認を小見出しと目的別リンクで追いやすく整理した。更新前のバージョンを見る (DOI: 10.5281/zenodo.22170921)
2026年08月22日: 初版公開

この記事を引用する(DOI: 10.5281/zenodo.22170920)

この記事はZenodoにアーカイブされています。常に最新版へ解決されるDOIと、いま表示している版に固定されたDOIの両方を下に示します。

小村豪(2026)「Windows仮想化の深層(第1回) ── あなたのWindowsはどこで動いているのか:ハイパーバイザーとパーティション」合同会社小村ソフト. https://doi.org/10.5281/zenodo.22170920 https://comcomponent.com/blog/windows-virtualization-internals-hypervisor/

DOI(最新版): 10.5281/zenodo.22170920
DOI(この版): 10.5281/zenodo.22344231

VMを1台も作ったことがないのに、Windows 11のシステム情報(msinfo32)には「仮想化ベースのセキュリティ: 実行中」と出る。この表示は、何を意味するのでしょうか。

そのPCでは、ホストのWindows自体が、すでにハイパーバイザーの上で動いています。 Windows 11では、対応ハードウェアへのクリーンインストールなど条件を満たす構成でVBSが既定で有効になり、VMを作らなくてもその土台が使われます。¹ WSL2やWindows Sandboxも、同じWindowsハイパーバイザーを利用します。

第1回では、「Hyper-Vを有効にしたとき、ホストのWindowsはどこで動くことになるのか」を、CPU・メモリ・デバイスI/Oの役割分担から説明します。「Windowsの上にVMソフトを載せる」という見方を、まず整理し直す回です。

「Windows仮想化の深層」全3回

同じWindowsハイパーバイザーを、土台 → セキュリティの隔離 → 軽量VMへの応用の順に見ていきます。

回	中心となる問い
第1回: ハイパーバイザーとパーティション(本記事)	ホストのWindowsはどこで動くのか
第2回: VBS・HVCI・Credential Guard	カーネルにも読めない秘密をどこに置くのか
第3回: WSL2・Windows Sandbox・コンテナー	隔離を保ったまま、なぜ軽くできるのか

この記事の前提

項目	内容
対象読者	Hyper-V・WSL2・Windows Sandboxの足元の仕組みを理解したい開発者・運用担当者
前提環境	x64のWindows 10/11または現行のWindows Server。リング・VT-x/AMD-V・EPT/RVIの説明はx64が前提で、Arm64は例外レベルなど別の仕組みを使います
前提知識	カーネルモードとユーザーモードの区別。VMの運用経験やハイパーバイザーの開発知識は不要です
難易度・範囲	中級。CPUの仮想化支援機能の概念を扱い、命令セットの詳細には踏み込みません

この記事の読み方

知りたいこと	読む節
WindowsとVMの位置関係、CPUの実行、役割分担	1節の全体像 → 2節のCPU → 3節のパーティション
メモリとデバイスI/Oは誰が仲介するのか	4節のSLAT → 5節のVMBus
VMを作らないPCへの影響、自分のPCの確認方法	6節の日常機能と共存 → 7節の確認方法

以下の知識マップは関係の一覧です。初めて読む場合は、1節の全体像から本文を追ってください。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

1. まず結論

Hyper-Vと聞くと、「Windowsの上で動くVM実行ソフト」を思い浮かべるかもしれません。実際の構造は逆です。

Hyper-Vを有効にして再起動したときから、物理CPUとメモリを支配するのはハイパーバイザーであり、ホストのWindowsは「ルートパーティション」という名の、特権を持つ最初のパーティションとして、その上で動く。

ハイパーバイザーはハードウェアとOSの間に入る薄いソフトウェア層で、「パーティション」と呼ばれる隔離された実行環境を作り、ハードウェアへのアクセスを調停します。² ホストの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つの特権

CPUの話では、カーネルとアプリを分けるリングと、ハイパーバイザーとゲストを分ける実行モードを区別します。「ゲストのカーネルもリング0で動くのに、なぜ衝突しないのか」がこの節の問いです。

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はこの機能を持つプロセッサを必須要件としています。² 仮想化支援機能は、従来のリングとは別の軸で「ハイパーバイザー用の実行モード」と「ゲスト用の実行モード」を追加します。俗に「リング-1」と呼ばれることもある、リング0よりさらに強い特権です。

ゲストのカーネルは、これまでどおりリング0で動きます。書き換えは不要です。
ただしそのリング0は「ゲスト用モードの中のリング0」であり、物理CPU全体を支配しているわけではありません。
ゲストがハイパーバイザーの介入を要する特定の操作(介入対象として設定された命令や、例外・違反)に当たると、CPUが自動的にハイパーバイザーへ制御を移します(VM Exit)。ハイパーバイザーが処理を終えると、ゲストへ戻します(VM Entry)。通常のメモリアクセスは、SLATの変換が通るかぎりVM Exitなしで素通りします。

割り込みも同様です。パーティションは物理プロセッサに直接触れず、割り込みはハイパーバイザーが受けて各パーティションへ振り向けます。²

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です。³ 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. パーティション ── 隔離の単位

全体像の「箱」にあたるパーティションを詳しく見ます。ここで分けたいのは、ハイパーバイザーが直接担うCPU・メモリの調停と、通常はルートパーティションが仲介するデバイスI/Oです。

3.1. ルートパーティションだけが持つ役割

パーティションは、ハイパーバイザーが提供する隔離の論理単位です。² ただし、全パーティションが対等ではありません。ルートパーティションだけが持つものがあります。

物理デバイスへの直接アクセス

ディスク、NIC、GPUなどのデバイスドライバーは、ハイパーバイザーではなくルートパーティション内のWindowsが持ちます。なお、Windows ServerのHyper-Vには特定のPCIeデバイスを子パーティションへ直接割り当てる構成(ディスクリートデバイス割り当て)があり、その場合ルートは当該デバイスを手放します(クライアント版Windowsでは利用できません)。⁴

仮想化管理スタック

VMの作成・起動・停止を司るVMMS(仮想マシン管理サービス)や、VM1台ごとに立ち上がるワーカープロセス(vmwp.exe)は、ルートパーティションのユーザーモードで動きます。⁵ これらはHyper-VのVM管理機能の一部なので、VBSやWSL2のためにハイパーバイザーだけが動いているホストでは存在しないことがあります。

子パーティションの作成権

ルートパーティションは、ハイパーコールAPI(ハイパーバイザーへの呼び出しインターフェイス)を通じて子パーティションを作ります。²

この設計には理由があります。あらゆるデバイスドライバーをハイパーバイザー本体に入れると、ハイパーバイザーが巨大化し、不具合や攻撃の入口も増えます。ハイパーバイザーは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またはハイパーバイザー経由でルートパーティションへ転送されます。²

一方、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. メモリから見る ── アドレス変換がもう一段増える

メモリでは、ゲストが「物理」と考えるアドレスと、実際のRAM上の位置を分けます。GVA → GPA → SPAの順と、各変換の管理者を押さえてください。

4.1. 3種類のアドレス

メモリ連載の第1回では、仮想アドレスがページテーブルを経て物理アドレスへ変換される流れを追いました(「仮想アドレスが物理RAMに変わる瞬間」)。仮想化環境では、この変換の下にもう一段が加わり、アドレスは3種類になります。

アドレス	略称	誰が管理するか
ゲスト仮想アドレス	GVA	ゲストOSのページテーブル
ゲスト物理アドレス	GPA	ゲストOSが「物理」と信じているアドレス
システム物理アドレス	SPA	ハイパーバイザー(実際のRAM上の位置)

ゲストOSは自分のページテーブルでGVAからGPAへ変換します。しかしゲストが見ているGPAは本当の物理アドレスではなく、各パーティション専用の私的なメモリ空間です。² GPAを実際のRAM上の位置(SPA)へ対応付けるのは、ハイパーバイザーの仕事です。

4.2. SLAT ── 二段変換をハードウェアで

この二段目の変換をソフトウェアだけで行うと、ゲストのページテーブル更新をハイパーバイザーが逐一追跡する必要があり、性能面で現実的ではありません。そこでCPUには、二段目の変換表をハードウェアで引く仕組みが用意されています。これがSLAT(Second Level Address Translation)で、Intel EPT(拡張ページテーブル)やAMD RVIが該当します。

現行のHyper-Vは、SLAT対応の64bitプロセッサを必須要件としています。⁴

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種類のデバイス

デバイスI/Oは、CPU時間やメモリ変換とは経路が違います。実在ハードウェアを模倣する方法と、仮想化専用の通路を使う方法を比べます。

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つです。²

VMBus:パーティション間の論理的な通信チャネル。共有メモリを利用した高速なパーティション間通信を提供します。³
VSP(Virtualization Service Provider):ルートパーティション側に常駐し、子からのデバイス要求を受けてルート側のデバイス/バックエンドのスタックへ橋渡しするサービス。要求は物理デバイスへ届くことも、仮想ディスクや仮想スイッチなどホスト側のバックエンドで処理されることもあります。
VSC(Virtualization Service Consumer):子パーティション側のゲストOSに入る合成デバイスドライバー。要求をVMBus経由でVSPへ送ります。

例: ゲストのWriteFileがホストへ届くまで

ゲストOSのストレージ要求は、次の順に流れます。

ゲストアプリのWriteFileが、ゲストカーネルのI/Oスタックを降ります。
最下層で、実在ハードウェアの代わりにVSCへ到達します。
VSCが要求をVMBusに載せ、ルートパーティションのVSPへ渡します。
VSPがルート側のI/Oスタックへ要求を流します。仮想ディスク(VHDX)構成なら、ホスト上のVHDXファイルへの書き込みとして処理され、最終的に物理ディスクへ届きます。

この方式はEnlightened I/O(仮想化を自覚したI/O)と呼ばれ、デバイスエミュレーションの層を迂回することで効率を上げています。²

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を使わない人にも他人事ではない理由

6.1. VBS・WSL2・Sandboxも同じ土台を使う

ここまでの構造は、「VMを立てる人の話」に見えるかもしれません。しかし冒頭のとおり、現在のWindowsではハイパーバイザーは日常の一部です。

仮想化ベースのセキュリティ(VBS)。 Windowsハイパーバイザーを使って隔離環境を作り、そこにセキュリティ機能を収容します。Windows 11では、対応ハードウェアへのクリーンインストールなど条件を満たす場合に既定で有効です。¹ 詳細は第2回で扱います。
WSL2。 軽量ユーティリティVMの中で本物のLinuxカーネルを動かします。⁶
Windows Sandbox。 ハイパーバイザーで分離された使い捨てのWindows環境です。⁷ どちらも第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を使う人の話」という前提がこの図で崩れる。

6.2. 他社製仮想化ソフトとの共存

もう1つ、実務でよく踏むのが他社製仮想化ソフトとの共存です。CPUの仮想化支援機能はハイパーバイザーが排他的に使うため、Windowsハイパーバイザーが動いている環境では、VirtualBoxなどが従来方式(自前でCPUの仮想化支援を使う方式)で動けません。

このためにWindows Hypervisor Platformという公開APIが用意されており、他社製の仮想化スタックはWindowsハイパーバイザーの上に載る形で動作できます。⁸ 現行の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でハイパーバイザーが動いているかどうかは、手元で確認できます。

7.1. PowerShellでハイパーバイザーとVBSを確認する

まず、管理者権限なしで実行できる確認です。

# ハイパーバイザーの上で動いているか
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

# VBSの状態(msinfo32の「仮想化ベースのセキュリティ」と同じ情報源)
Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard `
    -ClassName Win32_DeviceGuard |
    Select-Object VirtualizationBasedSecurityStatus

VirtualizationBasedSecurityStatusは、VBSの動作状態を数値で返します(2が「実行中」)。⁹

1つ注意があります。HypervisorPresentが示すのは「ハイパーバイザーの上で動いているか」だけで、ルートか子かは区別しません。VMの中のWindowsで実行しても、子パーティションとしてTrueが返ります。物理PC上のWindowsでTrueなら、そのWindowsはルートパーティションの中にいる──と、実行環境と合わせて読みます。

7.2. systeminfoで「動作中」と「事前要件」を読み分ける

次に、コマンドプロンプトからの定番です。

systeminfo

出力末尾の「Hyper-Vの要件」を見ます。ハイパーバイザーがまだ動いていないマシンでは、SLAT対応・仮想化支援の有効/無効などの要件が個別に表示されます。すでにハイパーバイザーが動いているマシンでは、要件の代わりに「ハイパーバイザーが検出されました。Hyper-Vに必要な機能は表示されません。」と1行だけ表示されます。⁴

つまりこの1行は、あなたのWindowsが何らかのハイパーバイザーの上で動いていることの表明です。HypervisorPresentと同じく、物理PCならルートパーティションの中、VMの中なら子パーティションとして、という読み分けが要ります。

systeminfoの要件がすべて「はい」でも、それはハードウェア側の準備が整っているという意味です。Hyper-Vの機能自体はPro・Enterprise・Educationエディションで利用でき、Homeにはありません。¹⁰

7.3. 画面で見るときも、確認している項目を区別する

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はルートパーティションとして動きます。²
ゲストOSのカーネルはリング0のまま動き、介入対象として設定された操作や例外だけがVM Exitでハイパーバイザーに渡ります。通常のメモリアクセスはSLATの変換で素通りします。
ルートパーティションだけが物理デバイスドライバーと仮想化管理スタックを持ち、ハイパーコールで子パーティションを作ります。²
メモリはGVA→GPA→SPAの二段変換になり、二段目はSLAT(EPT/RVI)がハードウェアで担います。現行Hyper-VはSLAT必須です。⁴
デバイスI/Oは、VSC→VMBus→VSPという合成デバイスの経路が主役で、性能はホスト側のI/Oスタックにも依存します。²
Windows 11では、クリーンインストールなど条件を満たすデバイスで既定有効になるVBSにより、VMを使わないPCでもハイパーバイザーが動いていることが珍しくありません。¹ 動作状態は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がどう作っているのかを追います。

参考リンク

Microsoft Learn, Silicon assisted security. VBSがハードウェア仮想化を使ってセキュアカーネルを通常のOSから分離すること、Windows 11の新規インストールでは前提条件を満たすデバイスでVBSとHVCIが既定で有効になることについて。 ↩ ↩² ↩³
Microsoft Learn, Hyper-V Architecture. ハイパーバイザーが分離単位としてパーティションを提供すること、ルートパーティションがハイパーコールAPIで子パーティションを作ること、パーティションが物理プロセッサに直接アクセスせず私的な仮想メモリ空間で動くこと、VMBus・VSP・VSC・Enlightened I/Oの役割、およびハードウェア仮想化支援(Intel VT/AMD-V)が必須であることについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹²
Microsoft Learn, Hyper-V architecture (Performance Tuning). Hyper-VがType 1ハイパーバイザーであること、ルートパーティションが物理I/Oデバイスを所有すること、VMBusが共有メモリを利用した高性能なパーティション間通信を提供することについて。 ↩ ↩²
Microsoft Learn, System requirements for Hyper-V on Windows and Windows Server. SLAT対応の64bitプロセッサとVMモニターモード拡張が必須であること、systeminfoの「Hyper-Vの要件」欄で要件の充足を確認できること、およびハイパーバイザー動作中は「ハイパーバイザーが検出されました」と表示されること、ディスクリートデバイス割り当てで特定デバイスを子パーティションへ直接割り当てられることについて。 ↩ ↩² ↩³ ↩⁴
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アプリ開発

業務アプリ、装置連携、通信ツールなどの 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経由)を持っており、最新版どうしの組み合わせであれば共存できます。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ブログ一覧に戻る