仮想化 — 1台のマシンを、仕切って複数に使う

概要 — まず全体をつかむ

初級では仮想化を「1台を仕切って複数として使う」と捉えました。中級では、その仕切りを誰が管理しているのか——ハイパーバイザの役割と、何を仮想化しているのかを見ます。

詳細 — 1段階ずつ追う

これは何をする係?

VMを束ねる管理役がハイパーバイザ(※1)です。1台分の物理資源を切り分けて、各VMへ割り当てます

アニメーション『仮想化の層構造(ハイパーバイザとVM)』を開く
1台の物理マシンを、複数のVMに分けて使うハイパーバイザが、物理資源(CPU・メモリ等)を切り分けて各VMへ割り当てる。仮想マシン1アプリゲストOS(OSを丸ごと積む=重い)仮想マシン2アプリゲストOS(OSを丸ごと積む=重い)仮想マシン3アプリゲストOS(OSを丸ごと積む=重い)ハイパーバイザ物理資源をVMへ割り当てる管理役ハードウェアCPU・メモリ・ストレージ・NIC(1台)VMごとにOSを積むので分離は強いが、その分だけ重くなる置き場所の2タイプType1(ハード直上)VM / VMハイパーバイザハードウェア速い・サーバ向きType2(ホストOS上)VM / VMハイパーバイザホストOSハードウェア手元PCに入れて使う向きOSの上に載せるか、ハードに直接載せるか

図のように、下からハードウェア → ハイパーバイザ → 複数のVMが積み上がります。各VMは、上にアプリ、下にゲストOS(※2)を丸ごと積んでいます。ここが大事な点で、VMは中に1台分のOSを持つため、しっかり分離できる反面、その分だけ重くなります。

ハイパーバイザには置き場所で2タイプあります。

  • Type1(ベアメタル) — ハードの直上で動く。速く、サーバ向き
  • Type2(ホスト型) — ホストOSの上で動く。手元のPCに入れて使う向き

登場人物メモ:

  • ※1 ハイパーバイザ — 物理資源を切り分け、各VMへ割り当てる管理役(VMM とも)
  • ※2 ゲストOS — VMの中で動くOS。VMごとに1つずつ積む
  • ※3 ホストOS — Type2で、ハイパーバイザを載せる土台側のOS
この部分をもっと深く(上級

ゲストOSに「本物のマシンに見せる」やり方は、歴史的に3つあります。

  • 完全仮想化 — ゲストOSを改造せずそのまま動かす。特権命令をハイパーバイザが捕まえて肩代わりする(トラップ&エミュレート)。互換性は高いが、捕まえる処理が重い
  • 準仮想化(paravirt) — ゲストOSを仮想化に気づかせて改造し、重い特権命令の代わりにハイパーバイザへの直接呼び出し(ハイパーコール)を使う。速いがゲストの改造が要る
  • ハードウェア支援仮想化 — CPU自体(Intel VT-x/AMD-V)に仮想化専用の動作モードを足し、改造なしで速く動かす

鍵は特権レベルです。OSは本来、最も強い権限の層(リング0※1)で動くつもりでいます。ところが仮想化ではハイパーバイザこそが最強でいたい。そこでVT-x/AMD-Vは、ハイパーバイザ用の VMX root モード(※2)とゲスト用の非rootモードを別に設けました。ゲストOSは自分がリング0にいると思い込んだまま動け、危険な操作の瞬間だけ自動でハイパーバイザ側へ制御が移ります(VMExit)。「ゲストには最強に見せつつ、実権はハイパーバイザが握る」——この二重構造が支援機構の核です。

なお中級で見た Type1(ベアメタル)/Type2(ホスト型) の違いは「ハイパーバイザの置き場所」の話で、上のどの方式とも組み合わさります。

やさしく言うと(初級

仮想化とは、1台の物理マシンを、ソフトウェアの力で複数の仮想マシン(※1 VM)に分けて使う技術です。

たとえるなら、1つの建物を壁で仕切って、複数の部屋として貸すイメージ。建物(=物理マシン)は1つでも、部屋(=VM)ごとに別の人が、別の使い方をできます。各部屋には独立した鍵があり、隣の部屋の中は見えません。

登場人物メモ:

  • ※1 VM(仮想マシン) — 物理マシンの中に作った、独立した1台分の「仮想の部屋」
  • ※2 資源 — CPU・メモリ・ストレージなど、マシンが持つ計算の元手

何を仮想化しているのか

「仮想化」といっても、実体は資源をあるように見せかけて割り当てることです。

  1. CPU — 物理コアの時間を細切れにして、各VMへ順番に貸す
  2. メモリ — 物理メモリの一部を切り出し、VMには「専用の連続したメモリ」に見せる
  3. ストレージ — 1つのファイルやボリュームを、VMには1台のディスクとして見せる
  4. ネットワーク — 仮想的なNICやスイッチを作り、VM同士や外とつなぐ

VM側からは、どれも本物の1台に見えます。この「見せかけ」を破綻なくやるのがハイパーバイザの仕事です。

この部分をもっと深く(上級

中級では「CPU・メモリ・ストレージ・ネットワークを見せかける」と概観しました。ここではCPUとI/Oを実装の目線で深掘りします。

vCPUスケジューリング — VMに割り当てた vCPU(※4)は、実体としては物理コアの時間の割り当てです。ハイパーバイザが物理コアを時分割し、各vCPUを順番に走らせます。ここで難しいのが、複数vCPUを持つVMで一部だけ実行され残りが止まると、ゲスト内のロック待ちなどが崩れること(co-scheduling問題)。物理コアより多くのvCPUを約束すると(オーバーコミット)、混雑時に取り合いが起きます。

I/O仮想化は、速さを求めて3段階に進化しました。

  1. エミュレーション — 実在のデバイス(NICなど)の振る舞いをソフトで真似る。改造不要で互換性は高いが最も遅い
  2. virtio(準仮想化I/O) — ゲストに専用ドライバを入れ、無駄な真似をやめて効率化した「仮想化前提のデバイス」。エミュレーションより大幅に速い
  3. SR-IOV(パススルー)物理デバイス自身が複数の仮想機能(VF)を提供し、各VMがハイパーバイザを介さず直接デバイスと話す。ほぼ実機の速度。ただしハードとドライバの対応が要り、VMの移動などで制約が出る

「ソフトで真似る → 準仮想化で賢く → ハードを直接分ける」——遅さを削るこの流れは、NIC のような実デバイスをどう共有するかという問いへの答えでもあります。

やさしく言うと(初級

わざわざ仕切るのには、はっきりした理由があります。

  1. 資源を無駄なく使える — 1台を持て余さず、余った力を別のVMに回せる
  2. 環境を分離できる — 部屋ごとに分かれるので、片方が壊れても隣に影響しにくい
  3. すぐ作って壊せる — ソフトなので、必要なときに増やし、要らなくなれば消せる

昔は「アプリごとに物理マシンを1台ずつ」用意しがちで、多くのマシンが力を余らせていました。仮想化はその無駄をまとめて解消したのです。

VMからコンテナへ

VMの弱点は、はっきりしています——OSを丸ごと積むので重い。起動に時間がかかり、1台に積める数も限られます。

その反省から生まれたのがコンテナDocker/コンテナ)です。コンテナはOSを積まず、ホストのカーネルを共有したまま、プロセスを隔離して動かします。だから軽く、起動も速い。VMとコンテナの積み方の違いは、既存の対比図で確かめられます。

アニメーション『VMとコンテナの違い』を開く
仮想マシン(VM)OSをまるごと積む=重いコンテナカーネルを共有=軽い仮想マシン1アプリゲストOS(フルOS)仮想マシン2アプリゲストOS(フルOS)仮想マシン3アプリゲストOS(フルOS)ハイパーバイザハードウェアコンテナ1アプリ+必要な部品だけコンテナ2アプリ+必要な部品だけコンテナ3アプリ+必要な部品だけコンテナエンジンホストOSカーネルを全コンテナで共有ハードウェアVMはゲストOSごと積むので重い/コンテナはホストのカーネルを共有しOSを積まないので軽い

分離の強さがほしいならVM、身軽さがほしいならコンテナ——用途で使い分けます。

そして、クラウドで借りるサーバの中身は、結局この仮想化です。物理マシンを大量に持つ事業者が、それをVMやコンテナに切り分けて、必要な分だけ貸している——それがクラウドの正体なのです。

この部分をもっと深く(上級

中級では「コンテナはOSを積まず軽い」と対比しました。上級の核心は、その軽さの代償である隔離の深さの差です。

アニメーション『VMとコンテナの違い』を開く
仮想マシン(VM)OSをまるごと積む=重いコンテナカーネルを共有=軽い仮想マシン1アプリゲストOS(フルOS)仮想マシン2アプリゲストOS(フルOS)仮想マシン3アプリゲストOS(フルOS)ハイパーバイザハードウェアコンテナ1アプリ+必要な部品だけコンテナ2アプリ+必要な部品だけコンテナ3アプリ+必要な部品だけコンテナエンジンホストOSカーネルを全コンテナで共有ハードウェアVMはゲストOSごと積むので重い/コンテナはホストのカーネルを共有しOSを積まないので軽い
  • VM — 各VMが独立したカーネルを丸ごと持つ。ハイパーバイザという薄い境界の下で、他VMとはカーネルレベルで分離される。隔離は強いが重い
  • コンテナ — ホストのカーネルを共有し、名前空間(namespace)とcgroupで「見える範囲と使える量」を仕切るだけ。カーネルは1つを分け合うので、カーネルの脆弱性を突かれると隣へ波及しうる。隔離は弱めだが軽い

つまり両者の差は「速さ対安全」ではなく、境界がどの層に引かれているかです。VMはハードウェアに近い層で、コンテナはOSの中の仕切りで隔てる。マルチテナントで強い隔離が要るなら、コンテナをさらにVMの中で走らせる(軽量VMでコンテナを包む)折衷も使われます。詳しくは Docker/コンテナ と、その土台を貸し出す クラウド を参照。

やさしく言うと(初級
  • クラウドクラウドで借りるサーバの多くは、実は誰かの物理マシンを仮想化したVMです
  • 手元のPC — 1台のPCの中に、別のOSをVMとして入れて試す
  • コンテナの土台 — もっと軽い仕切り方であるコンテナ/Dockerも、この「分けて使う」発想の延長にあります

つまり仮想化は、今どきのサーバ運用の土台の考え方なのです。

⚠️ うまくいかないとき

  • オーバーコミット — 資源を実際より多く約束しすぎると、混んだときに取り合って遅くなる
  • 単一障害点 — 物理1台の上のVMは、そのハードが倒れるとまとめて止まる(分散配置で緩和)
  • オーバーヘッド — 仮想化の見せかけ処理そのものが、わずかに性能を食う
  • VMの増えすぎ — 作るのが簡単なぶん、使われないVMが放置されがち(棚卸しが要る)
この部分をもっと深く(上級
  • CPUオーバーコミット — vCPUを物理コアより多く約束し、混雑時にスケジューリング待ちで急に遅くなる
  • NUMAの無視 — 大きなVMがCPUと遠いメモリを掴み、二段変換より前の段階で遅延が増える
  • SR-IOVの移動制約 — デバイス直結ゆえにVMのライブマイグレーションが難しくなる(速さと柔軟さの綱引き)
  • カーネル共有の油断 — コンテナをVM並みの隔離と思い込み、カーネル脆弱性の横展開リスクを見落とす
  • 準仮想化ドライバ欠如 — virtioドライバを入れ忘れ、遅いエミュレーション経路のまま運用してしまう
やさしく言うと(初級
  • 入れすぎると重い — 1台に詰め込みすぎると、部屋同士が資源を取り合って遅くなる
  • 土台が倒れると全滅 — 物理マシン1台が壊れると、その上のVMがまとめて止まる
  • 中身は本物のマシン — VMも1台分のOSを持つので、更新や管理の手間は物理マシンと同じだけかかる

関連する知識

理解度チェック

そのまま解けます(成績は保存されません)。無料アカウントを作ると、学習の記録と進捗の山登りが始まります。

1. ハイパーバイザの役割として正しいのは?

2. VMの中で動き、VMごとに1つずつ積むOSを何と呼ぶ?

3. VMに対してコンテナが軽いのは なぜ?

4. Type1(ベアメタル)とType2(ホスト型)の違いとして正しいのはどれ?

5. 中級本文で「CPUの仮想化」の実体として説明されているのはどれ?

6. 「ストレージの仮想化」の説明として正しいのはどれ?

7. 落とし穴の1つ「オーバーコミット」とはどういうことか?

8. Type2構成で、ハイパーバイザを載せる土台側のOSを何と呼ぶ?