コンテナ型仮想化とはなんだったのか
DESCRIPTION
2014/09/06 第4回 コンテナ型仮想化の情報交換会＠東京 発表資料TRANSCRIPT
コンテナ？それfreebsdでもできるよ！
2014/09/06第四回 コンテナ型仮想化の情報交換会@東京
by @m_bird
1
Ver.0.9.1
おはようごJail!
2
主催者「なんかFreeBSD Jail話してよ」
• Jailの話まで辿り着けませんでした
3
コンテナ？それfreebsdでもできるよ！
2014/09/06第四回 コンテナ型仮想化の情報交換会@東京
by @m_bird
4
コンテナ型仮想化とは なんだったのか？
2014/09/06第四回 コンテナ型仮想化の情報交換会@東京
by @m_bird
5
オマエ is 誰• FreeBSD6からのゆるふわFreeBSD使い • Just User, Not Developer
• 自宅はFreeBSD + Debian（KVM Host）
• ピチピチの20代
• 飲み友達募集中（ガールなら尚良し）
6
オマエ is 誰• 本業 • ドライブ • 読書 • 小説執筆 • vim + LaTeX
• 余暇 • エンジニア？ • インフラ寄り • 興味 • VMM • ファイルシステム
7
お伝えしたいこと• VMWare流行った！ • 何でもかんでも完全仮想化！
• KVM流行った！ • 何でもかんでもKVMにマイグレーション
• クラウドマネジメントツール流行った！ • 管理楽になるんでしょ？どうにゅ……
8
最悪死に至る
9
むしろ運用コストあがったにゃん……
お伝えしたいこと• 仮想化について、概念を振り返る
• 完全仮想化とコンテナ型仮想化（OSレベル仮想化）について比較
• ナウでヤングでグッチョイスな環境の構築の第一歩に
• ただしコンテナ型仮想化はFreeBSD jailしか触っていないので、jailをベースとしてお話します
10
今日のお話• コンテナ型仮想化とは何だったのか
• 完全仮想化との比較
• コンテナ型仮想化の使いどころ
• コンテナ型仮想化のキモ
コンテナ型仮想化の構成要素の再認識
11
！注意！ 本発表には発表者個人の主観が多分に含まれています
12
そう思うんならそうなんだろう。 おまえん中ではな
!
（ゆのっち画像）
てかJailやってる？（笑）
13
FreeBSD Jail• コンテナ型仮想化
• FreeBSD 4（2000年）に登場
• chroot を強力進化！ • UID空間、プロセス空間、ファイルシステム空間の分離を強化
LinuxでいうLXC的なサムシング
14
その他コンテナなサムシング• Solaris Zone • Solaris10で登場（2005） • コンテナ環境でSolaris8や9が動く • Solaris Legacy Containers †
†http://jp.fujitsu.com/platform/server/sparcenterprise/solution/virtualization/oslc/
@satokaz さんの発表でこの後すぐ！15
ほんとコンテナの仮想化便利なｗ どこ住み？
なにディストリ使い？
16
「仮想化」ってゆーなー！
17
さあ、要件定義の話をしようどんなアーキテクチャなら、仮想化って言えるのさ
18
PopekとGoldbergの仮想化要件• “Formal Requirements for Virtualizable Third Generation Architectures”(1974)†で示された
• 仮想計算機を提供するVMMたりえる要件を定義
• 命令を3つに分類し、VMMではそれぞれどのように扱えばよいかを示す
• それぞれの命令をどのように扱えば、VMMたり得るか？の定理を示す
†GJ Popek, RP Goldberg - Communications of the ACM19
PopekとGoldbergの仮想化要件
• 等価性(Equivalence) • 実機上で実行される場合と、仮想計算機モニタ（VMM）上で実行される場合とで作用が同じ
• 効率性(Efficiency) • 大部分の命令実行を、CPU上で直接実行可能
• 資源管理(Resource Control) • VMMはゲストOSの資源を完全に制御できる
仮想計算機を提供するVMMの持つ3つの特性
20
3つの命令• 特権命令 • ユーザーモードで動作中ならばトラップすべき命令
• 特権センシティブ命令 • システムの資源状態を変更する命令
• 動作センシティブ命令 • システムの状態に結果が依存する命令
命令セット特権命令
センシティブ命令
こんな感じなら そのアーキテクチャ仮想化OKよ
21
アーキテクチャって、そっちのアーキテクチャの話かよ
22
そもそも、”仮想化”の前提概念が違う
23
それぞれの仮想化
24
VMMHardware
VM VMOS OS
OSHardware
container container
完全仮想化(TypeI) OSレベル仮想化(コンテナ型仮想化)
もう一度要件に立ち返る
• 等価性(Equivalence) • 仮想計算機モニタの上で実行される場合と、VMM上で実行される場合とで作用が同じ
• 効率性(Efficiency) • 大部分の命令実行を、CPU上で直接実行可能であること
• 資源管理(Resource Control) • VMMはゲストOSの資源を完全に制御できる
25
もう一度要件に立ち返る
• 等価性(Equivalence) • 仮想計算機モニタの上で実行される場合と、VMM上で実行される場合とで作用が同じ
• 効率性(Efficiency) • 大部分の命令実行を、CPU上で直接実行可能であること
• 資源管理(Resource Control) • VMMはゲストOSの資源を完全に制御できる
コンテナ環境
コンテナ環境のホスト26
よし。 仮想化“っぽい”要件を考えよう
27
仮想化“っぽい”要件• 「1コンテナ1独立環境」に見えること • ファイルシステムが分かれている
• ユーザカウントの分離
• プロセス空間分かれている
進化した chroot 環境28
FreeBSD jail の出発点
それぞれの特徴を見てゆこう！
発表者の気まぐれ補足 ～完全仮想化との比較を添えて～
29
仮想化っぽい：ファイルシステムが分かれている
• ホスト環境のファイルシステム階層を一部切り出す • コンテナ環境を、その階層以下にとじ込める（jailed）
• ある特定ディレクトリより上位層を見ることができない（chroot）
• 他コンテナのファイルシステムは覗けない • ただし、コンテナのホストからはコンテナ環境のファイルシステム階層が見える（ホストからみると未分離）
完全仮想化では、ホスト環境からみても分離されている
30
完全仮想化との比較：ファイルシステム
• ファイルアクセスが早い • 完全仮想化で一番問題になるのはI/Oの遅さ
• ホストからゲストのファイルが操作可 • 完全仮想化だとディスクイメージをブロックデバイスとして扱い、マウントして……大変！＞＜
31
補足：完全仮想化におけるI/O速度の低下
• 問題点：コンテキストスイッチの切り替え
32
Hardware
VM
Host
OS
OS
VMM
Process
GuestVMExit VMEntry
補足：完全仮想化におけるI/O速度の低下
• コンテキストスイッチを減らすための工夫 • virtio†：準仮想化I/Oフレームワーク
• リングバッファなどを用いてコンテキストスイッチを削減
• 仮想化環境で用いられることを意識＝準仮想化ドライバ
33
† R Russell. "virtio: towards a de-facto standard for virtual I/O devices", ACM SIGOPS Operating Systems Review, 2008
補足：完全仮想化におけるI/O速度の低下
• 問題点：ファイルシステムのスタック
34
Disk
File System
Disk Image
File Systemwrite
write
process
補足：完全仮想化におけるI/O速度の低下• ファイルシステムのスタックの回避 • VirtFS†1
• Plan9由来の9pプロトコルを用いて、ホストOSのファイルシステムを直接マウント
• WFS†2
• ゲストホスト間RPC ”VMRPC”†3 を用いて、ゲストOSからホストOSのファイルシステムをマウントを行う
35
†1 V Jujjuri, E Van Hensbergen. "VirtFS̶A virtualization aware File System passthrough". Ottawa Linux Symposium. 2010
†2 豊岡拓， 新城靖， 齊藤剛. “ホスト型仮想計算機環境におけるファイル入出力の VFS アウトソーシングによる高速化”. 情報処理学会第 21 回コンピュータシステムシンポジウム,2009
†3 齊藤剛， 新城靖， 榮樂英樹， 佐藤聡， 中井央， 板野肯三. "仮想計算機におけるアウトソーシングのためのゲスト‒ホスト間 RPC", 第 20 回コンピュータシステム・シンポジウム,2008
補足：完全仮想化におけるI/O速度の低下
実機上
virtfs（仮想化ファイルシステム）
準仮想化ドライバ
ブロックデバイスエミュレーション(IDE)
0 25 50 75 100
41%
81%
99%
100%
速度(%)
36
• ホストOS • CPU Intel Core 2 Duo • VMM qemu-kvm 0.14.0 • メモリ 4GB • OS Linux 2.6.32 • ディスクデバイス Serial ATA ディスク
• ゲストOS • CPU 1 コア割り当て ‒ メモリ 512MB • OS Linux 2.6.32
コンテキストスイッチの切り替え、 ファイルシステムの重複のオーバヘッドが分かる
つまり……• ファイルI/Oに関して、コンテナ型仮想化はすごいお得！ • ディスクエミュレーション要らない
• ファイルシステムが重複しない
• オーバーヘッドがほとんどない（はず）
37
仮想化っぽい：アカウントの分離
• アカウント管理ファイルが分離 • /etc/passwd だとか、 /etc/shadow だとか
• ファイルシステムの分離による
• ユーザID空間の分離 • ユーザIDの重複も可能に
• ホストや他コンテナのUIDを意識しなくて良い
38
• Linux LXC：2013年末の Linux 3.12で User Namespaceの実装が完了
• FreeBSD Jail：FreeBSD4.0登場当初（2000年3月）から使えた（はず）
仮想化っぽい：ファイルシステムが分かれている
• 見えるのは、自コンテナ内のプロセスのみ • あるコンテナ内から、別コンテナ内のプロセスへは干渉できない
• あるコンテナのアプリがクラックされても、ほかアプリへの影響が最小限に
39
完全仮想化との比較：プロセス空間• 利点：コンテナごとのプロセス制限が可能に！ • 今までは、プロセスごとに制限
• limit(シェル組み込み) : syscall getrlimit/setrlimit
• 欠点：ホストからは丸見え • 欠点、というよりも特徴か
• ホスト環境から、ゲストのプロセスを殺すことが可能
• 完全仮想化の場合は、ホストOSからもゲストOSのプロセスは見えない
40
わかった！ コンテナってすげー強いってことだな！
41
仮想化の要件をちょっと都合良く解釈してやれば、仮想化とも言えるし、オー
バーヘッド少ないし！
※ 発表者の主観です
で、だ。
42
実装どうなってんのさ• 突っ込んだ話はしません（できません）
• Linux ：cgroups • 本日のトップバッター @hiro_kamezawa さんの発表が凄い充実していましたね！
• FreeBSD：jailシステムコール
• see: $ man 2 jail
43
FreeBSD: jail System Call• jail 環境(コンテナ環境)へ割り当てる • 割り当てるルートファイルシステムのパス
• 割り当てるアドレス（v4/v6）
• ホスト名
• jail名
44
FreeBSD: jail System Call
45
struct jail { uint32_t version; char *path; char *hostname; char *jailname; unsigned int ip4s; unsigned int ip6s; struct in_addr *ip4; struct in6_addr *ip6; };
リソース分割/制限について 特にプロセス数とか
46
コンテナを仮想化としてみた時のキモ
コンテナ環境を、 あたかも独立した環境かのようにみせる
kernel
container container
コンテナ他環境とを疎にするのはkernel
各コンテナは Kernelを共有
各コンテナ毎の リソース分割がキモ
47
そもそもはUnixは……
• 一台物理マシンを皆で利用しよう！ • ユーザ間での資源の共有
• ユーザランドのプログラムに、計算機資源をそれぞれに分配する
• リソースの割り当て単位に、概念追加 • コンテナ単位での制限、という括り
48
資源共有 今昔• 昔 • 皆で小さいリソースを分け合う
• 今
• 一台で色々役割もたそう、中で分離して
• 資源あまってるし
49
資源共有 完全仮想化？• 一台に詰め込むための完全仮想化 • CPUは効率的に使える
• メモリは無駄食いしてしまう
• そもそも、エミュレーション使ってまでの環境分離は必要？
• 今完全仮想化を使ってる目的の大半はコンテナで良いのでは？
50
リソース制限• 完全仮想化ならば、VMMで仮想計算機に割り当てるリソースを制御 • ディスクイメージサイズ、CPUコア数、ネットワーク帯域……etc
• コンテナ型仮想化では、コンテナホストでリソース制限を実施
51
リソース制限の重要性• 危険シェル芸 • :(){ :|:& };:
52
リソース制限の重要性• 危険シェル芸 • :(){ :|:& };:
53
% :(){ :|:& };: (snip) maxproc limit exceeded by uid 1001 (pid 9020); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12751); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12673); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10873); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 11813); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 7875); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13779); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10694); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13842); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 9440); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13047); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13796); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 11419); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) kern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 8605); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 12225); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10820); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 10820); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 12592); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 11193); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12641); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12176); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10976); see tuning(7) and login.conf(5)
リソース制限の重要性• 危険シェル芸 • :(){ :|:& };:
• ＞シリアルコンソールログイン不可！＜
• ＞ACPI shutdown 受け取らず！＜
• VM を ﾃﾞｽﾄﾛｰｲ……
54
リソース制限の重要性• :(){ :|:& };:
• forkbomb(){ forkbomb|forkbomb & } ; forkbomb
• fork爆弾、プロセスを再帰的にfork
• 「プロセステーブル、メモリ、ゼンブ クイツクス！」
55
bomb
bomb bombfork
fork fork
＿人人人人人人人人人人人＿ ＞ ずっとforkのターン ＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y^Y‾
fork爆弾を食い止めろ！• ユーザ権限でOS全体をハングさせることが可能 • ユーザごとの利用可能資源を制限すべし
• 多数のユーザアカウント発行するサービス（レンサバ）とか特にまずい
• さくらたんさんあたりが特にノウハウ持っていそうですね
56
非コンテナでのリソース制限• getrlimit/setrlimit を使った制限 • 4.2BSDで実装、POSIXでも定義あり
• Unix系OSなら使える
• シェル組み込みで”limits”コマンドで確認！
57
非コンテナでのリソース制限
58
% ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) 33554432 -s: stack size (kbytes) 524288 -c: core file size (blocks) unlimited -m: resident set size (kbytes) unlimited -l: locked-in-memory size (kbytes) 64 -u: processes 6670 -n: file descriptors 58293 -b: socket buffer size (bytes) unlimited -v: virtual memory size (kbytes) unlimited -N 11: unlimited -N 12: unlimited
デフォルト状態＠FreeBSD10-amd64
非コンテナでのリソース制限
59
% :(){ :|:& };: (snip) maxproc limit exceeded by uid 1001 (pid 9020); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12751); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 12673); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10873); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 11813); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 7875); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13779); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10694); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13842); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 9440); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13047); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 13796); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 11419); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) ern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 8605); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) maxproc limit exceeded by uid 1001 (pid 12225); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 10820); see tuning(7) and login.conf(5) kern.ipc.maxpipekva exceeded; see tuning(7) (snip)
デフォルト状態＠FreeBSD10-amd64
システム完全に沈黙
非コンテナでのリソース制限
60
% ulimit -u 1024 % ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) 33554432 -s: stack size (kbytes) 524288 -c: core file size (blocks) unlimited -m: resident set size (kbytes) unlimited -l: locked-in-memory size (kbytes) 64 -u: processes 1024 -n: file descriptors 58293 -b: socket buffer size (bytes) unlimited -v: virtual memory size (kbytes) unlimited -N 11: unlimited -N 12: unlimited
プロセス数制限変更＠FreeBSD10-amd64
非コンテナでのリソース制限
61
プロセス数制限変更＠FreeBSD10-amd64% :(){ :|:& };: (snip) maxproc limit exceeded by uid 1001 (pid 2632); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 2136); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 2644); see tuning(7) and login.conf(5) :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません maxproc limit exceeded by uid 1001 (pid 2136); see tuning(7) and login.conf(5) maxproc limit exceeded by uid 1001 (pid 2644); see tuning(7) and login.conf(5) :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません :: fork failed: リソースが一時的に利用できません (snip)
戻ってきた！
非コンテナでのリソース制限• FreeBSD • /etc/login.conf
• Linux • /etc/security/limits.conf
• あたりに書けば、そのユーザのプロセス全てに制限が適用
62
じゃ、コンテナでは？
63
Linux のお話はたっぷりだったので、少し FreeBSD jailのお話をします
64
jailの使い方• OS標準の仕組みでできます • /etc/jail.conf 書き書き
• jail の起動停止 • 起動 # jail -c ${JAIL_NAME}
• 停止 # jail -r ${JAIL_NAME}
65
www { host.hostname = "www"; path = "/usr/jails/www"; mount.fstab = "/usr/local/etc/qjail.fstab/www"; exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.consolelog = "/var/log/qjail.www.console.log"; devfs_ruleset = "4"; allow.mount.devfs; mount.devfs = "1"; ip4.addr = 10.0.0.3; interface = "lo1"; }
コンテナ(jail)環境での資源• FreeBSDのjailシステムコールには特にリソース制限ない • jail環境ごとのリソース制限は難しい
• じゃあ、どうすんねん？ • rlimitで頑張る？
• RACCT/RCTL66
RACCTL/RCTL• RACCTL • カーネル内の資源量を把握する
• RCTL • 資源の制限を行う
67
FreeBSD9(2012,10)にて実装
RACCTL/RCTL• 利用するには、GENERICカーネルじゃ駄目 • options RACCT • options RCTL • → カーネルビルド！
• 設定するには • /etc/rctl.conf
• ユーザランドツール：rctlコマンド
68
RACCTL/RCTL• syntax
• subject:subject-id:resource:action=amount/per.
• 左の例だと • -u: 現在の設定値出力
• -h: 人間さんが読む用
• user:m-bird
• m-birdユーザの制限設定値確認
• jailの場合 $ rctl -hu jail:${JAILNAME}
• $ rctl -hu jail:www
69
# rctl -hu user:m-bird cputime=137 datasize=48K stacksize=392K coredumpsize=0 memoryuse=6744K memorylocked=0 maxproc=1 openfiles=0 vmemoryuse=35M pseudoterminals=0 swapuse=0 nthr=1 msgqqueued=0 msgqsize=0 nmsgq=0 nsem=0 nsemop=0 nshm=0 shmsize=0 wallclock=270K pcpu=0
ざんねん！わたしのぼうけんはここでおわってしまった！
70
時間とは有限なのである• 他、やりたかったこと • LXCとJailでの実装の違いを追っかけて比較する
• ネットワーク仮想化（vimage/veth）
• 周辺ツールの比較
• dockerのFreeBSD対応
• cbsdを動かしてみる
• jailの管理している様子を実際に見せびらかす
FreeBSDの可愛らしさをアッピルする71
72
次回
せめて、BSDらしく
73
■警告 内容は発表予定もなく、現在作成中ですらないものです。 予告なく変更、中止などする場合があります。
その他FreeBSD jailで面白いこと• Jail環境でCentOS! • Linuxのバイナリ互換機能を利用
• https://wiki.freebsd.org/Image/Linux/CentOS55
• Linux互換機能、何か使えるの？
• SkypeやSkypeなどのLinuxバイナリを動かすのに利用
74
余談: Linux バイナリ互換
75
Linux は現在コンピュータの世界では最も「ホットなモノ」なのでたくさんの会社や開発者たちが Linux のためだけに開発を行なっています。そのため、残された私たち FreeBSD ユーザは彼らに対して FreeBSD ネイティブなアプリケーションも出すように言うしかないのです。
via: https://www.freebsd.org/doc/ja/books/handbook/linuxemu.html
参考資料• 佐藤広生. Jail機構と資源制御. FreeBSD勉強会. 2012
• http://people.allbsd.org/~hrs/FreeBSD/sato-FBSD20120608.pdf
• Unixの基礎概念からJailのリソース制限への発展について詳しい
• 読んでみると、今回の発表の内容がすごく分かりやすく丁寧に書かれているので、私の発表読むよりこちら読む方が勉強になります
• 長谷川 猛. とあるvirtioドライバの接続部分. 仮想化友の会恋バナ.2011 • http://www.slideshare.net/TakeshiHasegawa1/osc2011-tokyofall-virtio
• virtioを用いた準仮想化ドライバについて詳しい
• yuyarin. Kernel/VM Advent Calendar 38日目: 仮想化可能なアーキテクチャの要件とx86. yuyarinの日記. 2011 • http://d.hatena.ne.jp/yuyarin/20110113/1294889935
76
発表版との差異• 2014/09/07 Ver0.9.1 • 全体の話の流れを明確にするため、区切りの見出しスライドを追加
• スライドだけを見る人に対する対応
• 引用元をいくつか明示
• ゆのっち画像を削除
77