Presented by M.Miwa M.Suekane N.Tei 2002/1/21 © 2002 All rights reserved. Chapter 1 イントロダクション 用語解説１ VMM Virtual Machine Monitor（従来のバーチャルマシ ンで物理マシンとバーチャルマシンをつなげるアプリ ケーション層） VMware VMAｐｐ、VMM、VMDriverによって構成されるソフト ウェア VMApp a user-level application（いろいろなドライバが入っ ていて、I/Oデバイスを仮想化するアプリケーション） VM Driver Driver to switch between VMM and VMApp（ホス トワールドとVMワールドの切り替えドライバ） バーチャルマシンの歴史 バーチャルマシンは1960年代にIBMによって、 メインフレームコンピュータへの対話型の同 時アクセスを提供するために最初に開発され たもの 現在のVMware Workstationはメインフレー ムクラスのバーチャルマシン技術をPCディス クトップやワークステーションコンピュータに応 用させたもの 従来のバーチャルマシンの概念 非常に高価なメーンフレームハードウェアをタイム シェアリングする手段として使われる バーチャルマシンは完全に保護された独立の物理 マシンのハードウェアのコピーであって、ユーザはあ たかも自分専用のの物理マシンを持っているような 感覚が得られる ソフトウェア開発者達はプログラムを書くときや試す ときに、物理マシンをフリーズさせたり、ほかのユー ザに影響を与えたりすることを心配する必要がない バーチャルマシンを理解するため の予備知識 CPUの特権モードとユーザモードにつて CPUのプログラム実行モードに特権モードと非特権モード 特権モード（カーネルモード、スーパバイザモード）：あら ゆるハードウェア資源にアクセス可能、オペレーティング システムの実行モード 非特権モード（ユーザモード）：ハードウェア資源へのアク セスを制限、監視下でプログラムを実行、通常のプログラ ムの実行モード スケジューリングはむずかしい ある特権命令をするとVMMでトラップがおきる たとえば、二つの仮想マシンが同じ物理番地にアクセス するときなど 従来のバーチャルマシンの構造 I/Oデバイスにアクセス する時は特権モードに なる VMMが物理マシンの ハードウェアをコント ロールし、バーチャルマ シンを生成する 各バーチャルマシンが 完全な物理マシンのよ うにふるまって、独自の OSを走らせる Virtual Machine Monitorの動作 VMができるだけ直接ハードウェア上で動作 するようにすることが必要。 →パフォーマンス向上のため。 VMMは、 VMが他のVMやハードウェアでの 操作に支障をきたすような場合にのみ操作 (VMMが一旦制御を奪い、その操作を安全 な方法でエミュレートした後、VMに制御を戻 す。)を行う。 →個々のVMの保護、独立性の保証のため。 VMMの利点 一つの物理マシンの上でいくつかの異なる OSとアプリケーションを走らせる バーチャルマシンを異なる物理マシンの間 に移動させることができる バーチャルマシンのデスクはホストマシンのファ イルシステムになっている バーチャルマシンが一つの物理マシンの上 でいろいろなサービスを提供することできる ⇒しかし、従来のVMMが普通のPCに応用する事できない Chapter 1.1 PCプラットフォームの仮想化 普通のPCに応用できない従来の VMMが理由 バーチャル化できないプロセッサ 多様なハードウェアデバイス Intel IA-32 processor 多様なデバイスごとにドライバを作る時の労力は大変 従来のVMMは高価なメーンフレームコンピュータのハード ウェアのためにそれぞれのドライバを作ったが プリインストールされたソフトウェア（OS） Windows NT ，Windows 2000 and Linuxなど Chapter 2 ホスト化によるVMの仕組み 用語解説２ ゲストOS 仮想マシンの上で稼動するOS ホストOS ホストマシンの上で稼動するOS ホストマシン VMwareをインストールする実際の物理的マシン バーチャルマシン ゲストOSが稼動するVMwareが作る仮想的なマシン VMware Workstationとは？ 特徴 既存のOSとの共存が可能で、そのOS(Host OS)にデバイスサポートを任せる、ホスト化さ れた機構。 (＝Hosted Virtual Machine Architecture) CPUに集中的な負荷がかかってもNativeに 近い性能を実現。 OSに通常のアプリケーションと同様にインス トールされる。 VMwareの機構 VM AppがHost OSに ロードされたVM Driver を使ってVMMを確立。 VMMがCPUを仮想化、 VM AppがHost OSを 使ってデバイスをサ ポート、VM Driverが両 者の制御の移行をサ ポート。 従来のVMMとVMwareの違い 従来のVMMとVMwareの違い プロセッサに対する要求の低下 John Scott Robin&Cynthia E.Irvine 「Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor」→250個の命令のうち17個が仮想化に向かない。 さまざまのハードウェアへの対応 ドライバの作成のかわりにホストOSのファイルシステムを つかって仮想デバイスにする IDEとSCSI CD-ROM両方に対応できる ホストOSのほうから抽象のCD-ROMを提供してくれる プリインストールされたソフトウェアとの共存 VMwareはプリインストールされたOSに上にインストール される VMwareの従来のVMの問題点への対応 仮想化できないプロセッサ →ハードウェアへのアクセス（I/O操作)は全てHostへ 移行。 PCハードウェアの多様性 →デバイスのサポートをHostＯＳに任せることにより回 避。 例. CD-ROM(次ページ) プリインストールされたソフトウェア（OS) →アプリケーションとしてインストールされるため、もと のHostOSに影響は出ない。 PCハードウェアの多様性への対応の例 CD-ROMにはIDEとSCSIが存在。 VMでは それぞれのデバイスドライバ、プログラム が必要。 VMwareでは HostOSから仮想化されたCD-ROMが提供 され、VMMはそれをCD-ROMとして認識。 →仮想化CD-ROMへのドライバ、プログラム を一つ持てば全ての規格に対応。 VMwareのホスト化の問題点 I/Oパフォーマンスの低下 →I/Oへの集中的な負荷に対し、VMMとホストのworld switchが頻繁に起こり余分なCPU負荷を引き起こす。 HostOSの完全なマシンリソースの支配による影響 → HostOSは、少量を除いて、VMMに割り当てられた メモリを使用可能であり、VMMへのリソース割当て に失敗すると性能が犠牲になる。 ⇒以下、特に最も影響の大きいI/Oパフォーマンスの 低下に焦点を当てる。 Chapter 2.1 I/Oデバイスの仮想化 VMwareのVMのデバイス構成 PS/2キーボード、マウス フロッピーディスクドライブ ATAディスクやATAPI CD-ROMのIDEコントローラ Sound Blaster 16 サウンドカード シリアル/パラレルポート 他に仮想BusLogic SCSIコントローラやAMD PCNet Ethernetアダプタ、VMware仮想ディスプレイカード 対応SVGAビデオコントローラを仮想PCIスロットに取 り付け可能。(SVGA以外はOSにドライバ付属) I/Oデバイスのバーチャル化 VMMがゲストOSのI/O操作をすべて受け取る PCの中で、プロセスは特権モードのIA-32 IN/OUT 命令で行われている 物理デバイスにアクセスするとき、必ずVMAｐｐがコ ントロールをする、アクセスしないときはVMMで処理 できる場合もある。 ステータスポートやあとで使用するデータの保持はVMM で処理することができる 仮想化するデバイスを減らせば、処理すべきI/O ポートもしくは把握すべき状況を減らすことができる I/Oデバイスのバーチャル化による 問題（オーバヘッド） I/Oデバイスのバーチャル化のとき、ホストとVMMの スイッチングのためにオーバヘッドが起こりうる 高い転送率と短い呼び出し時間の場合のみ 逆にキーボードはこの仕組みにとても適している ハードウェアとコミュニケーションするときの特権 モードをコントロールするためのコスト →上記のデバイスの条件を満たすものとして、 Network interface card (NIC) があり、以下で はこれを例として取り上げる Chapter 2.2 NICの仮想化 Network Interface Card NIC=Ethernetカード Ethernetとは？ 安易かつ低コストでLANの構築が可能なため、 LANの代名詞的存在 語源はエーテル（Ether）:伝達を媒介するもの EthernetとPCを接続するハードウェアがNIC スループットが大きく遅延の小さいデバイス の代表例（i.e.オーバーヘッド改善の余地の 大きいデバイス） NIC Ethernet 仮想NIC NICをエミュレートしたものが仮想NIC NICのエミュレーションは二種類ある 1. 2. hOSの物理NICと同じ物理ネットワークと接続 hOS上の仮想ネットワークと接続(今回は扱わない） ⇒いずれもVMNet Driverにより実現 仮想NICの動作 パケット送信 仮想NICは自分固有のMACアドレス付のパケット を送信する パケット受信 VMNet Driverが仮想ネットワークHUBとブリッジ した物理NICを無差別モードで動作させ、LANを 監視する 自分のMACアドレス宛パケットがあったら受信 表面上の動作は完全に「仮想NIC＝物理NIC」 スピードはどうか?次項で動作を細かく追ってみる Chapter 2.3 仮想NICによるパケット送受信 NICの動作：パケット送信 パケット送信はLanceポートへのアクセス をエミュレートするためにVMMだけでは処 理できず、VMApp（Host World）への切替 が必要 点線部はポートアクセスを仮想化することによるオーバーロード部分 NICの動作：パケット受信 hOSのNICはパケットをVMNetに 送信するので、VMAｐｐは定期的に select()をVMNetドライバに発行し てgOSに送るべきパケットの有無を 確認する gOSに送るべきパケットがあった らIRQを発行して受信処理 最後にACKをhOS側（物理ネット ワーク）に発行する 点線部はポートアクセスを仮想化することによるオーバーロード部分 仮想NICによる送受信のまとめ ポートアクセスの仮想化において VMMの内部で処理できずにホスト 領域のVMAppに切り替えて処理す る、余分なオーバーヘッドが生じる ⇒ これらのオーバーヘッドはI/O性 能とCPU負荷にどれくらいの影響 を与えているのだろうか？ ⇒ ネットワーク処理におけるVMMとVMAｐｐの時間配 分について次章で検討する Chapter 3 仮想マシンにおける ネットワーク性能の検証 概要 余分なオーバーヘッドのため送受信の遅延や CPUの独占が起きている！！ OVERHEADS 1. 2. 3. VMがハードに直接アクセスするときに必ず発生する VMMとhOS間のworld switch I/O割込処理にVMM/gOS/hOS 3つのI/O割込が必要 gOSのパケット転送は・・・ gOSのドライバとhOSのドライバ双方を伴う gOSの物理メモリからhOSのカーネルバッファに余計なコピー が必要 ⇒ World Switchの回数を少なくする最適化をすると・・・ 低速マシンはTCP転送を倍速にできた ⇒ 高速マシンはCPU使用率を下げることができた Chapter 3.1 パケット転送に関する実験 3.1 実験環境 ２台のPCの性能 PC-350 PentiumⅡ350MHz 128MB RAM Linux2.2.13kernel For VM（VMware2.0) 64MB RAM PC-733 PentiumⅢ733MHz 256MB RAM Linux2.2.17kernel For VM （VMware2.0) 128MB RAM ゲストOSはRedHatLinux6.2（2.2.17-14kernel) VMのNICはvirtual AMD Lance NIC (Lance=Local Area Network Controller for Ethernet) ドライバはPCNet32ドライバ Experiment 1 前述の2台のPCを100MbpsのNICとクロス ケーブルを用いて接続。 100MBのデータを4096BytesごとにPC-733か らPC-350に転送したが・・・ ⇒ 64Mbpsしかスピードが出ない・・・ (i.e. CPUの速さに性能が縛られている) ⇒ どこでCPU時間を消費しているのか を次の実験で調べる Experiment 2 目的 パケット転送におけるCPU時間の消費部分の 判定 方法 PentiumのTime Stamp Counterレジスタを用 いて時間を計測する。TSCレジスタを用いると 無駄な関数呼び出し時間を使わずに各部分 の時間を測定可能。 Experiment 2 Experiment 2: behavior of sustained VM TCP transmits VMNet Driverがパケット転送を行っている17.55μsのところと 開始処理と終了処理のところは転送に必須の部分であり、そ れ以外(13.10μs)が短縮可能なオーバーヘッドである。 Experiment 2 考察 この仮想化によるオーバーヘッドだけでは全体のオーバー ヘッドがCPU制限になる理由を説明することはできない(ヘッ ダを除いた1520Bytesの転送が31.63μsとすると100Mbitを たった0.26秒で送信できてしまって現実とあわない)。 31.63 100000000 [bit] [sec] 0.26[sec] 1000000 1520 8[bit] ではいったい何が原因なのであろうか？それを 調べるためにさらに実験を行った。 Experiment 3 目的 割り込み処理・仮想化によるオーバーヘッド 以外の、ゲストEthernetドライバによるI/O命 令によるオーバーヘッドの詳細を調べる。 方法 VMとVMAppで使用された、ゲストEthernetド ライバによる（12個の）I/O命令の使用する時 間比率を時ベースのサンプリングにより計測。 Experiment 3 Experiment 3: distribution of time spent in the VMM &VMapp 考察 •VMAppを呼び出す時間 (world switch発生）は VMM時間の25％以上 •送受信ごとに呼び出す IRQの占める時間が大き い（IRQ呼び出しでは必ず world switchが起こり、処 理も複雑） (VMM-ホスト間)world switchとIRQ処理を減らせばよい！ Chapter 3.2 ネットワーク性能の最適化 ネットワーク仮想化における オーバーヘッド削減の手段 ホストマシンのI/Oシステムから離れずにい かに”World Switch”の回数を減らすか？ →以下の3つの方法がある。 1.VMMによるI/Oポートの処理 2.パケットの結合 3.IRQの通知 VMMによるI/Oポートの処理 world switchはホストの物理的(⇔仮想的)I/Oデバ イスにアクセスするときのみ必要 Lanceポートへの物理アクセスのうちパケット転送は 1/3、残りはLanceポートの状態修正で、VMM内で処 理できる（わざわざswitchする必要なし） →今まではLanceポートへのアクセス時は常に switchしていたが、パケット転送時のみswitch を行えばよい また、Lanceポートへの送信はLanceアドレスレジスタへのMOVEと同等という性質がある →送信命令の変わりに簡単なMOV命令を使えばよい →仮想化の減少、命令数の減少につながる →Lanceアクセスの場合も高速化 パケットの結合 LanceポートがVMMで一部処理されることか ら、次の割込みによるworld switchまで転送 延期可能して一緒に転送する。 ただし、I/O割込があまり起こっておらず、world switchが十分に高いレートで起こっていないと逆 に遅くなってしまう。 パケット送信によるswitchとIRQ処理によ るswitchをまとめることでswitchの回数が 減少 IRQの通知 パケットの送受信の通知を受け取るためのhOSのシ ステムコールを減らせないか？ →VMAppが初期化時にVMNetドライバとの共有メモリ を確立することを利用する。 すなわち、 VMAppがselect()を呼び出さず、共有メモリを 利用する(switchがなくなる）ようにVMNetを 拡張する。 注） select()はI/Oネットワーキングにおいて大きな負荷となる。 VMM最適化後の結果 Lanceアドレスレジスタへのアクセスが 8.1％から0.5％に減少している。 (Lance I/OをVMMで処理した成果） VMNetを通したパケット送信の時間は 変わっていない。→それ以外の時間が 短縮されている。 PercentTimeが減っているのに AverageTimeが長くなってる部分があ るのはなぜか?→一度にまとめて転送し ているため。 ほとんどのI/O関連のオーバーヘッドがなくなって、 Guest Idleの時間になっている 処理速度とパケットサイズの関係 nettestプログラムを用い て、 パケットサイズをさま ざまに変えたとき VMwareにおいて最適化 する前とした後で、native speedとの処理速度の比 較をする。 考察 733,350共に最適化により約2倍のスピード改善 •PC-350を最適化したものはPC-733のスピードにほぼ一致する。 （CPU制限されているから100Mbは出ていないが・・・） •PC-733を最適化したものはnative speedまでスピードが上昇する CPUの利用状況 それぞれの環境でCPUはどれくらいアイドルになっているのか？ TSCレジスタを使ってgOSがHLT命令を出したときから次のハード ウェア割り込みが起きるまでの時間（i.e. gOSがほかの演算を実 行できるまでのCPUサイクル。hOSが演算可能になるサイクルで はない）を計測した。（packet size=4KB ,CPU bound=64MB/s) 結果 ←71.5×30.4＝21.7 考察 最適化により、明らかにCPU占有率は低下した。しかし、 まだnativeなマシンのアイドル時間には程遠い。 Chapter 4 I/O以外における最適化 イントロダクション 前章において、仮想化においてI/O操作自体が原因となった オーバーヘッドについては削減することができた。 ⇒I/Oパフォーマンスを上げCPU使用率を減らすには？ ⇒5つの方法に注目する。 1. 2. 3. 4. 5. CPU（と割込みコントローラ）の仮想化によるオーバーヘッ ドの削減。 GuestOSの修正。 Guestのドライバの修正。 HostOSの修正。 HostOSの回避（VMMから直接ハードにアクセス）。 ここで４と5はVMの範疇ではないので避けるべき。 4.1 CPUの仮想化による オーバーヘッドの削減 前章の結果によれば、CPU の仮想化によるオーバー ヘッドはかなりの割合を占め ている。(右図矢印) （これを個別に詳しく論議す るにはVMwareの内部につ いて知っている必要がある ので議論できない。） 例えば、GuestOSのPICへのアクセス(interrupt controller)はVMM Time の2.5%を占めているが、この操作はIRQによるworld switchが原因であ り、 物理的なPICから独立した仮想PICを作ることにより回避できる。 ⇒オーバーヘッドを減らすことができる。 4.2 Guest OSの修正 以下の2つの方法が挙げられる。 仮想化すると効率の悪くなる（オーバーヘッド の原因となる）命令の使用を避ける。 既成のOS（Guest OS）の情報をVMMに提供 し、操作を代替となるより効率的な操作に置 換。 例.Linux kernelにおいて、アイドル移行時の ページテーブルスイッチを回避（→次ページ）。 4.2 Guest OSの修正 例.Linux kernelにおいて、アイドル移行時のページ テーブルスイッチを回避。 ページテーブルスイッチ ー CPUオーバヘッドの 8.5%（PC-733）。 Linux kernelにおいてアイドルタスクは、kernelの ページテーブルを伴ったkernel threadであり、その ページテーブルはユーザアプリケーションのページ テーブルのサブセット（一部）である。 →アイドルに移るときページテーブルを変える必要は ない。（具体的には最後のプロセスのページテーブ ルをそのまま使えばよい。） 4.3 Guestのドライバの最適化 NICを例として考える。 GuestのNICはホストの物理的NICに関係のない抽 象的なもの。 →仮想化に適した理想的なNICを実現することができ る。 例.vmxnetネットワークアダプタ(→次ページ）。 問題点：理想的なNICについて全てのGuest OSに合 うドライバの実現が必要。 →理想化による利益が大きい環境（サーバ環境な ど）には適している。 4.3 Guestのドライバの最適化 以下のような理想化が考えられる。 例1.Linux pcnet32 ドライバ パケット転送に12のI/O命令と１つのIRQが必要。 →転送時のOUT命令もしくは転送可能を知らせる IRQのいずれか1つのみで実現。 例２．Lanceコントローラのバッファ 柔軟だが複雑なバッファ。 →メモリ上の単純な送受信バッファとして実現。 以上の理想化を実現したものとしてVMwareの vmxnetネットワークアダプタがある。 4.4 Host OSの修正 Hostを修正することでオーバヘッドを減らすこ とができる場合がある。 例．ネットワークにおいて、 Linuxがソケット カーネルバッファ（sk_buff)を割り当てて扱う 方法を拡張（→次ページ） 。 問題点：OS venderの協力が必要。 4.4 Host OSの修正 例．ネットワークにおいて、 Linuxがソケットカーネル バッファ（sk_buff)を割り当てて扱う方法を拡張。 VMAppがVMNet driverを用いてパケットを送信す る時、VMNet driverはsk_buffをkmalloc()を用い て割り当て、VMAppからsk_buffにコピーして送信 する。 → このコピーがホストでの時間浪費の原因。 送信元（VMApp）のデータはVMの物理メモリ領域 に存在。 ⇒ 送信元のデータをVMNet driverがsk_buffのデー タとして割り当てれば、コピーを回避できる。 4.5 Host OSの回避 根本的なI/O制限はworld switchの存在。 →直接VMMがI/Oデバイスを制御すればよい。 問題点 1. I/Oデバイスの変更に対するドライバ変更な どのサポートの必要性。 2. 個々のVMとそのVMM 、多重送信を制御す るための新しいkernelの必要性。 → I/O performanceが重要な要求となる場合 に適している。（例.VMware ESX Server） Chapter 5 総論 VMwareのホスト化技術によって・・・ 1. 2. 3. ハード毎のドライバ作成の必要性の排除。 ポータビリティ性のある安定した仮想ハー ドウェアの実現(VMからの利点)。 ユーザ・ディベロッパ双方の労力の削減。 ここで、ホスト化により、 大量のI/Oに対するオーバヘッド という新たな問題が生じる。 ⇒この問題を解消するには？(次ページ) 大量のI/Oに対するホスト化によるオーバ ヘッドを減らすには？ NICの仮想化を例にとると・・・ ⇒World Switchの回数を減らせばよい！！ 以下のような方法を使った。 1. VMMによるI/Oポートの処理 2. パケットの結合 3. IRQの通知 その結果・・・ 低速マシンはTCP転送が倍速になった 高速マシンはCPU使用率が下がった ここで、（条件つきで)I/Oの修正以外の改善策もある。 →次ページ 大量のI/Oに対するホスト化によるオーバ ヘッドを減らすには？ （続き） 様々な条件が整えば以下のような改善策もある。 1. VMwareの内部について知ることにより →CPU仮想化によるオーバヘッドの削減。 2. （Guest) OSについて知ることにより →Guest OSの修正。 3. 仮想NICについて知ることにより →Guest ドライバの修正。 4. （Host) OSを改変することにより →Host OSの修正。 5. I/Oのみのホスト化からの独立により →Host OSの迂回。 結論 以上の最適化により、(現在のCPU速度、ネッ トワーク性能では)VMwareは従来のVirtual Machine技術の代替、あるいはそれ以上とし て十分に機能するものである事がわかる。 互換性とI/O性能はトレードオフの関係にあり、 これからはCPU速度とネットワーク性能に合 わせて、バランスをとる必要があるかもしれな い。 参考文献 AMD Lance Manual http://www.amd.pl/products/npd/techdocs/techdocs.html Intel Architecture Manual http://www.intel.co.jp/jp/developer/design/pentium/manuals/ VMware日本語ホームページ(体験版DL可) http://www.networld.co.jp/products/vmware/index.htm Linux全般 http://www.linux.or.jp/ VMwareの画面
© Copyright 2024 ExpyDoc
