仮想マシン技術とその展開

慶應義塾大学 理工学部河野 健二

アウトライン

仮想マシン技術の概要 計算機を “仮想化” するには何が必要か？ 計算機の “仮想化” はどうやって実現されたか？

ブレイクスルーとしての VMware Workstation– 血と汗と涙の実装技術

誰でも (?) 作れるようになった VMM としての KVM 仮想マシン技術とクラウド

クラウドのための要素技術の紹介 Live migration Remus Kaleidoscope

仮想マシン技術とは？

一台の計算機を複数台の計算機として使う技術 複数の OS を “同時” に動かすことができる技術

仮想マシン： 仮想的に作り出された計算機ハードウェアのこと 仮想マシンが動く実計算機のコピーのようなもの 仮想マシン上で OS が（多くの場合）無修正で動作する

ホスト計算機（仮想マシンが動く実計算機）

仮想マシン 仮想マシン 仮想マシン仮想マシン技術によってホスト計算機のコピーである複数の仮想マシンを生み出す

ホスト計算機のコピー

仮想マシンモニタとは？

仮想マシンを作り出すソフトウェアのこと 仮想マシン ≠ 仮想マシンモニタ

仮想マシンのことを virtual machine や VM ともいう 仮想マシンモニタのことを virtual machine monitor や VMM ともいう

VM 上で動くソフトウェアをゲスト (guest) という 特に， VVM 上で動く OS をゲスト OS という

ホスト計算機（仮想マシンが動く実計算機）

仮想マシン 仮想マシン 仮想マシン仮想マシンモニタというソフトウェアが仮想マシンというコピーを作り出す

ホスト計算機のコピー

仮想マシンモニタ

Type I VMM と Type II VMM

VMM が動作するレイヤの違いによる分類

ホスト計算機

VMM

ゲスト OS ゲスト OS

VM VMゲストアプリ ゲストアプリ

ホスト計算機

VMM

ゲスト OS

VM

ホスト OS

ゲストアプリ

ホストアプリ

Type I VMM:VMM が裸の計算機 ( ホスト計算機 ) 上で直接動作する方式

Type II VMM:VMM がホスト計算機の OS の上で動作する方式

仮想化の方式の分類

完全仮想化 (full virtualization) 無修正のゲスト OS が動作するように仮想化すること

準仮想化 (para-virtualization) 仮想化のための修正を加えたゲスト OS を対象とする

ソフトウェア仮想化 (software virtualization) ソフトウェアのみで仮想化を行うこと ハードウェアによる仮想化支援機構を前提としない

ハードウェア仮想化 (hardware virtualization) ハードウェアによる仮想化支援を用いて仮想化すること

資源の仮想化 ー CPU

安全にゲストの命令列を実行できるようにすること 「安全に」 とは VMM や他の VM を阻害しないこ

と ゲストの命令列には特権命令も含むことに注意

CPU 時間をそのまま VM に与えてしまうと・・・ ゲスト OS が特権命令を実行してしまう

ゲスト OS はホスト計算機を占有していると思い込んでいるため他の VM や VMM の状態を壊してしまう

De-Privileging

ゲスト OS を非特権モードで実行すること ゲスト OS の特権命令により， VMS の整合性が破壊さ

れるのを防ぐため 特権命令を実行しようとすると保護例外が発生する

VMM に制御が移る （ VMM は特権レベルで動作している） VMM では特権命令をエミュレートする

ゲスト OS は特権命令が期待通りに実行できたと勘違いする 特権命令のエミュレート例：

ある VM が cli ( 割込禁止命令 ) を実行 保護例外が発生し， VMM に制御が移る 割込禁止の VM 宛ての割り込みは配信待ちにする

実 CPU の割り込みが禁止されるわけではない なぜなら，他の VM では割り込みを待っているかもしれないか

ら

センシティブな命令

特権命令の実行だけを防止すればいいのではない 正確にはセンシティブ命令の実行を防止しなければならない

センシティブ (sensitive) 命令： ゲスト OS が直接実行してはまずい命令のこと

直接実行すると VMM やホスト OS と干渉する恐れがある 例： I/O 命令

センシティブではない普通の命令を innocuous 命令という

センシティブ命令と特権命令の関係

すべての命令特権命令

センシティブ命令

センシティブ命令の例

システムの状態を参照する命令 例： プロセッサの動作モードを参照する命令

ゲスト OS に次のようなコードが含まれるとまずいm ← プロセッサの動作モード ;if (m != priviledged) { /* 何かおかしい */ panic();}

例：プロセッサの動作モードにより処理内容が異なる命令 Intel x86 の POPF

スタック上の値をフラグレジスタに読み込む命令» フラグのひとつは割込許可フラグ

POPF を使って割込許可フラグを変更しようとすると・・・– 特権モードでは，割込許可フラグが変更できる– 非特権モードでは，割込許可フラグの変更は無視される

» 無視されるだけで保護例外は発生しない

（古典的な意味での）仮想化可能な CPU CPU が仮想化可能 (virtualizable) であるとは，

センシティブ命令が特権命令の部分集合であること

上記の包含関係が成立していれば・・・ゲスト OS は非特権モードで動作しているため，

ゲスト OS はセンシティブ命令を直接実行できない センシティブ命令を実行すると保護例外が発生する

すべての命令

特権命令

センシティブ命令

資源の仮想化 ー メモリ

各 VM は物理メモリを独占していると思っている 物理メモリは 0 番地から始まる 物理メモリは連続している

実際には？ ホスト計算機の物理メモリを分け合って使っている

物理メモリは 0 番地から始まるとは限らない 物理メモリは連続しているとは限らない

にもかかわらず・・・ 各 VM には 0 番地から始まる連続したメモリがあ

ると思わせたい

2 段階のアドレス変換？？？

メモリを仮想化するには 2 段階のアドレス変換が必要 一段階目のアドレス変換：

仮想アドレス → ゲスト物理アドレス– ゲスト OS が両者の対応を管理している

二段目のアドレス変換： ゲスト物理アドレス → ホスト物理アドレス

– VMM が両者の対応を管理している 用語：

仮想アドレス (guest virtual addr; gVA) ： VM 上の仮想アドレス

ゲスト物理アドレス (guest physical addr; gPA) ： VM 上の物理アドレス

ホスト物理アドレス (host physical addr; hPA) ： ホスト計算機上の物理アドレス

通常の MMU では 2 段階のアドレス変換はできない 通常の MMU を使って 2 段階変換を実現する方法は？

資源の仮想化 ー I/O

ゲスト OS は I/O デバイスを独占していると思っている I/O デバイスを多重化してゲスト OS に見せる必要がある ゲスト OS の見ているデバイスを仮想デバイスという

I/O Virtualization

VirtualDevice

VirtualDevice

VirtualDevice・ ・ ・ ・

Device

DeviceDriver

ソフトウェアによる完全仮想化 :VMware Workstation を題材に

Commodity PC の仮想化

VMware WS の成し遂げたこと 広く普及した PC プラットフォームの仮想化

古典的な仮想化技術をそのまま使うのは難しい– trap & emulate, VMM による全デバイスの管理・・・

仮想化への障壁 仮想化できないプロセッサ：

Intel x86 には sensitive but unprivileged 命令がある PC ハードウェアの多様性：

膨大な種類の PC 用デバイスが存在する VMM がすべてのデバイスドライバを持つことは不可能

プレインストールされたソフトウェア資産： PC には OS やアプリケーションがインストール済み インストール済みのソフトウェアを使い続けられる方式が必要

VMware's Hosted Architecture

ホスト OS と共存できる構成 Type I と Type II のハイブリッド型

ホスト上の OS とアプリはそのまま

I/O デバイスへのアクセスはホスト OS 任せ

VM Monitor CPU とメモリの仮想

化 VM Driver

Host OS と VMMの通信

VM App I/O 処理をホストに丸投げ

VMware WS における CPU 仮想化

BT (Binary Translation) Innocuous 命令は直接実行する Sensitive (either privileged or unprivileged) 命令はエミュレート

エミュレータ呼び出しに置き換える 多くの場合，インライン展開してしまう

・・

mov %ecx, %edimov %esi, $2popfcmp %esi, %ecx

・・

・・

mov %ecx, %edimov %esi, $2《 call emulator》cmp %esi, %ecx

・・

BinaryTranslation

実行したいゲストのコード 実際に実行するコード

BT で除去できない Sensitive 命令

ページテーブル，割り込みベクタ等へのアクセス 通常の mov 命令でアクセスされるため，

BT で削除するのは難しい

どうやってページテーブル等へのアクセスだと知るのか？ VMM のほうでメモリ保護しておく

trap が頻発するならエミュレータ呼び出しに切り替える

trap の頻度によって， エミュレータ呼び出しを使う場合と mov 命令を使う場合と

を 適応的に切り替える

メモリの仮想化

ゲストの仮想ページ

ゲストの物理ページ

ホストの物理ページ

仮想 CR3

gVA → gPA

(virtual)page table

CR3

gPA (?) → hPA

page table

二段階のマッピングをどうやって実現するの？

Shadow Page Table

ハードウェアによるアドレス変換に使われるページテーブル Shadow Page Table に gVA → hPA の対応を格納する

ゲストの仮想ページ

ゲストの物理ページ

ホストの物理ページ

仮想 CR3

gVA → gPA

(virtual)page table

CR3

gVA → hPA

shadowpage table

HW はこちらを使う

I/O の仮想化

I/O の仮想化は鬼門 性能への影響が大きい 多種・多様なデバイスに対応するため，

開発コストがかさむ危険がある

VMware Workstation のアプローチ VMM 自身はデバイスドライバを持たない

VMware hosted architecture の採用 I/O デバイスへのアクセスはすべてホスト OS に丸投げ

仮想化するデバイスを絞り込む 標準的な PC デバイスのみを仮想化する

– PS/2 キーボード， PS/2 マウス，フロッピー， IDE/ATA– ATAPI CD-ROM, AMD PCNet Ethernet などなど

VMware WS における I/O 処理

ポートを通じて I/O 操作を行う IN 命令： 指定した I/O ポートからデータを読み込

む OUT 命令： 指定した I/O ポートにデータを書き込

む いずれも特権命令

IN/OUT 命令を VMM で trap & emulate する 基本的に VMApp に処理を丸投げする VMApp はホスト OS の機能を使って I/O 処理を行

う 例： ディスクブロックの読み出しであれば，

仮想ディスクを読み出す read() を行う 仮想化対象のデバイスを絞り込むことで・・・

仮想化する必要のある I/O ポートが少なくてすむデバイスに対応するための VMApp 上のコードが少なくて済む

パケットの受信

Guest OS

VMM

Virtual NIC

Host OS

VMDriver

VMApp

VMNet Driver

Host Ethernet Driver

Ethernet H/W

6. IN/OUT to I/O port

4. WorldSwitch

3. ask packettransfer

1.Device Interrupt

2. select()returns 5. copy packet &

raise virtual IRQ

VMM World で割込を受け取ると，Host World にスイッチしてから，Host OS でパケットを受信する

7. VMApp の呼び出し

オーバーヘッドの削減

理想的な仮想デバイス・インターフェスを用意する 例： 単一の OUT 命令でパケット送信可能な NIC

IN/OUT 命令のエミュレートに必要な World Switch が減る ゲスト OS には理想デバイス用のドライバを入

れる 仮想化のオーバーヘッドを軽減するため，

ゲスト OS 側で少し仮想化に対応してもらう 準仮想化 (paravirtualization) の考え方

仮想化のためのハードウェア支援とKVM

ハードウェアによる仮想化支援

ソフトウェア仮想化は大変 特に x86 は仮想化との相性が悪い

Sensitive but unprivileged 命令 Hardware-walk のページテーブル

– ソフトウェア TLB であればまだ楽 完全仮想化は地獄． VMware はたいしたもの

ハードウェアで仮想化を支援しましょう 仮想化を実現するソフトウェアがシンプルにできる

必ずしも性能が向上するわけではない 当然の流れ

Intel VT, AMD-V, などなど他にもたくさん

Intel VT とは？

Intel Virtualization Technology の略称 仮想化支援のための一連の新機能

CPU の仮想化のための IA-32 用の VT-x IA-64 用の VT-i

I/O の仮想化ための VT-d Virtualization Technology for Directed I/O

今回の対象は， VT-x と VT-d AMD の仮想化支援はだいたい同じ

細かいところが違うが，概念的には（近似的には）同じ

VMX モード

リング保護とは直交した新たな保護モード VMX root モード： VMM が動作するためのモード VMX non-root モード： ゲストが動作するためのモー

ド

VMMゲスト OS

アプリケーション

VMX rootVMX non-root

VM Exit

VM Entry

VMX root/non-root モード

VMX root モード 従来のプロセッサとほぼ同じ動きをするモード 相違点

VMX 命令が使えること VMX non-root モード

仮想化を容易にするための支援がなされているモード

仮想化に影響する命令やイベントは VM Exit を引き起こす

例： センシティブな命令を実行 1. VM exit が発生する 2. VMX root モードで動作する VMM に制御が移る 3. VMM では VM exit の理由を調べ，適切な処理を行う 4. VMX non-root モードに復帰する

モードの遷移

通常モードVMX root モード

(VMM)VMX non-root モード

(VM)

VMXON

VMXOFF

VM Entry

VM Exit

VM Entry

VM Exit

Event Injection

ゲスト OS にイベントを送り込む仕組み VM entry 時に，指定したイベントを配信することが

できる イベント = interrupt or exception

ゲスト OS から見ると VM entry 直後に指定されたイベントが起きたように見える したがって，ゲスト OS の IDT を使ってハンドラが起動さ

れる VMM で補足したイベントの再送に便利

イベントの再送メカニズムをエミュレートする必要がない

EPT: メモリの仮想化支援

Extended Page Table (EPT) guest virtual addr → host physical addr への変換を行う ハードウェアで勝手に

guest physical addr → host physical addrの変換を行う

ゲスト OS から見ると・・・ 0 番地から始まる連続した物理メモリという幻想を抱いている

CR3 はゲスト OS のページテーブルを指す– Shadow page table は不要

にもかかわらず，ゲスト OS のページテーブルでは，guest virtual addr → guest physical addr

の変換を行う

Extended Page Table の仕組み

Extended Page Table という別のテーブルを持つ guest physical addr → host physical addr の対応表

EPT Ptr

Extended Page Table の注意点

TLB にエントリがあればオーバーヘッドはなし 通常のアドレス変換と全く同じように動作する TLB には，

guest virtual address → host physical addressが入っている

TLB ミスのオーバーヘッドが数倍のコストになる ページテーブルが使用するアドレスは gPA である点に注

意 ページテーブルを参照するために gPA → hPA への変換が必要

TLB fill のために EPT を頻繁に参照する CR3 → PD, PD → PT, PT → hPA の 3 回 64 bit アーキテクチャでは 4 段階のページテーブル

– 全部で 5 回 EPT を参照する

KVM の基本アーキテクチャ

KVM における仮想マシン ホストカーネル上のひとつのプロセスと

して動作 仮想マシンごとに kvm プロセスが作られる 仮想マシンに割り当てられた仮想 CPUの個

数に応じてスレッドが作られる KVM モジュール

ホストカーネル内で動作 kvm プロセスは /dev/kvm を通じて KVM

モジュールとやりとりする QUEM プロセス

仮想デバイスのエミュレーションを行う 動作モード

ゲストカーネル： VMX non-root/RING0 sensitive な処理を行うと，

VM exit が発生する ゲスト上のプロセス：

VMX non-root/RING3 ホストカーネル：

VMX root/RING0 ホスト上のプロセス：

VMX root/RING3

デバイスへのアクセスとメモリ管理

デバイスの仮想化 QUEM によるデバイスエミュレーションを利用する

ゲスト OS がデバイスにアクセスすると・・・– VM exit が発生し KVM モジュールに処理が移る

KVM モジュールは必要に応じて QEMU を呼び出す

メモリ管理 Extended Page Table を使う Extended Page Table が

サポートされていなければ，Shadow Page Table を使う

Intel VT-d: I/O の仮想化支援

I/O デバイスを多重化するためのハードウェア支援 DMA Remapping (IOMMU) Interrupt Remapping

デバイスの Direct Assignment を目指す ゲスト OS が直接デバイスを制御する

各 VM 専用の I/O デバイスが存在するイメージ– マルチキュー NIC などの利用を想定

I/O エミュレーションのオーバーヘッドがない ゲスト OS のデバイスドライバがそのまま利用できる

– VMM を小さくすることができ VMM の信頼性が向上する

– デバイス特有の機能を最大限に活用できる

DMA Remapping

ゲスト OS が占有するデバイスの DMA を安全に行う 解決したいこと：

DMA ではデータの転送先アドレスを物理アドレスで指定する ゲスト OS が物理アドレスの設定を間違えると致命的

– 他のゲスト OS や VMM自身のメモリが破壊される可能性がある VMM でチェックすればいいのでは？

ゲスト OS からの DMA 要求を横取りし， VMM でチェックする– 安全性は保証できる

VMM でデバイスドライバを持つ必要が出てくる Direct Assignment の考え方に反する

VMM でチェックせずに安全性を保証したい！

IOMMU

デバイスアドレスから物理アドレスの変換機構 デバイスアドレス：

I/O デバイスが見ている仮想アドレスのこと

Main Memory

Device

IOMMU

Physical Address

CPU

MMU

Virtual AddressDevice Address

IOMMU の拡張による DMA Remap

デバイスごとに別々のデバイスアドレス空間を持つ デバイスごとに別々のアドレス変換表を持つ

プロセスごとに別々のページテーブルを持つのと同じ ゲスト OS が指定した gPA に書き込まれることを強制で

きる デバイスアドレス変換表では，

guest physical addr → host physical addrの変換を行う

Devicemappingstructure

PCI requester ID

Address Translation Table

仮想マシン技術とクラウド

仮想マシン技術のもたらすもの

計算機そのもののカプセル化 計算機を物理的なハードウェアから分離できる 計算機を 「電子的に」 移動・複製が可能になる

計算機をいつでもどこでも好きなところで好きな数だけ実行できる

カプセル化の手順 VM のスナップショット機能により，計算機を “カプセル化” “カプセル化” した計算機を複製・移動する

スナップショットはただのデータ．複製も移動も容易 スナップショットを編集することも容易

カプセル化の仕方を少し変えると・・・ VM cloning: 計算機のコピーを on demand に素早く作る技術 Live migration: 計算機を止めずに移動する技術 Remus: 待機系の計算機をうまく作る技術

仮想化とクラウド

クラウドコンピューティングが広く利用されている 特長の一つとして，リソースの伸縮性（ Elasticity ）が

あるメモリや CPU など，リソースの増減を自在に行える性質の

ことで，負荷状況に合ったリソース量を維持できる 負荷増加時には，新たに VM を生成してリソースを追加する

インターネット

VM 1

VM 2

ロードバランサ

VM 3

負荷が大きく，処理仕切れない

新たな VM を生成（ = インスタンスの追加）

現行のクラウドサービス（例： Amazon EC2 ）

VM Cloning

稼働中の VM のコピーを作る技術

1. リソース追加に時間がかかり，突発的な負荷増加に素早く対処できない

VM の起動は，時間を要する処理であるため Amazon EC2 では VM の起動に約 2 分かかる

2. メモリの無駄遣いが生じる 一時的に少しだけリソースを増やしたい場合でも，

フルサイズのメモリを割り当ててしまうため

3. VM 起動直後のパフォーマンスが低い 起動直後はキャッシュが存在しないため

Previous Work

Live VM Cloning with SnowFlock [Lagar-Cavilla et.al. ’09] 負荷増加時に， VM のクローンを迅速に作成する手法

親 VM の最低限の情報からクローンを作成し，稼働させる 子 VM のメモリ内容は，オンデマンドにコピーしていく

子 VM 生成直後のパフォーマンスが著しく低下する 負荷が長期間にわたって増加する場合は大きな問題に

ならないが，短期的な負荷増加の場合は問題となる

メモリ

親 VM

メモリ

子 VM 1

メモリ

子 VM 2

へアクセスしたい

へアクセスしたい

クローンを作成

オンデマンドにコピーする

提案： Kaleidoscope

クローン VM 作成に要する時間を短く抑えつつ， VM 起動直後のパフォーマンスを保つクローニング手法 提案手法の特長

負荷増加時，クローン VM を迅速に生成できる クローン VM 起動直後のパフォーマンス低下が小さいユーザのニーズに応じたメモリ割り当てにより，無駄がない

クローン VM 稼働

SnowFlock

Kaleidoscope

クローン VM 稼働（パフォーマンス低下） time

time

Amazon EC2 time新 VM 作成時間

負荷増加時の挙動

クローン VM 作成時間

新 VM 稼働

アプローチ

二つのメカニズムを用いて，クローン VM 起動後のパフォーマンス低下を防ぎ，無駄なくメモリを使用する VM state coloring

クローン VM が起動後に必要としそうなデータを起動前にプリフェッチする or VM 間で共有する

Fractional allocation VM state coloring によってプリフェッチされたメモリ領域以

外にはメモリを割り当てない

プリフェッチされた領域以外にアクセスされた場合は，メモリを割り当てて親 VM からオンデマンドにメモリ内容をコピーする

クローン VM 起動後のパフォーマンス低下を防ぐことができる

クローン VM に対するメモリの無駄遣いをなくすことができる

実環境でのパフォーマンス評価

CPU 使用率の制限を変化させながら，要求を満たせなかった時間の累計を測定した Kaleidoscope は従来の Elastic Cloud よりも，要求を満たせ

なかった時間が短く，高いパフォーマンスを出すことができた Kaleidoscope はスレッショルドが 90 % の場合でも， Elastic Cloud

のスレッショルド 50 % 時よりも高いパフォーマンスを出せた

VM Creation Threshold = 90 (%) とは，システム全体としての CPU 使用率が 70 ~ 90 %になるように，リソースの増減を行うことを表す．

VM Creation Threshold = 60 (%) ならば， 40 ~ 60 %

マシンに無理強いする環境

低パフォーマンス

Live Migration

VM を稼働させたまま別の物理マシンに移送する技術 HW のメンテナンスやアップグレードを容易にする

移送時のシステムのダウンタイムを最小化し、システムの移送による影響を隠す サーバを落とすことは大きい損害に繋がる

ディスクの移送は行わない データセンタ環境を想定し、各 VM はネットワークスト

レージに接続していることを仮定

VM１

VM２

仮想マシン１

VM２

VM３

仮想マシン２

Live Migration

稼働中

反復的ダーティページ転送

Push Phase 最初は全てのページを転送 ダーティページが一定以下

になるまで反復的に繰り返す

Stop-and-copy Phase VM を停止させ、残っているダーティページ、 CPU レジスタを転送し、制御を移す

システムがダウンしているため、ダーティページが発生しない

最初のメモリコピー：全てのメモリページを転送

ダーティページの反復的転送

VM を停止させ、残りダーティページと仮想 CPU の情報を転送

移送先の VM でコントロール再開

VM 停止

VM稼働

ダーティページが一定以下に下がるまで反復

実験 ウェブサーバ移送時のスループット

テスト環境 Dell PE-2650 サーバー (2Ghz Dual Processor with 2GBメモリ ) 一つの 512KB ファイルを 100 クライアントに続けて HTTP で転送

２回のダーティページコピーの後、 Stop-and-copy段階に入る サーバーのダウンタイムは 165ms

時間の流れ（ sec ）

スル

ープ

ット

（M

bit/sec)

Remus

サービス提供マシンとバックアップマシン ( 待機系 ) を利用

Live Migration のメモリコピー手法を利用し HW 故障から、サービスを保護する 同期の負担を軽くし、サービスへの影響を小さくする

クライアントに気付かれることなく制御を切り替える サーバの状態（例：コネクション）を保持する

サーバ

待機系

同期

同期

同期

ハードウェア故障発生

最新の同期点から実行再開

Remus の動作

メモリのコピーに live migration のメモリコピー手法使用 (A)のStop-and-copy Phaseが終わった時点をチェックポイントとして保存

ハードウェア故障が発生した場合チェックポイントまで戻る 送信パケットをバッファに入れ，チェックポイント取得後解放する

バッファリングせず送信すると、チェックポイントに戻った時に同じメッセージを送信してしまう

待機系のディスク書き込み作業を非同期に処理する ディスクアクセスの遅延を隠蔽 チェックポイント後待機系のディスクに書き込み作業を実行

移送元 移送先

Buffer1

23

まとめ

仮想マシン技術 どのようにして計算機を仮想しているのか？

VMware Workstation と KVM を題材に

仮想マシン技術とクラウド 仮想マシン技術はクラウドと相性がよい 動的に計算機を

作り (cloning) 移動 (migration) し 待機 (standby) させることができる