第1章: 仮想化理論とオペレーティングシステムの抽象化 - 計算機仮想化の計算機科学的基盤
1.1 仮想化の理論的基礎
1.1.1 仮想化問題の歴史的背景
コンピュータの黎明期と資源の希少性
1950年代から1960年代初頭、コンピュータは極めて高価で希少な資源でした。IBM 704（1954）やIBM 7094（1962）といった大型計算機は、数百万ドルの価値があり、大学や大企業でさえ1台しか所有できませんでした。
この時代の深刻な問題はバッチ処理システムの非効率性でした：
バッチ処理の流れ（1950年代）：
1. プログラマがパンチカードにプログラムを記録
2. カードをオペレータに提出
3. オペレータがカードを読み込ませて実行
4. 結果が出るまで数時間〜数日待機
5. エラーがあれば最初からやり直し
問題：
- CPU使用率が極めて低い（典型的に10-30%）
- I/O待ちの間、高価なCPUがアイドル状態
- プログラマの生産性が低い
タイムシェアリング構想の誕生
1959年、John McCarthyはMITでタイムシェアリング（時分割処理）の概念を提唱しました。これは、複数のユーザーが1台のコンピュータを「同時に」使用できるというアイデアでした。
タイムシェアリングの原理：
時間軸 →
┌────┬────┬────┬────┬────┬────┐
│ A │ B │ C │ A │ B │ C │ ...
└────┴────┴────┴────┴────┴────┘
↑
時間量子（タイムスライス）
各ユーザー（A, B, C）に短い時間を順番に割り当て
人間の反応速度より速く切り替え → 各自が専用機を持つ錯覚
McCarthyの洞察（1959）：
「コンピューティングは電気やガスと同様のユーティリティとなるべきである。各ユーザーは専用の仮想マシンを持っているかのように感じるべきだ。」
この予言は、現代のクラウドコンピューティング（AWS、Azure、GCP）で現実となりました。
1.1.2 CTSS：最初のタイムシェアリングシステム
MIT Compatible Time-Sharing System（1961-1963）
Fernando J. Corbatóと彼のチームは、MITでCTSS（Compatible Time-Sharing System）を開発しました。これは世界初の本格的なタイムシェアリングシステムでした。
CTSSの革新的な特徴：
- マルチユーザー対話型操作
- 保護メカニズム
- 階層的ファイルシステム
CTSSの技術的課題と解決策：
課題1：メモリ保護
解決策：ハードウェアによるベース/リミットレジスタ
ベースレジスタ リミットレジスタ
↓ ↓
┌────────┬───────────────┬────────┐
│ OS領域 │ ユーザー領域 │ 他ユーザー│
└────────┴───────────────┴────────┘
↑ ↑
プロセスの プロセスの
開始アドレス 終了アドレス
アクセス範囲外 → ハードウェア例外
課題2：コンテキストスイッチ
解決策：レジスタ状態の保存と復元
プロセスAの状態保存：
- プログラムカウンタ（PC）
- 汎用レジスタ
- スタックポインタ
- プロセッサステータスワード
プロセスBの状態復元：
- 保存されていたB の状態をロード
- 実行再開
Corbatóは、CTSSの開発により1990年にチューリング賞を受賞しました。
1.1.3 IBM CP/CMS：真の仮想マシンの誕生
仮想マシンの概念的飛躍
1960年代中盤、IBMのケンブリッジ科学センターでCP-40（Control Program-40）の開発が始まりました。このプロジェクトは、タイムシェアリングを超えた革命的なアプローチを採用しました。
CP/CMSの設計思想：
タイムシェアリングが「CPUを共有」するのに対し、CP/CMSはコンピュータ全体を仮想化しました。
タイムシェアリング vs 仮想マシン
タイムシェアリング： 仮想マシン（CP/CMS）：
┌─────────────────┐ ┌─────────────────┐
│ 単一OS │ │ CP（制御プログラム）│
├─────────────────┤ ├────┬────┬────────┤
│ P1 P2 P3 P4 │ │VM1 │VM2 │VM3 │
└─────────────────┘ │CMS │CMS │CMS │
└────┴────┴────────┘
↑ ↑
OSが複数プロセスを管理 各VMが完全なコンピュータ
各VMで独自のOSが動作
CP/CMS（1967）の革新：
- 完全な仮想化
- CMSの効率性
Robert Creasyの貢献：
CP-40の主要設計者Robert Creasyは、仮想マシンの基本原則を確立しました：
「ゲストオペレーティングシステムには、自分が物理ハードウェア上で直接実行されているかのように見えなければならない。」
1.1.4 Popek-Goldberg仮想化要件
形式的な仮想化理論の確立
1974年、Gerald J. PopekとRobert P. Goldbergは、論文「Formal Requirements for Virtualizable Third Generation Architectures」で、仮想化可能なアーキテクチャの形式的条件を定義しました。
三つの基本要件：
1. 等価性（Equivalence / Fidelity）
仮想マシン上のプログラムは、物理マシン上と本質的に同じ動作をする
∀ プログラム P:
Execute(P, PhysicalMachine) ≈ Execute(P, VirtualMachine)
（タイミングとリソース制限を除く）
2. 効率性（Efficiency / Performance）
大部分の命令は直接ハードウェアで実行される
VMM介入なしに実行される命令 >> VMM介入が必要な命令
3. リソース制御（Resource Control / Safety）
VMMはすべてのハードウェアリソースを完全に制御する
ゲストVMは割り当てられたリソース以外にアクセス不可
センシティブ命令と特権命令
Popek-Goldbergは、命令を以下のように分類しました：
命令の分類：
1. 非特権命令（User Mode命令）
- 通常の計算命令（ADD, MUL, etc.）
- ユーザーモードで実行可能
2. 特権命令（Privileged Instructions）
- カーネルモードでのみ実行可能
- ユーザーモードで実行 → トラップ発生
例：I/O命令、ページテーブル操作
3. センシティブ命令（Sensitive Instructions）
a. 制御センシティブ：システム状態を変更
例：割り込み有効化/無効化
b. 動作センシティブ：現在のモードに依存して動作が変わる
例：PSW（プロセッサステータスワード）の読み取り
Popek-Goldbergの定理：
仮想化可能条件：
センシティブ命令の集合 ⊆ 特権命令の集合
言い換えると：
すべてのセンシティブ命令がトラップを発生させる
→ VMMがそれらを適切にエミュレート可能
→ 安全で効率的な仮想化が可能
x86アーキテクチャの問題
1970年代から2000年代初頭まで、x86アーキテクチャはPopek-Goldberg条件を満たしていませんでした。
x86のセンシティブだが非特権な命令の例：
POPF（Pop Flags）:
- スタックからフラグレジスタにPOP
- IF（割り込みフラグ）を含む
- ユーザーモードでは特定のフラグ変更がサイレントに無視される
- トラップが発生しない → VMMが検知できない
SGDT/SIDT（Store GDT/IDT）:
- グローバル/割り込みディスクリプタテーブルのアドレスを読み取り
- ユーザーモードで実行可能
- ゲストがホストの内部構造を検出可能
この問題の解決には、バイナリ変換（VMware）またはハードウェア仮想化支援（Intel VT-x、AMD-V）が必要でした。
1.2 ハイパーバイザの理論
1.2.1 ハイパーバイザの定義と分類
ハイパーバイザ（VMM：Virtual Machine Monitor）は、仮想マシンを作成・実行するためのソフトウェア層です。
Type 1 ハイパーバイザ（ベアメタル型）
ハードウェア上で直接実行され、その上でゲストOSを動作させます。
┌─────────┬─────────┬─────────┐
│ Guest │ Guest │ Guest │
│ OS 1 │ OS 2 │ OS 3 │
├─────────┴─────────┴─────────┤
│ Type 1 Hypervisor │
│ (VMware ESXi, Xen) │
├─────────────────────────────┤
│ Hardware │
└─────────────────────────────┘
特徴：
- 高いパフォーマンス
- 企業データセンター向け
- 複雑な管理インターフェース
Type 2 ハイパーバイザ（ホスト型）
既存のOS上でアプリケーションとして動作します。
┌─────────┬─────────┐
│ Guest │ Guest │
│ OS 1 │ OS 2 │
├─────────┴─────────┤
│ Type 2 Hypervisor│
│ (VirtualBox) │
├───────────────────┤
│ Host OS │
│ (macOS, Linux) │
├───────────────────┤
│ Hardware │
└───────────────────┘
特徴：
- セットアップが容易
- 個人開発者向け
- Born2berootで使用
1.2.2 Trap-and-Emulate方式
古典的な仮想化手法で、CP/CMSで確立されました。
動作原理：
1. ゲストOSが特権命令を実行しようとする
2. CPUがトラップ（例外）を発生
3. 制御がVMMに移行
4. VMMが命令の効果をエミュレート
5. ゲストOSに制御を返す
例：ゲストがCLI（割り込み無効化）を実行
ゲストOS VMM
│ │
│ CLI命令実行 │
│ ─────────→ トラップ │
│ │
│ ┌─────────────┤
│ │ 仮想割り込み│
│ │ フラグ更新 │
│ └─────────────┤
│ │
│ ←───────── 制御復帰 │
▼ ▼
効率性の分析：
オーバーヘッド = トラップ頻度 × トラップ処理時間
典型的なトラップコスト: 100-1000 CPUサイクル
非トラップ命令: 1-10 CPUサイクル
効率的な仮想化の条件：
トラップ発生する命令 << 全命令数
1.2.3 バイナリ変換（Binary Translation）
VMwareが1998年に商用化した手法。x86のPopek-Goldberg問題を解決しました。
動作原理：
1. ゲストコードをブロック単位で解析
2. センシティブ命令を検出
3. 安全な等価コードに変換
4. 変換したコードを実行
5. 変換結果をキャッシュして再利用
変換例：
元のゲストコード：
POPF ; センシティブ（非トラップ）
変換後のコード：
MOV [saved_eflags], eax ; 一時保存
CALL vmm_handle_popf ; VMMが処理
; VMMが仮想フラグを更新
; 必要なら実際のフラグを変更
変換コードキャッシュ：
Translation Cache（変換キャッシュ）：
┌─────────────────────────────────────┐
│ ゲストアドレス │ 変換コードへのポインタ │
├─────────────────┼───────────────────────┤
│ 0x401000 │ → 変換済みブロック1 │
│ 0x401050 │ → 変換済みブロック2 │
│ 0x401100 │ → 変換済みブロック3 │
└─────────────────┴───────────────────────┘
利点：
- 一度変換すれば再利用可能
- 頻繁に実行されるコードは高速
1.2.4 ハードウェア仮想化支援
Intel VT-x（Vanderpool Technology, 2005）とAMD-V（Pacifica, 2006）は、CPUレベルでの仮想化支援を提供しました。
VT-xの新しい動作モード：
従来のx86：
┌─────────────────────────────────────┐
│ Ring 0（カーネル） │
├─────────────────────────────────────┤
│ Ring 1 │
├─────────────────────────────────────┤
│ Ring 2 │
├─────────────────────────────────────┤
│ Ring 3（ユーザー） │
└─────────────────────────────────────┘
VT-x導入後：
┌─────────────────────────────────────┐
│ VMX Root Mode（ホスト/VMM） │
│ ┌─────────────────────────────────┐│
│ │ Ring 0-3 ││
│ └─────────────────────────────────┘│
├─────────────────────────────────────┤
│ VMX Non-Root Mode（ゲスト） │
│ ┌─────────────────────────────────┐│
│ │ Ring 0-3（仮想化） ││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘
ゲストのRing 0は「真の」Ring 0ではない
センシティブ命令 → 自動的にVM Exit
VMCS（Virtual Machine Control Structure）：
VMCSは各仮想CPUの状態を管理するデータ構造：
┌─────────────────────────────────────┐
│ VMCS │
├─────────────────────────────────────┤
│ ゲスト状態領域： │
│ - レジスタ（RAX, RBX, ...） │
│ - セグメントレジスタ │
│ - CR0, CR3, CR4（制御レジスタ） │
│ - EFLAGS │
├─────────────────────────────────────┤
│ ホスト状態領域： │
│ - VM Exitで復元されるホストの状態 │
├─────────────────────────────────────┤
│ VM実行制御： │
│ - どの操作でVM Exitを発生させるか │
│ - 割り込み処理の制御 │
├─────────────────────────────────────┤
│ VM Exit情報： │
│ - 終了理由 │
│ - 詳細情報 │
└─────────────────────────────────────┘
1.3 メモリ仮想化の理論
1.3.1 仮想メモリと二重のアドレス変換
現代のOSは仮想メモリを使用します。仮想化環境では、アドレス変換が二重になります。
物理マシンでのアドレス変換：
仮想アドレス ───→ 物理アドレス
(VA) ページテーブル (PA)
仮想化環境でのアドレス変換：
ゲスト仮想アドレス ───→ ゲスト物理アドレス ───→ ホスト物理アドレス
(GVA) ゲストページ (GPA) ネスト化ページ (HPA)
テーブル テーブル
略記：
GVA: Guest Virtual Address
GPA: Guest Physical Address（実際には存在しない）
HPA: Host Physical Address（実際の物理メモリ）
1.3.2 シャドウページテーブル
ソフトウェアによるメモリ仮想化の古典的手法：
シャドウページテーブルの構造：
ゲストが認識するページテーブル（偽物）：
┌────────┬────────┐
│ GVA │ GPA │
├────────┼────────┤
│ 0x1000 │ 0x5000 │
│ 0x2000 │ 0x6000 │
└────────┴────────┘
↑
ゲストOSが管理
VMMが管理するシャドウページテーブル（本物）：
┌────────┬────────┐
│ GVA │ HPA │
├────────┼────────┤
│ 0x1000 │ 0x8000 │ ← 実際の物理アドレス
│ 0x2000 │ 0x9000 │
└────────┴────────┘
↑
VMMが生成・維持
動作：
1. ゲストがページテーブルを更新
2. VMMがその変更を検知
3. シャドウページテーブルを同期更新
4. 実際のCR3はシャドウを指す
オーバーヘッド：
シャドウページテーブルは高コストでした：
- ページテーブル更新のたびにVM Exit
- TLBフラッシュが頻繁
- メモリオーバーヘッド（シャドウコピー）
1.3.3 Extended Page Tables（EPT/NPT）
ハードウェア支援によるメモリ仮想化：
Intel EPT / AMD NPT：
GVA ───→ GPA ───→ HPA
ゲストPT EPT
（ゲスト （ハードウェア
管理） 管理）
EPTの動作：
1. ゲストがメモリアクセス
2. MMUがゲストページテーブルを参照 → GPA取得
3. MMUがEPTを参照 → GPA→HPA変換
4. 物理メモリにアクセス
利点：
- ページテーブル更新でVM Exitが不要
- VMMの介入が大幅に減少
- 30-50%の性能向上（メモリ集約型ワークロード）
欠点：
- TLBミス時のページウォークが2段階
- TLBミスのコストが増加
1.4 I/O仮想化の理論
1.4.1 I/O仮想化の課題
I/Oデバイスの仮想化は特に困難です：
課題：
1. デバイスの多様性
- 何千種類のハードウェアデバイス
- 各デバイス固有のインターフェース
2. 高い性能要求
- ネットワーク：低レイテンシ、高スループット
- ストレージ：高IOPS、大帯域幅
3. 共有とアイソレーション
- 複数VMでのデバイス共有
- VM間のセキュリティ分離
1.4.2 I/O仮想化の方式
1. 完全エミュレーション
ゲストOS
↓ (デバイスへのアクセス)
VM Exit
↓
VMM（デバイスエミュレータ）
↓ (実デバイスへの変換)
物理デバイス
例：QEMU
- 完全な互換性
- 低いパフォーマンス
- 各I/O操作でVM Exit
2. 準仮想化（Para-virtualization）
ゲストOS（修正済み）
↓ (準仮想化インターフェース)
VMM（高効率バックエンド）
↓
物理デバイス
例：Virtio
- ゲストOSの修正が必要
- 高いパフォーマンス
- バッチ処理でオーバーヘッド削減
3. SR-IOV（Single Root I/O Virtualization）
VM1 VM2 VM3
↓ ↓ ↓
VF1 VF2 VF3
│ │ │
└────────────┴────────────┘
│
PF（Physical Function）
│
物理NIC
VF: Virtual Function（軽量な仮想デバイス）
PF: Physical Function（本体デバイス）
- ハードウェアレベルでの仮想化
- ネイティブに近いパフォーマンス
- 高価なハードウェアが必要
1.5 オペレーティングシステムの抽象化
1.5.1 保護リングとプロセッサモード
現代のCPUは複数の保護レベル（リング）を提供：
x86の保護リング：
┌─────────────────────────────────────┐
│ Ring 0 │
│ （カーネルモード） │
│ OSカーネル、デバイスドライバ │
│ 全命令実行可能、全メモリアクセス可 │
├─────────────────────────────────────┤
│ Ring 1 │
│ （使用されず） │
├─────────────────────────────────────┤
│ Ring 2 │
│ （使用されず） │
├─────────────────────────────────────┤
│ Ring 3 │
│ （ユーザーモード） │
│ アプリケーション │
│ 制限された命令、制限されたメモリ │
└─────────────────────────────────────┘
実際の使用（現代のOS）：
- Ring 0：カーネル
- Ring 3：ユーザープログラム
- Ring 1,2：通常使用されない
仮想化でのリング圧縮（Ring Compression）：
- ゲストカーネル：Ring 1または Ring 3
- VMMがRing 0を占有
1.5.2 システムコールのメカニズム
ユーザープログラムがカーネル機能を利用するためのインターフェース：
システムコールの流れ：
ユーザープログラム（Ring 3）
│
▼ write(fd, buf, count)
│
│ ライブラリ関数（libc）
│ - 引数をレジスタにセット
│ - システムコール番号をEAX
│ - SYSCALL命令実行
│
▼ ──────── Ring 3 → Ring 0 ────────
│
│ カーネル（Ring 0）
│ - システムコールハンドラ
│ - 引数の検証
│ - 実際の処理実行
│ - 結果をレジスタに設定
│ - SYSRET命令で復帰
│
▼ ──────── Ring 0 → Ring 3 ────────
│
ユーザープログラム（Ring 3）
│ 結果を受け取る
セキュリティ境界：
Ring 3（ユーザー空間）の制限：
- 特権命令を実行できない
- カーネルメモリにアクセスできない
- 他のプロセスのメモリにアクセスできない
- I/Oポートに直接アクセスできない
これらの制限はハードウェアが強制
違反 → 例外発生 → カーネルが処理
1.5.3 カーネルとユーザー空間の分離
プロセスのアドレス空間（64-bit Linux）：
0x0000000000000000
↓
┌─────────────────────────────────────┐
│ ユーザー空間 │
│ │
│ Text（コード） │
│ Data（グローバル変数） │
│ Heap（動的メモリ） │
│ ↓ │
│ ... │
│ ↑ │
│ Stack（スタック） │
│ │
├─────────────────────────────────────┤ 0x00007FFFFFFFFFFF
│ 無効領域（Non-canonical） │
├─────────────────────────────────────┤ 0xFFFF800000000000
│ │
│ カーネル空間 │
│ │
│ カーネルコード │
│ カーネルデータ │
│ ダイレクトマップ（全物理メモリ） │
│ │
└─────────────────────────────────────┘ 0xFFFFFFFFFFFFFFFF
ユーザー空間：各プロセスで独立
カーネル空間：全プロセスで共有（ただしアクセス不可）
1.6 Born2berootへの理論の適用
1.6.1 VirtualBoxの技術的位置づけ
VirtualBoxは以下の技術を使用するType 2ハイパーバイザです：
VirtualBoxの仮想化戦略：
1. ハードウェア仮想化（優先）
- VT-x/AMD-Vが利用可能な場合
- VMCS/VMCBによる効率的な制御
- EPT/NPTによるメモリ仮想化
2. ソフトウェア仮想化（フォールバック）
- ハードウェア支援がない場合
- Ring圧縮とバイナリ変換
- シャドウページテーブル
VirtualBoxのアーキテクチャ：
┌─────────────────────────────────────────────────┐
│ VirtualBox GUI │
├─────────────────────────────────────────────────┤
│ VBoxSVC（サービス） │
├─────────────────────────────────────────────────┤
│ VBoxManage │ VBoxHeadless │ VirtualBox │
├──────────────┴──────────────┴───────────────────┤
│ VMM Core（リング0） │
├─────────────────────────────────────────────────┤
│ VirtualBox Drivers │
│ - vboxdrv（メインドライバ） │
│ - vboxnetflt（ネットワークフィルタ） │
│ - vboxnetadp（ホストオンリーアダプタ） │
├─────────────────────────────────────────────────┤
│ Host OS │
└─────────────────────────────────────────────────┘
1.6.2 システム要件の理論的根拠
CPU仮想化支援の確認：
# Linux での確認
grep -E 'vmx|svm' /proc/cpuinfo
# macOS での確認
sysctl -a | grep machdep.cpu.features | grep -i vmx
# 結果の意味
# vmx: Intel VT-x が有効
# svm: AMD-V が有効
# なし: ソフトウェア仮想化にフォールバック（低速）
メモリ要件の根拠：
仮想化のメモリオーバーヘッド：
1. VMM自体のメモリ使用
- VirtualBox: 約50-100MB
2. ゲストメモリ
- Born2beroot最小: 512MB
- 推奨: 1024MB
3. 追加オーバーヘッド
- EPT/シャドウページテーブル: ゲストメモリの1-3%
- デバイスエミュレーション: 数十MB
推奨構成（ホスト8GBの場合）：
ホストOS: 4GB
ゲストVM: 2GB
予備: 2GB
1.6.3 VirtualBoxのインストール
理論的背景を踏まえたセットアップ：
# macOS（Homebrew使用）
brew install --cask virtualbox
# インストール後の確認
VBoxManage --version
# カーネル拡張の確認（macOS）
kextstat | grep -i virtualbox
# 期待される出力
# com.oracle.vbox.kext.VBoxDrv (X.X.X)
# com.oracle.vbox.kext.VBoxNetAdp (X.X.X)
# com.oracle.vbox.kext.VBoxNetFlt (X.X.X)
# com.oracle.vbox.kext.VBoxUSB (X.X.X)
1.6.4 仮想マシンの作成
# コマンドラインでのVM作成
VBoxManage createvm --name "Born2beroot" --ostype "Debian_64" --register
# メモリ設定（理論：2^10 MB = 1GB）
VBoxManage modifyvm "Born2beroot" --memory 1024
# CPU設定（VT-x/AMD-V使用）
VBoxManage modifyvm "Born2beroot" --cpus 2
# ネスト化ページング有効化（EPT/NPT）
VBoxManage modifyvm "Born2beroot" --nestedpaging on
# 仮想ディスク作成
VBoxManage createhd --filename "Born2beroot.vdi" --size 30720 --format VDI
# ストレージコントローラ追加
VBoxManage storagectl "Born2beroot" --name "SATA Controller" \
--add sata --controller IntelAhci
# ディスク接続
VBoxManage storageattach "Born2beroot" --storagectl "SATA Controller" \
--port 0 --device 0 --type hdd --medium "Born2beroot.vdi"
# ISOマウント
VBoxManage storageattach "Born2beroot" --storagectl "SATA Controller" \
--port 1 --device 0 --type dvddrive --medium debian-12.2.0-amd64-netinst.iso
1.6.5 仮想化設定の確認
# VM情報の詳細表示
VBoxManage showvminfo "Born2beroot" --details
# 重要な設定項目
# Hardware Virtualization:
# HM: on ← ハードウェア仮想化有効
# Nested Paging: on ← EPT/NPT有効
# VT-x unrestricted guest: on
# Memory:
# RAM size: 1024 MB
# State:
# Running (since...)
1.7 チェックポイント
1.7.1 理論的理解の確認
以下の概念を説明できることを確認してください：
仮想化の歴史と理論：
- [ ] タイムシェアリングと仮想マシンの違い
- [ ] Popek-Goldberg仮想化要件
- [ ] Type 1とType 2ハイパーバイザの違い
- [ ] Trap-and-Emulate方式の原理
ハードウェア仮想化：
- [ ] VT-x/AMD-Vの役割
- [ ] VMX Root/Non-Root モード
- [ ] EPT/NPTの目的
オペレーティングシステム：
- [ ] 保護リングの概念
- [ ] システムコールのメカニズム
- [ ] カーネル空間とユーザー空間の分離
1.7.2 実践的な準備の確認
セットアップ：
- [ ] VirtualBoxを正しくインストールした
- [ ] ハードウェア仮想化が有効になっている
- [ ] Debian ISOをダウンロードして検証した
- [ ] 仮想マシンを作成した
まとめ
本章では、Born2berootプロジェクトの技術的基盤として、仮想化理論の歴史と原理を学びました：
歴史的発展：
- 1960年代: タイムシェアリング（CTSS, Multics）
- 1967年: CP/CMS - 真の仮想マシンの誕生
- 1974年: Popek-Goldberg要件の形式化
- 1998年: VMwareによるバイナリ変換の商用化
- 2005-2006年: VT-x/AMD-Vによるハードウェア支援
核心的概念：
- 仮想化は「等価性」「効率性」「リソース制御」の三条件を満たす
- ハイパーバイザはハードウェアリソースを抽象化してVMに提供
- メモリ仮想化はシャドウページテーブルまたはEPT/NPTで実現
- オペレーティングシステムは保護リングで特権を分離
次章では、これらの仮想化技術の上でDebianをインストールし、LVMとディスク暗号化を設定します。