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

1. 仮想マシン技術とその展開 慶應義塾大学 理工学部 河野 健二

2. アウトライン • 仮想マシン技術の概要 • 計算機を“仮想化”するには何が必要か？ • 計算機の“仮想化”はどうやって実現されたか？ • ブレイクスルーとしての VMware Workstation • 血と汗と涙の実装技術 • 誰でも (?) 作れるようになった VMM としての KVM • 仮想マシン技術とクラウド • クラウドのための要素技術の紹介 • Live migration • Remus • Kaleidoscope

3. 仮想マシン技術とは？ • 一台の計算機を複数台の計算機として使う技術 • 複数の OS を“同時”に動かすことができる技術 • 仮想マシン： • 仮想的に作り出された計算機ハードウェアのこと • 仮想マシンが動く実計算機のコピーのようなもの • 仮想マシン上で OS が（多くの場合）無修正で動作する ホスト計算機のコピー 仮想マシン 仮想マシン 仮想マシン 仮想マシン技術によってホスト計算機のコピーである複数の仮想マシンを生み出す ホスト計算機 （仮想マシンが動く実計算機）

4. 仮想マシンモニタとは？ • 仮想マシンを作り出すソフトウェアのこと • 仮想マシン ≠ 仮想マシンモニタ • 仮想マシンのことを virtual machine や VM ともいう • 仮想マシンモニタのことを virtual machine monitor や VMM ともいう • VM 上で動くソフトウェアをゲスト (guest) という • 特に，VVM 上で動く OS をゲスト OS という ホスト計算機のコピー 仮想マシン 仮想マシン 仮想マシン 仮想マシンモニタというソフトウェアが仮想マシン というコピーを作り出す 仮想マシンモニタ ホスト計算機 （仮想マシンが動く実計算機）

5. Type I VMM と Type II VMM • VMM が動作するレイヤの違いによる分類 VM VM VM ゲストアプリ ゲストアプリ ゲストアプリ ホストアプリ VMM VMM ゲスト OS ゲスト OS ゲスト OS ホスト計算機 ホスト OS ホスト計算機 Type I VMM:VMM が裸の計算機 (ホスト計算機) 上で直接動作する方式 Type II VMM:VMM がホスト計算機の OS の上で動作する方式

6. 仮想化の方式の分類 • 完全仮想化 (full virtualization) • 無修正のゲスト OS が動作するように仮想化すること • 準仮想化 (para-virtualization) • 仮想化のための修正を加えたゲスト OS を対象とする • ソフトウェア仮想化 (software virtualization) • ソフトウェアのみで仮想化を行うこと • ハードウェアによる仮想化支援機構を前提としない • ハードウェア仮想化 (hardware virtualization) • ハードウェアによる仮想化支援を用いて仮想化すること

7. 資源の仮想化ー CPU • 安全にゲストの命令列を実行できるようにすること • 「安全に」とは VMM や他の VM を阻害しないこと • ゲストの命令列には特権命令も含むことに注意 • CPU 時間をそのまま VM に与えてしまうと・・・ • ゲスト OS が特権命令を実行してしまう • ゲスト OS はホスト計算機を占有していると思い込んでいるため他の VM や VMM の状態を壊してしまう

8. De-Privileging • ゲスト OS を非特権モードで実行すること • ゲスト OS の特権命令により，VMS の整合性が破壊されるのを防ぐため • 特権命令を実行しようとすると保護例外が発生する • VMM に制御が移る（VMM は特権レベルで動作している） • VMM では特権命令をエミュレートする • ゲスト OS は特権命令が期待通りに実行できたと勘違いする • 特権命令のエミュレート例： • ある VM がcli (割込禁止命令) を実行 • 保護例外が発生し，VMM に制御が移る • 割込禁止の VM 宛ての割り込みは配信待ちにする • 実 CPU の割り込みが禁止されるわけではない • なぜなら，他の VM では割り込みを待っているかもしれないから

9. センシティブな命令 • 特権命令の実行だけを防止すればいいのではない • 正確にはセンシティブ命令の実行を防止しなければならない • センシティブ (sensitive) 命令： • ゲスト OS が直接実行してはまずい命令のこと • 直接実行すると VMM やホスト OS と干渉する恐れがある • 例： I/O 命令 • センシティブではない普通の命令を innocuous 命令という • センシティブ命令と特権命令の関係 特権命令 すべての命令 センシティブ命令

10. センシティブ命令の例 • システムの状態を参照する命令 • 例：プロセッサの動作モードを参照する命令 • ゲストOS に次のようなコードが含まれるとまずい m ← プロセッサの動作モード; if (m != priviledged) { /* 何かおかしい */ panic(); } • 例：プロセッサの動作モードにより処理内容が異なる命令 • Intel x86 の POPFスタック上の値をフラグレジスタに読み込む命令 • フラグのひとつは割込許可フラグ • POPF を使って割込許可フラグを変更しようとすると・・・ • 特権モードでは，割込許可フラグが変更できる • 非特権モードでは，割込許可フラグの変更は無視される • 無視されるだけで保護例外は発生しない

11. （古典的な意味での）仮想化可能な CPU • CPU が仮想化可能 (virtualizable) であるとは，センシティブ命令が特権命令の部分集合であること • 上記の包含関係が成立していれば・・・ ゲスト OS は非特権モードで動作しているため， • ゲスト OS はセンシティブ命令を直接実行できない • センシティブ命令を実行すると保護例外が発生する すべての命令 特権命令 センシティブ命令

12. 資源の仮想化ーメモリ • 各 VM は物理メモリを独占していると思っている • 物理メモリは 0 番地から始まる • 物理メモリは連続している • 実際には？ • ホスト計算機の物理メモリを分け合って使っている • 物理メモリは 0 番地から始まるとは限らない • 物理メモリは連続しているとは限らない • にもかかわらず・・・ • 各 VM には 0 番地から始まる連続したメモリがあると思わせたい

13. 2 段階のアドレス変換？？？ • メモリを仮想化するには 2 段階のアドレス変換が必要 • 一段階目のアドレス変換： • 仮想アドレス → ゲスト物理アドレス • ゲスト OS が両者の対応を管理している • 二段目のアドレス変換： • ゲスト物理アドレス → ホスト物理アドレス • VMM が両者の対応を管理している • 用語： • 仮想アドレス (guest virtual addr; gVA)： • VM 上の仮想アドレス • ゲスト物理アドレス (guest physical addr; gPA)： • VM 上の物理アドレス • ホスト物理アドレス (host physical addr; hPA)： • ホスト計算機上の物理アドレス • 通常の MMU では 2 段階のアドレス変換はできない • 通常の MMU を使って 2 段階変換を実現する方法は？

14. 資源の仮想化ー I/O • ゲストOSは I/O デバイスを独占していると思っている • I/O デバイスを多重化してゲスト OS に見せる必要がある • ゲストOSの見ているデバイスを仮想デバイスという Virtual Device Virtual Device Virtual Device ・・・・ I/O Virtualization Device Driver Device

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

16. Commodity PC の仮想化 • VMware WS の成し遂げたこと • 広く普及した PC プラットフォームの仮想化 • 古典的な仮想化技術をそのまま使うのは難しい • trap & emulate, VMM による全デバイスの管理・・・ • 仮想化への障壁 • 仮想化できないプロセッサ： • Intel x86 には sensitive but unprivileged 命令がある • PC ハードウェアの多様性： • 膨大な種類の PC 用デバイスが存在する • VMM がすべてのデバイスドライバを持つことは不可能 • プレインストールされたソフトウェア資産： • PC には OS やアプリケーションがインストール済み • インストール済みのソフトウェアを使い続けられる方式が必要

17. 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 処理をホストに丸投げ

18. VMware WSにおける CPU 仮想化 • BT (Binary Translation) • Innocuous 命令は直接実行する • Sensitive (either privileged or unprivileged) 命令はエミュレート • エミュレータ呼び出しに置き換える • 多くの場合，インライン展開してしまう ・ ・ mov%ecx, %edi mov %esi, $2 popf cmp %esi, %ecx ・ ・ ・ ・ mov%ecx, %edi mov %esi, $2 《callemulator》 cmp %esi, %ecx ・ ・ Binary Translation 実行したいゲストのコード 実際に実行するコード

19. BT で除去できない Sensitive 命令 • ページテーブル，割り込みベクタ等へのアクセス • 通常のmov命令でアクセスされるため，BT で削除するのは難しい • どうやってページテーブル等へのアクセスだと知るのか？ • VMMのほうでメモリ保護しておく • trap が頻発するならエミュレータ呼び出しに切り替える • trap の頻度によって， • エミュレータ呼び出しを使う場合とmov命令を使う場合とを • 適応的に切り替える

20. メモリの仮想化 仮想 CR3 ゲストの仮想ページ (virtual) page table gVA → gPA ゲストの物理ページ CR3 page table ホストの物理ページ gPA (?) → hPA 二段階のマッピングをどうやって実現するの？

21. Shadow Page Table • ハードウェアによるアドレス変換に使われるページテーブル • Shadow Page Table に gVA → hPA の対応を格納する 仮想 CR3 ゲストの仮想ページ (virtual) page table gVA → gPA ゲストの物理ページ shadow page table CR3 ホストの物理ページ gVA → hPA HW はこちらを使う

22. 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 などなど

23. 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上のコードが少なくて済む

24. パケットの受信 VMApp Guest OS 3. ask packet transfer 2. select() returns 5. copy packet & raise virtual IRQ 6. IN/OUT to I/O port VMM Virtual NIC Host OS VMDriver VMNet Driver 4. World Switch Host Ethernet Driver 7. VMAppの呼び出し 1.Device Interrupt VMM World で割込を受け取ると， Host World にスイッチしてから， Host OS でパケットを受信する Ethernet H/W

25. オーバーヘッドの削減 • 理想的な仮想デバイス・インターフェスを用意する • 例：単一の OUT 命令でパケット送信可能な NIC • IN/OUT 命令のエミュレートに必要な World Switch が減る • ゲスト OS には理想デバイス用のドライバを入れる • 仮想化のオーバーヘッドを軽減するため，ゲスト OS 側で少し仮想化に対応してもらう • 準仮想化 (paravirtualization) の考え方

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

27. ハードウェアによる仮想化支援 • ソフトウェア仮想化は大変 • 特に x86 は仮想化との相性が悪い • Sensitive but unprivileged 命令 • Hardware-walk のページテーブル • ソフトウェア TLB であればまだ楽 • 完全仮想化は地獄．VMware はたいしたもの • ハードウェアで仮想化を支援しましょう • 仮想化を実現するソフトウェアがシンプルにできる • 必ずしも性能が向上するわけではない • 当然の流れ • Intel VT, AMD-V, などなど他にもたくさん

28. 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 の仮想化支援はだいたい同じ • 細かいところが違うが，概念的には（近似的には）同じ

29. VMX モード • リング保護とは直交した新たな保護モード • VMX root モード： VMM が動作するためのモード • VMX non-root モード：ゲストが動作するためのモード VM Exit アプリケーション ゲストOS VMM VM Entry VMX non-root VMX root

30. 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 モードに復帰する

31. モードの遷移 VMX root モード (VMM) VMX non-root モード (VM) 通常モード VMXON VM Entry VM Exit VM Entry VM Exit VMXOFF

32. Event Injection • ゲスト OS にイベントを送り込む仕組み • VM entry 時に，指定したイベントを配信することができる • イベント = interrupt or exception • ゲスト OS から見ると • VM entry 直後に指定されたイベントが起きたように見える • したがって，ゲスト OS の IDT を使ってハンドラが起動される • VMM で補足したイベントの再送に便利 • イベントの再送メカニズムをエミュレートする必要がない

33. 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 の変換を行う

34. Extended Page Table の仕組み • Extended Page Table という別のテーブルを持つ • guest physical addr → host physical addrの対応表 EPT Ptr

35. 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 を参照する

36. 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

37. デバイスへのアクセスとメモリ管理 • デバイスの仮想化 • QUEM によるデバイスエミュレーションを利用する • ゲスト OS がデバイスにアクセスすると・・・ • VM exit が発生し KVM モジュールに処理が移る • KVM モジュールは必要に応じて QEMU を呼び出す • メモリ管理 • Extended Page Table を使う • Extended Page Table がサポートされていなければ，Shadow Page Table を使う

38. Intel VT-d: I/O の仮想化支援 • I/O デバイスを多重化するためのハードウェア支援 • DMA Remapping (IOMMU) • Interrupt Remapping • デバイスの Direct Assignment を目指す • ゲスト OS が直接デバイスを制御する • 各 VM 専用の I/O デバイスが存在するイメージ • マルチキュー NIC などの利用を想定 • I/O エミュレーションのオーバーヘッドがない • ゲスト OS のデバイスドライバがそのまま利用できる • VMM を小さくすることができ VMM の信頼性が向上する • デバイス特有の機能を最大限に活用できる

39. DMA Remapping • ゲストOSが占有するデバイスのDMAを安全に行う • 解決したいこと： • DMAではデータの転送先アドレスを物理アドレスで指定する • ゲストOSが物理アドレスの設定を間違えると致命的 • 他のゲストOSやVMM自身のメモリが破壊される可能性がある • VMMでチェックすればいいのでは？ • ゲストOSからのDMA要求を横取りし，VMMでチェックする • 安全性は保証できる • VMMでデバイスドライバを持つ必要が出てくる • Direct Assignment の考え方に反する • VMMでチェックせずに安全性を保証したい！

40. IOMMU • デバイスアドレスから物理アドレスの変換機構 • デバイスアドレス： • I/O デバイスが見ている仮想アドレスのこと Main Memory Physical Address IOMMU MMU Virtual Address Device Address Device CPU

41. IOMMU の拡張による DMA Remap • デバイスごとに別々のデバイスアドレス空間を持つ • デバイスごとに別々のアドレス変換表を持つ • プロセスごとに別々のページテーブルを持つのと同じ • ゲストOSが指定したgPAに書き込まれることを強制できる • デバイスアドレス変換表では， guest physical addr → host physical addr の変換を行う Address Translation Table Device mapping structure PCI requester ID

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

43. 仮想マシン技術のもたらすもの • 計算機そのもののカプセル化 • 計算機を物理的なハードウェアから分離できる • 計算機を「電子的に」移動・複製が可能になる • 計算機をいつでもどこでも好きなところで好きな数だけ実行できる • カプセル化の手順 • VM のスナップショット機能により，計算機を“カプセル化” • “カプセル化”した計算機を複製・移動する • スナップショットはただのデータ．複製も移動も容易 • スナップショットを編集することも容易 • カプセル化の仕方を少し変えると・・・ • VM cloning: 計算機のコピーを on demand に素早く作る技術 • Live migration: 計算機を止めずに移動する技術 • Remus: 待機系の計算機をうまく作る技術

44. 仮想化とクラウド • クラウドコンピューティングが広く利用されている • 特長の一つとして，リソースの伸縮性（Elasticity）がある • メモリやCPU など，リソースの増減を自在に行える性質のことで，負荷状況に合ったリソース量を維持できる • 負荷増加時には，新たに VM を生成してリソースを追加する 現行のクラウドサービス（例：Amazon EC2） VM 1 負荷が大きく， 処理仕切れない VM 2 インターネット VM 3 新たな VM を生成 （= インスタンスの追加） ロードバランサ

45. VM Cloning 稼働中のVM のコピーを作る技術 • リソース追加に時間がかかり，突発的な負荷増加に素早く対処できない • VM の起動は，時間を要する処理であるため • Amazon EC2 では VM の起動に約 2 分かかる • メモリの無駄遣いが生じる • 一時的に少しだけリソースを増やしたい場合でも，フルサイズのメモリを割り当ててしまうため • VM 起動直後のパフォーマンスが低い • 起動直後はキャッシュが存在しないため

46. Previous Work • Live VM Cloning with SnowFlock [Lagar-Cavillaet.al. ’09] • 負荷増加時に，VM のクローンを迅速に作成する手法 • 親 VM の最低限の情報からクローンを作成し，稼働させる • 子 VM のメモリ内容は，オンデマンドにコピーしていく • 子VM 生成直後のパフォーマンスが著しく低下する • 負荷が長期間にわたって増加する場合は大きな問題にならないが，短期的な負荷増加の場合は問題となる クローンを作成 へアクセスしたい へアクセスしたい 子 VM 1 親 VM 子 VM 2 メモリ メモリ メモリ オンデマンドにコピーする

47. 提案：Kaleidoscope • クローン VM 作成に要する時間を短く抑えつつ，VM 起動直後のパフォーマンスを保つクローニング手法 • 提案手法の特長 • 負荷増加時，クローン VM を迅速に生成できる • クローン VM 起動直後のパフォーマンス低下が小さい • ユーザのニーズに応じたメモリ割り当てにより，無駄がない 負荷増加時の挙動 新 VM 稼働 time Amazon EC2 新 VM 作成時間 クローンVM 稼働（パフォーマンス低下） SnowFlock time クローン VM 作成時間 クローン VM 稼働 Kaleidoscope time

48. アプローチ • 二つのメカニズムを用いて，クローン VM 起動後のパフォーマンス低下を防ぎ，無駄なくメモリを使用する • VM state coloring • クローン VM が起動後に必要としそうなデータを起動前にプリフェッチする or VM 間で共有する • Fractional allocation • VM state coloring によってプリフェッチされたメモリ領域以外にはメモリを割り当てない • プリフェッチされた領域以外にアクセスされた場合は，メモリを割り当てて親 VM からオンデマンドにメモリ内容をコピーする クローン VM 起動後のパフォーマンス低下を防ぐことができる クローン VM に対するメモリの無駄遣いをなくすことができる

49. 実環境でのパフォーマンス評価 • CPU 使用率の制限を変化させながら，要求を満たせなかった時間の累計を測定した • Kaleidoscope は従来の Elastic Cloud よりも，要求を満たせなかった時間が短く，高いパフォーマンスを出すことができた • Kaleidoscope はスレッショルドが 90 % の場合でも，Elastic Cloud のスレッショルド 50 % 時よりも高いパフォーマンスを出せた 低パフォーマンス VM Creation Threshold = 90 (%) とは， システム全体としての CPU 使用率が 70 ~ 90 % になるように，リソースの増減を行うことを表す． VM Creation Threshold = 60 (%) ならば，40 ~ 60 % マシンに無理強いする環境

50. Live Migration • VMを稼働させたまま別の物理マシンに移送する技術 • HWのメンテナンスやアップグレードを容易にする • 移送時のシステムのダウンタイムを最小化し、システムの移送による影響を隠す • サーバを落とすことは大きい損害に繋がる • ディスクの移送は行わない • データセンタ環境を想定し、各VMはネットワークストレージに接続していることを仮定 Live Migration 稼働中