試験項目 1.2 · CCNA-007

Hypervisor

Hypervisor 役割, ハードウェア抽象化, リソース割り当て, VM 分離, Guest OS 関係, Type 1 / Type 2 Hypervisor

このページのゴール

Hypervisorが物理ハードウェアとVirtual Machineの間で果たす役割を理解し、ハードウェアリソースの抽象化・割り当て・VM実行基盤としての機能を説明できるようにする。

このページで学ぶこと

Hypervisorの役割
ハードウェア抽象化
リソース割り当て
VM分離
Guest OSとの関係
Type 1 Hypervisor
Type 2 Hypervisor

仮想化では、1台の物理ホスト上で複数の仮想マシン（VM）を動作させることができます。

その中心となるソフトウェア層が、

ハイパーバイザー（Hypervisor）

です。

ハイパーバイザーは物理ホストが持つ、

CPU
メモリ
ストレージ
NIC

などのハードウェアリソースとVMの間に位置し、それらをVMが利用できる形へ抽象化・割り当てします。

CCNA 200-301 v2.0 Objective 1.2では、

ハイパーバイザー、仮想マシン（VM）、コンテナの役割と機能を説明できること

が要求されています。Page007ではそのうち、ハイパーバイザーを担当します。Cisco公式の現行試験範囲でもObjective 1.2はこの範囲を「説明（Describe）」として要求しています。

1. 仮想化とは

物理サーバーを1台用意したとします。

仮想化を使わない単純な構成では、

物理サーバー
      ↓
オペレーティングシステム（OS）
      ↓
アプリケーション

のように、1つの物理サーバー上で1つのOS環境を使用する構成があります。

仮想化では、1台の物理ホスト上に複数の独立した仮想マシン（VM）を作成できます。

物理ホスト
      ↓
ハイパーバイザー
  ├─ VM-A
  ├─ VM-B
  └─ VM-C

Ciscoも仮想化について、同じ物理マシン上で複数のVMを分離して並行動作させられるものとして説明しています。

2. 物理ホスト

ハイパーバイザーを理解するには、まず物理ホストを区別します。

物理ホストは実際のハードウェアです。

たとえば、

物理ホスト

CPU
メモリ
ストレージ
物理NIC

を持っています。

これらは実際に存在する有限のハードウェアリソースです。

ハイパーバイザーはリソースを無限に生み出すわけではありません。

基本構造は、

物理リソース
       ↓
ハイパーバイザーが管理
       ↓
VMへ利用可能な形で提供

です。

3. ハイパーバイザーはハードウェアとVMの間に位置する

ハイパーバイザーの基本的な役割を図にすると、

VM-A       VM-B       VM-C
 │          │          │
 └──────────┼──────────┘
            ↓
        ハイパーバイザー
            ↓
 ┌────────────────────┐
 │ 物理ハードウェア  │
 │ CPU                │
 │ メモリ             │
 │ ストレージ            │
 │ NIC                │
 └────────────────────┘

です。

ハイパーバイザーは、

物理ハードウェアリソースを管理し、複数VMが利用できる仮想化されたリソースとして提供するソフトウェア層

と考えます。

Ciscoの仮想化資料でも、ゲストVMはハイパーバイザーまたはVMマネージャーと呼ばれるソフトウェア層によって実行・管理されると説明されています。

4. ハイパーバイザーの主な役割

Page007で押さえるハイパーバイザーの役割は、大きく次の4つです。

① ハードウェアリソースを抽象化する

② リソースをVMへ割り当てる

③ VMを実行する基盤を提供する

④ VM同士を論理的に分離する

この4つを中心に理解すると、ハイパーバイザーとVMを混同しにくくなります。

5. ハードウェア抽象化

抽象化とは、物理ハードウェアの詳細をそのままゲストOS（Guest OS）へ見せるのではなく、VMが利用できる論理的なハードウェアとして扱えるようにすることです。

たとえば、

物理CPU
      ↓
ハイパーバイザー
      ↓
VMが利用するCPUリソース

という関係です。

同様に、

物理メモリ
物理ストレージ
物理NIC

もハイパーバイザーによってVMへ利用可能なリソースとして提供されます。

Ciscoは仮想マシン（VM）が独自の仮想ハードウェアとしてRAM、CPU、NICなどを持ち、OSがその仮想ハードウェアを利用する構造を説明しています。

6. 抽象化の目的

抽象化によって、ゲストOSは物理ホスト上のハードウェア構成をすべて直接管理する必要がなくなります。

概念的には、

ゲストOS
   ↓
仮想化されたリソース
   ↓
ハイパーバイザー
   ↓
物理ハードウェア

という階層になります。

重要なのは、

ゲストOS
      ↓
物理CPUを直接すべて制御

という構造ではないことです。

物理リソースとVMの間をハイパーバイザーが管理します。

7. リソース割り当て

ハイパーバイザーのもう1つの重要な役割が、

リソース割り当て

です。

1台の物理ホストに、

CPU
メモリ
ストレージ
NIC

があったとして、それらを複数のVMへ利用可能な形で提供します。

たとえば概念的には、

物理ホスト

CPU
メモリ
ストレージ
NIC

       ↓ ハイパーバイザー

VM-A
CPUリソース
メモリリソース
ストレージリソース
ネットワークリソース

VM-B
CPUリソース
メモリリソース
ストレージリソース
ネットワークリソース

という関係です。

8. CPUリソース

物理ホストには実際のCPUがあります。

ハイパーバイザーは、そのCPU 処理リソースをVMが利用できるよう管理します。

概念的には、

物理CPU
      ↓
ハイパーバイザー
      ↓
VM-AのCPUリソース
VM-BのCPUリソース
VM-CのCPUリソース

です。

Page007では、

CPU スケジューリングアルゴリズム
CPU 予約
CPU 上限
CPU オーバーコミット

などの詳細なリソース管理までは扱いません。

覚えるべきなのは、

物理CPUリソースをハイパーバイザーがVMへ提供する

という役割です。

9. メモリリソース

メモリも同じ考え方です。

物理メモリ
       ↓
ハイパーバイザー
       ↓
VM-A用メモリ
VM-B用メモリ
VM-C用メモリ

となります。

それぞれのVMは、自分に提供されたメモリリソースを利用してゲストOSやアプリケーションを動作させます。

ここでも、

VM-A
      ↓
物理メモリ全体を自由に管理

ではありません。

ハイパーバイザーが物理リソースを管理しています。

10. ストレージリソース

ストレージについても、

物理 / 共有ストレージ
          ↓
      ハイパーバイザー
          ↓
     VM用ストレージ

という関係で考えます。

VMから見るとディスクとして利用できるリソースが提供されます。

ただし、

データストア設計
SAN
ストレージプロトコル
仮想ディスク作成操作
シン / シックプロビジョニング

などの製品固有・詳細ストレージ設計はPage007の範囲外です。

ここでは、

ハイパーバイザーがVMへストレージリソースを利用可能な形で提供する

という役割を押さえます。

11. ネットワークリソース

物理ホストには物理NICがあります。

ハイパーバイザー環境では、VMもネットワーク通信を行う必要があります。

概念的には、

VM
 ↓
仮想化されたネットワークリソース
 ↓
ハイパーバイザー
 ↓
物理NIC
 ↓
物理ネットワーク

という関係になります。

ただし、

vNIC
仮想スイッチ
VMから物理ネットワークまでの詳細な経路
同一ホスト内VM通信

はPage008で扱います。

Page007では、

ネットワークリソースもハイパーバイザーがVMへ提供・仲介するリソースの1つ

という位置付けまでです。

12. ハイパーバイザーは物理リソースを「増やす」のではない

次のように考えると誤りです。

物理CPU = 1台分

ハイパーバイザーを入れる
      ↓
CPUが無限に増える

ハイパーバイザーはハードウェアリソースを論理的に扱いやすくしますが、

元の物理リソースそのものを無限に増加させるわけではありません。

複数VMは、物理ホストに存在するリソースをハイパーバイザーの管理下で利用します。

したがって、

仮想化
=
無制限なリソース

ではありません。

13. 複数VMを1台の物理ホストで動かす

仮想化の代表的な構造は、

物理ホスト
       ↓
ハイパーバイザー
  ├─ VM-A
  ├─ VM-B
  ├─ VM-C
  └─ VM-D

です。

Ciscoも仮想ハードウェアによって、複数の独立したVMを1台の物理サーバー上で動かせると説明しています。

これによって、物理サーバーをアプリケーションごとに1台ずつ用意する構成とは異なるリソース利用が可能になります。

14. サーバー統合

複数のワークロードを別々のVMとして1台の物理ホスト上で動作させることを考えます。

従来例

サーバー A
 └─ アプリA

サーバー B
 └─ アプリB

サーバー C
 └─ アプリC

仮想化すると、

物理ホスト
      ↓
ハイパーバイザー
  ├─ VM-A ─ アプリA
  ├─ VM-B ─ アプリB
  └─ VM-C ─ アプリC

のような構成が可能です。

これにより物理リソースを複数のワークロードで利用できます。

ただしPage007では、コスト計算やキャパシティプランニングまでは扱いません。

15. VMの分離

複数VMを同じ物理ホストで実行していても、

すべてのVMが1つのOSインスタンスとして動くわけではありません。

概念的には、

ハイパーバイザー

├─ VM-A
│   └─ ゲストOS A
│
├─ VM-B
│   └─ ゲストOS B
│
└─ VM-C
    └─ ゲストOS C

となります。

各VMは独立した実行環境として扱われます。

ハイパーバイザーはVM同士を論理的に分離します。

16. 「分離」は「物理ホストを共有しない」という意味ではない

VM同士が分離されていても、

VM-A
VM-B
VM-C

は同じ物理ホストの、

CPU
メモリ
ストレージ
NIC

などをハイパーバイザー経由で共有している場合があります。

したがって、

VMが分離されている
      ↓
完全に別物理サーバー

という意味ではありません。

正しくは、

同じ物理インフラ上でも、VMごとの論理的な実行環境として分離される

ということです。

17. VMの分離とリソース共有を両立する

仮想化の重要な特徴は、

物理リソースは共有
          ＋
VMの実行環境は分離

という2つを同時に実現することです。

たとえば、

物理CPU
物理メモリ
      ↓
ハイパーバイザー
  ├─ VM-A
  └─ VM-B

では、VM-AとVM-Bは同じ物理ホストのリソースを利用しています。

しかしゲストOSやアプリケーションの実行環境は別です。

18. ゲストOS

ゲストOSは、仮想マシン（VM）内部で動作するオペレーティングシステム（OS）です。

構造は、

物理ハードウェア
       ↓
ハイパーバイザー
       ↓
仮想マシン（VM）
       ↓
ゲストOS
       ↓
アプリケーション

です。

ゲストOSとハイパーバイザーは同じものではありません。

19. ハイパーバイザーとゲストOSの役割を区別する

ハイパーバイザーは、

物理リソースを管理
VMへリソースを提供
VMを実行
VMを分離

します。

ゲストOSは、

VM内部で動作
アプリケーション実行環境を提供

します。

整理すると、

要素	主な役割
物理ホスト	実際のハードウェアリソースを持つ
ハイパーバイザー	物理リソースを管理・抽象化しVMを実行
VM	ハイパーバイザー上で動作する論理的コンピューター
ゲストOS	VM内部で動作するオペレーティングシステム（OS）

20. ハイパーバイザーの下と上を判断する

CCNAでは構造図から役割を判断できることが重要です。

基本形は、

アプリケーション
     ↓
ゲストOS
     ↓
仮想マシン（VM）
     ↓
ハイパーバイザー
     ↓
物理ハードウェア

です。

したがって、

ゲストOS
↓
ハイパーバイザー

という順序では、ゲストOSがハイパーバイザー上で動作します。

ハイパーバイザーがゲストOSの内部アプリケーションとして必ず動作するわけではありません。

ただし後述するType 2では、ハイパーバイザーの下にホストOS（Host OS）が存在します。

21. ホストOSとゲストOSを混同しない

特にType 2ハイパーバイザーでは、

ホストOS

と、

ゲストOS

の両方が登場します。

基本構造は、

VM
└─ ゲストOS
      ↓
Type 2ハイパーバイザー
      ↓
ホストOS
      ↓
物理ハードウェア

です。

ホストOSは物理マシン側でハイパーバイザーを実行するOSです。

ゲストOSはVM内部で動作するOSです。

同じ「OS」でも位置と役割が異なります。

22. Type 1ハイパーバイザー

Type 1ハイパーバイザーは、基本モデルとして物理ハードウェア上で直接動作するハイパーバイザーです。

VM-A        VM-B
 │           │
ゲストOS A ゲストOS B
  \          /
   Type 1ハイパーバイザー
          ↓
   物理ハードウェア

ハイパーバイザーの下に、一般用途のホストOSを置く基本構造ではありません。

Type 1は、

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

と呼ばれることもあります。

23. Type 1で重要なのは「位置」

CCNAでType 1を判断するときは、

製品名よりも、

ハイパーバイザーが構成上どこにあるか

を見ます。

VM
 ↓
ハイパーバイザー
 ↓
物理ハードウェア

なら、Type 1の基本モデルです。

つまり、

物理ハードウェア
      ↓
ハイパーバイザー
      ↓
VM

という直接的な構造を識別します。

24. Type 2ハイパーバイザー

Type 2ハイパーバイザーは、一般用途のホストOS上で動作する基本モデルです。

VM-A        VM-B
 │           │
ゲストOS A ゲストOS B
  \          /
   Type 2ハイパーバイザー
          ↓
       ホストOS
          ↓
   物理ハードウェア

ハイパーバイザーと物理ハードウェアの間にホストOSがあります。

25. Type 1とType 2を比較する

観点	Type 1	Type 2
物理ハードウェア直上	ハイパーバイザー	ホストOS
ハイパーバイザーの下	物理ハードウェア	ホストOS
ホストOS	一般用途ホストOSを下に置く基本構造ではない	存在する
VM / ゲストOS	ハイパーバイザー上	ハイパーバイザー上

最も重要なのは、

ハイパーバイザーの下に
何があるか

です。

26. Type 1 / Type 2を図から識別する

構成A

ゲストOS
   ↓
VM
   ↓
ハイパーバイザー
   ↓
物理ハードウェア

→ Type 1

構成B

ゲストOS
   ↓
VM
   ↓
ハイパーバイザー
   ↓
ホストOS
   ↓
物理ハードウェア

→ Type 2

この位置関係を読めれば、基本的な識別ができます。

27. Type 1だからゲストOSがないわけではない

次の理解は誤りです。

Type 1ハイパーバイザー
      ↓
ゲストOSが存在しない

Type 1でも、ハイパーバイザー上のVMにはゲストOSがあります。

ゲストOS
   ↓
VM
   ↓
Type 1ハイパーバイザー
   ↓
物理ハードウェア

です。

Type 1 / Type 2の違いは、

VMにゲストOSがあるかどうか

ではありません。

ハイパーバイザーの下にホストOSが存在する基本構造かどうかです。

28. Type 2のホストOSをゲストOSと呼ばない

Type 2では、

物理ハードウェア
       ↓
ホストOS
       ↓
ハイパーバイザー
       ↓
VM
       ↓
ゲストOS

となります。

ここで、

ホストOS
=
ゲストOS

ではありません。

ホストOSはハイパーバイザーを動作させる側です。

ゲストOSはVM内部で動作する側です。

29. ハイパーバイザーと仮想マシン（VM）を混同しない

ハイパーバイザーはVMを動かす基盤です。

VMはハイパーバイザー上で動く論理的なコンピューターです。

ハイパーバイザー
  ├─ VM-A
  ├─ VM-B
  └─ VM-C

したがって、

ハイパーバイザー
=
VM

ではありません。

ハイパーバイザーが複数のVMを実行・管理できる関係です。CiscoもゲストVMがハイパーバイザーによって実行・管理される構造を説明しています。

30. VMごとに別ゲストOSを持てる

仮想化では、

VM-A
└─ ゲストOS A

VM-B
└─ ゲストOS B

のように、VMごとに独立したゲストOS環境を持つ基本モデルです。

Ciscoも、各仮想マシン（VM）が仮想ハードウェアを持ち、その上にオペレーティングシステム（OS）とアプリケーションがロードされる構造を説明しています。

したがって、

物理ホストにOSが1つ
      ↓
すべてのVMが同じOSインスタンスを共有

という構造ではありません。

コンテナとの違いはPage009で扱います。

31. 1台のVM障害とハイパーバイザー障害は意味が違う

ハイパーバイザーは複数VMの共通基盤になり得ます。

ハイパーバイザー
  ├─ VM-A
  ├─ VM-B
  └─ VM-C

このため概念的には、

VM-A内部のゲストOS障害

と、

ハイパーバイザー自体の障害

では影響範囲が異なり得ます。

VM分離そのものはPage007で押さえますが、VM単位の障害範囲の判断はPage008で詳しく扱います。

ここでは、

ハイパーバイザーが複数VMに共通する実行基盤である

ことだけ理解します。

32. 物理ホスト障害も共通基盤に影響する

複数VMが1台の物理ホスト上で動いている場合、

物理ホスト
      ↓
ハイパーバイザー
  ├─ VM-A
  ├─ VM-B
  └─ VM-C

物理ホスト自体はすべてのVMの下にあります。

そのため、

物理ホスト全体に影響する障害は、その物理ホスト上の複数VMに影響し得ます。

これは、

VMは論理的に分離される

ことと矛盾しません。

論理的な分離と、物理インフラの共有は別の観点です。

33. ハイパーバイザーはアプリケーションそのものではない

ハイパーバイザーの役割は、

Webサーバーを提供
データベースを提供
メールサービスを提供

といったBusiness アプリケーションの役割ではありません。

ハイパーバイザーは、

それらのアプリケーションを動かすVMの実行基盤

を提供します。

アプリケーション
    ↓
ゲストOS
    ↓
VM
    ↓
ハイパーバイザー
    ↓
物理ホスト

という階層で考えます。

34. ハイパーバイザーはゲストOSを置き換えるものではない

次の理解も誤りです。

ハイパーバイザーを導入した
      ↓
ゲストOSは不要

VMの基本モデルでは、VM内部にゲストOSがあります。

ハイパーバイザーは、

ゲストOSの代わり

ではなく、

ゲストOSを含むVMを実行するための下位層

です。

35. ハイパーバイザーとコンテナエンジンを混同しない

Page009ではコンテナを扱います。

ここでは責任境界だけ確認します。

仮想マシン（VM）
      ↓
ハイパーバイザー

と、

Container
      ↓
コンテナエンジン

は同じ構造ではありません。

Page007では、

ハイパーバイザーがハードウェア仮想化の基盤としてVMを実行する

という役割だけを確実にします。

コンテナのホストカーネル共有などはPage009で扱います。

36. ハイパーバイザーが提供する抽象化を整理する

Page007で扱う関係をまとめます。

物理側	ハイパーバイザーの役割	VM側
CPU	処理リソースを管理・提供	CPUリソース
メモリ	メモリリソースを管理・提供	VM用メモリ
ストレージ	ストレージをVMから利用可能にする	VM用ストレージ
NIC	ネットワークリソースを仲介・提供	VM用ネットワークリソース

ここではPage008との責任境界を守るため、

VM内部の仮想ハードウェア構成そのものを深掘りするのではなく、ハイパーバイザー側から「リソースを提供する」関係

として理解します。

37. ハイパーバイザーが担わないことも区別する

Page007の範囲では、ハイパーバイザーの役割を広げすぎないことも重要です。

扱わないものには、

ハイパーバイザーのインストール
VM作成手順
製品固有設定
予約 / 上限等の詳細リソース制御
HA
クラスター
ライブマイグレーション
ハイパーバイザーのトラブルシューティング
仮想スイッチ詳細
コンテナランタイム
ハイパーバイザーCLI

があります。

つまりPage007は、

設定方法ではなく、役割・構造・関係を説明するページ

です。

38. よくある誤判断

「ハイパーバイザーは仮想マシン（VM）そのもの」

誤りです。

ハイパーバイザーはVMを実行・管理するソフトウェア層です。

「VMは物理ハードウェアを直接すべて管理する」

誤りです。

ハイパーバイザーが物理リソースを管理し、VMへ利用可能な形で提供します。

「ハイパーバイザーを入れると物理リソースが無限に増える」

誤りです。

物理リソースは有限です。

ハイパーバイザーはリソースを抽象化・管理・割り当てします。

「VMが分離されているなら物理ハードウェアも別」

誤りです。

複数VMが同じ物理ホストのリソースを共有しながら、論理的に分離される構成があります。

「ハイパーバイザーとゲストOSは同じもの」

誤りです。

ハイパーバイザーはVM実行基盤、ゲストOSはVM内部のOSです。

「Type 1にはゲストOSが存在しない」

誤りです。

Type 1でもVM内部にはゲストOSがあります。

「Type 2ではホストOSとゲストOSが同じ」

誤りです。

ホストOSはハイパーバイザーの下、ゲストOSはVM内部です。

「Type 1 / Type 2はVMの数で決まる」

誤りです。

ハイパーバイザーの構成上の位置で判断します。

「ハイパーバイザーはコンテナを実行するためだけの層」

誤りです。

Page007で扱うハイパーバイザーは仮想マシン（VM）を実行する仮想化層です。

コンテナはPage009で扱います。

39. CCNAでの判断ポイント

問題でハイパーバイザーについて問われたら、

次を確認します。

① 物理ハードウェアはどこか
② ハイパーバイザーはどこか
③ VMはどこか
④ ゲストOSはどこか
⑤ ホストOSがハイパーバイザーの下にあるか

特にType 1 / Type 2では、

ハイパーバイザー
   ↓
何がある？

を見ると判断しやすくなります。

40. Page007で覚える基本パターン

パターンA

物理ハードウェア
      ↓
ハイパーバイザー
      ↓
複数VM

→ ハイパーバイザーが物理リソースとVMの間を仲介

パターンB

物理CPU / メモリ
      ↓
ハイパーバイザー
      ↓
複数VMへリソース提供

→ ハードウェア抽象化 / リソース割り当て

パターンC

同一物理ホスト
      ↓
VM-A
VM-B
VM-C

→ 物理リソースを共有しながらVM環境は論理的に分離

パターンD

VM
 ↓
ゲストOS

→ ゲストOSはVM内部で動作

パターンE

VM
 ↓
Type 1ハイパーバイザー
 ↓
物理ハードウェア

→ Type 1

パターンF

VM
 ↓
Type 2ハイパーバイザー
 ↓
ホストOS
 ↓
物理ハードウェア

→ Type 2

パターンG

ハイパーバイザー
=
VM

→ 誤り

ハイパーバイザーはVMを実行する基盤です。

まとめ

ハイパーバイザーは、

物理ハードウェアと仮想マシン（VM）の間に位置し、ハードウェアリソースを抽象化・管理・割り当てして、複数VMの実行基盤を提供するソフトウェア層

です。

物理ホストには、

CPU
メモリ
ストレージ
NIC

などの実際のリソースがあります。

ハイパーバイザーはそれらを、

物理リソース
       ↓
抽象化・管理
       ↓
VMへ提供

します。

その結果、1台の物理ホスト上で複数のVMを動作させることができます。

また、VM同士は同じ物理リソースを利用しながらも、基本的には独立したゲストOSを持つ論理的な実行環境として分離されます。

構造を整理すると、

アプリケーション
      ↓
ゲストOS
      ↓
VM
      ↓
ハイパーバイザー
      ↓
物理ハードウェア

です。

Type 1とType 2の違いは、ハイパーバイザーの下に何があるかで判断します。

Type 1

VM
↓
ハイパーバイザー
↓
物理ハードウェア

Type 2

VM
↓
ハイパーバイザー
↓
ホストOS
↓
物理ハードウェア

Page007で最も重要なのは、

ハイパーバイザー、VM、ゲストOS、物理ホストの役割を混同せず、ハードウェア抽象化・リソース割り当て・VMの分離・Type 1 / Type 2の構造を説明できること

です。

理解確認

このページの内容を12問で確認します。

理解確認12問へ →