[仮想化] 01. 仮想化技術の基礎: Type 1 vs Type 2 ハイパーバイザー

はじめに
- 仮想化が重要な理由
ハイパーバイザーとは？
仮想化手法の比較
3つの仮想化手法の比較表
実践: KVMベースの仮想化確認
CPU特権レベル（Ring）構造
VM Exitとパフォーマンス
まとめ

はじめに

仮想化（Virtualization）は、物理ハードウェア上に複数の独立した仮想環境を作成する技術です。1台のサーバーで複数のOSを同時に実行でき、ハードウェアの利用率を最大化し、インフラ運用コストを削減できます。

仮想化が重要な理由

ハードウェア統合: 平均CPU利用率15〜20%の物理サーバーを60〜80%まで引き上げ
分離（Isolation）: 各VMは独立したカーネル、ファイルシステム、ネットワークスタックを保有
柔軟なプロビジョニング: 数分以内に新しいサーバー環境をデプロイ可能
スナップショットとマイグレーション: 障害復旧、無停止移行が容易
クラウドコンピューティングの基盤: AWS、Azure、GCPすべてが仮想化上で動作

ハイパーバイザーとは？

ハイパーバイザー（Hypervisor）は、仮想マシン（VM）を作成・管理するソフトウェア層です。VMM（Virtual Machine Monitor）とも呼ばれます。物理リソース（CPU、メモリ、ストレージ、ネットワーク）を抽象化して各VMに分配します。

Type 1 ハイパーバイザー（ベアメタル）

Type 1ハイパーバイザーはハードウェア上に直接インストールされます。ホストOSなしで動作するため、オーバーヘッドが少なくパフォーマンスに優れます。

+-------------------------------------------+
|   VM 1      |   VM 2      |   VM 3        |
|  (Ubuntu)   |  (Windows)  |  (CentOS)     |
+-------------------------------------------+
|          Type 1 Hypervisor                 |
|     (ESXi / Hyper-V / Xen)                |
+-------------------------------------------+
|          Physical Hardware                 |
|   (CPU, RAM, Storage, NIC)                |
+-------------------------------------------+

代表的なType 1ハイパーバイザー:

ハイパーバイザー	ベンダー	特徴
VMware ESXi	VMware(Broadcom)	エンタープライズ標準、vSphereエコシステム
Microsoft Hyper-V	Microsoft	Windows Serverに内蔵、AD統合
Xen	Linux Foundation	準仮想化のパイオニア、AWSの初期基盤
KVM	オープンソース(Red Hat)	Linuxカーネルモジュール、QEMUと連携

Type 2 ハイパーバイザー（ホスト型）

Type 2ハイパーバイザーは、ホストOS上で通常のアプリケーションのように実行されます。

+-------------------------------------------+
|   VM 1      |   VM 2      |   VM 3        |
|  (Ubuntu)   |  (Windows)  |  (Fedora)     |
+-------------------------------------------+
|          Type 2 Hypervisor                 |
|  (VirtualBox / VMware Workstation)        |
+-------------------------------------------+
|           Host OS (Windows/macOS/Linux)    |
+-------------------------------------------+
|          Physical Hardware                 |
|   (CPU, RAM, Storage, NIC)                |
+-------------------------------------------+

代表的なType 2ハイパーバイザー:

ハイパーバイザー	ベンダー	特徴
Oracle VirtualBox	Oracle	オープンソース、クロスプラットフォーム、無料
VMware Workstation	VMware(Broadcom)	プロフェッショナルデスクトップ仮想化
VMware Fusion	VMware(Broadcom)	macOS専用、Apple Silicon対応
Parallels Desktop	Parallels	macOS最適化、優れた統合機能

KVM: ハイブリッドアプローチ

KVM（Kernel-based Virtual Machine）は独特な位置を占めます。LinuxカーネルモジュールとしてLinux自体をType 1ハイパーバイザーに変換します。

+-------------------------------------------+
|   VM 1      |   VM 2      |   VM 3        |
|  (Ubuntu)   |  (Windows)  |  (Fedora)     |
+-------------------------------------------+
|     QEMU (Device Emulation / Management)  |
+-------------------------------------------+
|  Linux Kernel + KVM Module (Type 1-like)  |
+-------------------------------------------+
|          Physical Hardware                 |
|   (CPU + VT-x/AMD-V, RAM, Storage, NIC)  |
+-------------------------------------------+

kvm.koモジュールがCPUのハードウェア仮想化拡張（VT-x/AMD-V）を直接活用
ゲストCPU命令はハードウェアで直接実行（ネイティブに近い性能）
Linuxカーネルがプロセススケジューリング、メモリ管理、I/Oを担当
QEMUがデバイスエミュレーションとVM管理を提供
技術的にはType 1だが、完全なLinux OS内で動作するため「ハイブリッド」に分類

仮想化手法の比較

完全仮想化（Full Virtualization）

完全仮想化では、ゲストOSを修正なしでそのまま実行します。ハイパーバイザーがゲストの特権命令（privileged instructions）をインターセプトして変換します。

バイナリ変換（Binary Translation）方式:

Guest OS (Ring 1で実行)
    |
    v  特権命令の実行を試行
    |
Hypervisor (Ring 0)がトラップ
    |
    v  安全な命令に変換して実行
    |
Physical Hardware

ゲストOSの修正不要（Windows、Linuxなど全て対応）
バイナリ変換によるパフォーマンスオーバーヘッドが存在
VMwareの初期アプローチ

準仮想化（Paravirtualization）

準仮想化では、ゲストOSが仮想化環境で実行されていることを認識します。特権命令の代わりにハイパーコール（Hypercall）を使ってハイパーバイザーに直接リクエストします。

Guest OS (修正済み - Hypercallインターフェース搭載)
    |
    v  hypercall呼び出し (trapの代わりに直接通信)
    |
Hypervisor (リクエスト処理)
    |
    v
Physical Hardware

ゲストOSカーネルの修正が必要（Linux可能、通常のWindows不可）
オーバーヘッドが少なく完全仮想化より高パフォーマンス
Xenの初期方式、VirtIOドライバも準仮想化の概念を活用
VirtIOはネットワーク、ストレージなどI/Oデバイスの準仮想化標準

ハードウェア支援仮想化（Hardware-Assisted Virtualization）

2005〜2006年にIntelとAMDがCPUレベルで仮想化をサポートし始めました。

主要技術:

Intel VT-x（2005年）: VMX root/non-rootモードを導入
AMD-V（2006年）: SVM（Secure Virtual Machine）拡張
Ring -1の概念: ハイパーバイザー専用の特権レベルを追加
VT-d / AMD-Vi: IOMMUベースのDMAリマッピング、デバイスパススルー対応
EPT / NPT: 拡張ページテーブルによるメモリ仮想化のハードウェア高速化

+--------------------------------------------------+
|  Guest OS (Ring 3: User, Ring 0: Kernel)          |
|  --> VMX non-rootモードで実行                      |
+--------------------------------------------------+
|  Hypervisor (Ring -1 / VMX root mode)              |
|  --> VM Exit時のみ介入                             |
+--------------------------------------------------+
|  Hardware (VT-x/AMD-V, EPT/NPT, VT-d/AMD-Vi)     |
+--------------------------------------------------+

ゲストOS修正不要 + ネイティブに近いパフォーマンス
VM Exitの頻度によってパフォーマンスが変動
現代のすべてのx86仮想化の基盤技術

3つの仮想化手法の比較表

項目	完全仮想化	準仮想化	HW支援仮想化
ゲストOS修正	不要	必要	不要
CPUオーバーヘッド	高（バイナリ変換）	中（ハイパーコール）	低（HWトラップ）
I/Oパフォーマンス	エミュレーションで遅い	ハイパーコールで高速	VirtIO併用で最適
Windowsサポート	可能	カーネル修正が困難	可能
代表技術	VMware BT	Xen PV, VirtIO	VT-x, AMD-V
現在の利用状況	レガシー	I/O最適化に活用	主流方式

実践: KVMベースの仮想化確認

# CPUが仮想化をサポートしているか確認
# Intel VT-xの場合はvmx、AMD-Vの場合はsvmフラグを確認
grep -E '(vmx|svm)' /proc/cpuinfo | head -1

# KVMモジュールのロード確認
lsmod | grep kvm

# 出力例:
# kvm_intel            368640  0
# kvm                 1028096  1 kvm_intel

# libvirtを使ったVM作成例
virt-install \
  --name test-vm \
  --ram 2048 \
  --vcpus 2 \
  --disk size=20 \
  --os-variant ubuntu22.04 \
  --cdrom /path/to/ubuntu-22.04.iso

CPU特権レベル（Ring）構造

[HW仮想化以前]                    [HW仮想化以後]

Ring 3: ユーザーアプリ            Ring 3: ユーザーアプリ
Ring 2: (未使用)                  Ring 2: (未使用)
Ring 1: (Guest OS - 完全仮想化)   Ring 1: (未使用)
Ring 0: Hypervisor                Ring 0: Guest OS (non-root)
                                   Ring -1: Hypervisor (VMX root)

ハードウェア仮想化の導入により、ゲストOSがRing 0で正常に動作しつつ、ハイパーバイザーがより高い特権レベル（Ring -1）で制御できるようになりました。

VM Exitとパフォーマンス

ハードウェア支援仮想化では、ゲストが特定の操作を行うとCPUがVMX non-rootからrootモードに切り替わります。これをVM Exitと呼びます。

VM Exitが発生する主な状況:

I/Oポートアクセス
特定のMSR（Model-Specific Register）アクセス
割り込み処理
ページフォールト（EPT未使用時）
CPUID命令の実行

VM Exitは数百〜数千CPUサイクルを消費するため、頻度を減らすことがパフォーマンスの鍵です。VirtIOのような準仮想化ドライバがI/Oパスでのvm Exitを削減します。

[VM Exit処理フロー]

Guest実行 (non-root)
    |
    v  センシティブ命令を実行
    |
VM Exit (non-root -> root遷移, ~数百サイクル)
    |
    v  Hypervisorが命令を処理
    |
VM Entry (root -> non-root遷移)
    |
    v  Guest実行再開

まとめ

分類基準	Type 1	Type 2
インストール場所	ハードウェア直接	ホストOS上
パフォーマンス	高い	中程度
主な用途	サーバー仮想化、クラウド	開発、テスト
管理の複雑さ	高い	低い
代表製品	ESXi, Hyper-V, KVM	VirtualBox, VMware Workstation

仮想化は現代のクラウドインフラの基盤です。Type 1ハイパーバイザーはプロダクション環境で、Type 2はデスクトップ環境でそれぞれの役割を果たします。ハードウェア仮想化サポート（VT-x/AMD-V）の登場によりパフォーマンスオーバーヘッドが劇的に減少し、現在のクラウドコンピューティング時代が可能になりました。

クイズ: 仮想化基礎の理解度チェック

Q1. Type 1ハイパーバイザーとType 2ハイパーバイザーの最大の違いは何ですか？

Type 1はハードウェア上に直接インストールされホストOSがなく、Type 2は既存のホストOS上でアプリケーションとして実行されます。Type 1はオーバーヘッドが少なくプロダクション環境に適しています。

Q2. KVMが「ハイブリッド」に分類される理由は何ですか？

KVMはLinuxカーネルモジュールとしてLinux自体をType 1ハイパーバイザーに変換しますが、同時に完全なLinux OS環境内で動作します。そのためType 1の性能とType 2の利便性を兼ね備えています。

Q3. 準仮想化で使用する「ハイパーコール」とは何ですか？

ハイパーコールは、ゲストOSがハイパーバイザーに直接サービスを要求するインターフェースです。システムコールがカーネルにリクエストするのと同様に、ハイパーコールはハイパーバイザーにリクエストします。トラップ方式よりオーバーヘッドが少ないです。

Q4. Intel VT-xの「Ring -1」が解決する問題は何ですか？

以前はゲストOS（Ring 0）とハイパーバイザー（Ring 0）が同じ特権レベルで衝突していました。Ring -1（VMX rootモード）を導入してハイパーバイザーがより高い特権で動作し、ゲストOSはRing 0で正常に実行されます。

Q5. VirtIOがパフォーマンスを向上させる原理は何ですか？

VirtIOはI/Oデバイス（ネットワーク、ストレージ）の準仮想化標準で、ゲストOSが仮想化環境を認識し最適化されたパスでハイパーバイザーと通信します。これにより完全なハードウェアエミュレーションよりVM Exitが減少し、パフォーマンスが向上します。