View
47
Download
0
Category
Preview:
DESCRIPTION
仮想マシン 技術 とその展開. 慶應義塾大学 理工学部 河野 健二. アウトライン. 仮想マシン技術の概要 計算機を “仮想化” するには何が必要か? 計算機の “仮想化” はどうやって実現されたか? ブレイクスルーとしての VMware Workstation 血と汗と涙の実装技術 誰でも (?) 作れるようになった VMM としての KVM 仮想マシン技術とクラウド クラウドのための要素技術の紹介 Live migration Remus Kaleidoscope. 仮想マシン技術とは?. 一台の計算機を複数台の計算機として使う技術 - PowerPoint PPT Presentation
Citation preview
仮想マシン技術とその展開
慶應義塾大学 理工学部河野 健二
アウトライン
仮想マシン技術の概要 計算機を “仮想化” するには何が必要か? 計算機の “仮想化” はどうやって実現されたか?
ブレイクスルーとしての 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 はネットワークスト
レージに接続していることを仮定
VM1
VM2
仮想マシン1
VM2
VM3
仮想マシン2
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 で転送
2回のダーティページコピーの後、 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) させることができる
Recommended