Virtualizing I/O Devices on VMware Workstation’s VMM 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ワールドの切り替えドライバ） 具体的な意味 VMAPPってそんななの？

バーチャルマシンの歴史 バーチャルマシンは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ポートもしくは把握すべき状況を減らすことができる IA－３２を説明する

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.オーバーヘッド改善の余地の大きいデバイス） Ethernet Ethernetはバス型LANなのでケーブル数をあまり増やさず多くの端末を接続できる NIC

仮想NIC NICをエミュレートしたものが仮想NIC NICのエミュレーションは二種類ある ⇒いずれもVMNet Driverにより実現 hOSの物理NICと同じ物理ネットワークと接続 hOS上の仮想ネットワークと接続(今回は扱わない） 　⇒いずれもVMNet Driverにより実現 ゲストOSから見ると仮想NICは専用のMACアドレスを持ち、すべての機能を備えたPCIイーサネットコントローラである。

仮想NICの動作 パケット送信 パケット受信 表面上の動作は完全に「仮想NIC＝物理NIC」 仮想NICは自分固有のMACアドレス付のパケットを送信する パケット受信 VMNet Driverが仮想ネットワークHUBとブリッジした物理NICを無差別モードで動作させ、LANを監視する 自分のMACアドレス宛パケットがあったら受信 仮想NIC自体はVMMとVMAppのコードの組み合わせによって実装される 仮想NICはLance Am79C970A（PCnet PCI II Single-Chip Full-Duplex Ethernet Controller for PCI Local Bus）をもとにしているが、特定のネットワーク速度に制限されない promiscuous 表面上の動作は完全に「仮想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の独占が起きている！！ VMがハードに直接アクセスするときに必ず発生するVMMとhOS間のworld switch I/O割込処理にVMM/gOS/hOS 3つのI/O割込が必要 gOSのパケット転送は・・・ gOSのドライバとhOSのドライバ双方を伴う gOSの物理メモリからhOSのカーネルバッファに余計なコピーが必要 OVERHEADS ⇒ World Switchの回数を少なくする最適化をすると・・・ 低速マシンはTCP転送を倍速にできた 高速マシンはCPU使用率を下げることができた ⇒

Chapter 3.1 パケット転送に関する実験

3.1 実験環境 ２台のPCの性能 PC-350 For VM（VMware2.0) PC-733 For VM （VMware2.0) 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 ⇒ ⇒ どこでCPU時間を消費しているのかを次の実験で調べる 前述の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秒で送信できてしまって現実とあわない)。 11個の命令って何だ？ A series of 11 other IN/OUT instructions. ではいったい何が原因なのであろうか？それを調べるためにさらに実験を行った。

Experiment 3 目的 　割り込み処理・仮想化によるオーバーヘッド以外の、ゲストEthernetドライバによるI/O命令によるオーバーヘッドの詳細を調べる。 方法 　 VMとVMAppで使用された、ゲストEthernetドライバによる（12個の）I/O命令の使用する時間比率を時ベースのサンプリングにより計測。

Experiment 3 考察 (VMM-ホスト間)world switchとIRQ処理を減らせばよい！ 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つの方法がある。 VMMによるI/Oポートの処理 パケットの結合 IRQの通知

VMMによるI/Oポートの処理 world switchはホストの物理的(⇔仮想的)I/Oデバイスにアクセスするときのみ必要 Lanceポートへの物理アクセスのうちパケット転送は1/3、残りはLanceポートの状態修正で、VMM内で処理できる（わざわざswitchする必要なし） →今まではLanceポートへのアクセス時は常にswitchしていたが、パケット転送時のみswitchを行えばよい また、Lanceポートへの送信はLanceアドレスレジスタへのMOVEと同等という性質がある →送信命令の変わりに簡単なMOV命令を使えばよい →仮想化の減少、命令数の減少につながる →Lanceアクセスの場合も高速化

パケットの結合 パケット送信によるswitchとIRQ処理によるswitchをまとめることでswitchの回数が減少 LanceポートがVMMで一部処理されることから、次の割込みによるworld switchまで転送延期可能して一緒に転送する。 ただし、I/O割込があまり起こっておらず、world switchが十分に高いレートで起こっていないと逆に遅くなってしまう。 パケットをリングバッファに送る パケット送信によるswitchとIRQ処理によるswitchをまとめることでswitchの回数が減少

IRQの通知 パケットの送受信の通知を受け取るためのhOSのシステムコールを減らせないか？ すなわち、 →VMAppが初期化時にVMNetドライバとの共有メモリを確立することを利用する。 すなわち、 　VMAppがselect()を呼び出さず、共有メモリを利用する(switchがなくなる）ようにVMNetを拡張する。 注）　select()はI/Oネットワーキングにおいて大きな負荷となる。

VMM最適化後の結果 ほとんどのI/O関連のオーバーヘッドがなくなって、Guest Idleの時間になっている Lanceアドレスレジスタへのアクセスが8.1％から0.5％に減少している。(Lance I/OをVMMで処理した成果） VMNetを通したパケット送信の時間は変わっていない。→それ以外の時間が短縮されている。 PercentTimeが減っているのにAverageTimeが長くなってる部分があるのはなぜか?→一度にまとめて転送しているため。 ほとんどのI/O関連のオーバーヘッドがなくなって、Guest Idleの時間になっている

処理速度とパケットサイズの関係 考察 733,350共に最適化により約2倍のスピード改善 nettestプログラムを用いて、 パケットサイズをさまざまに変えたときVMwareにおいて最適化する前とした後で、native speedとの処理速度の比較をする。 考察 733,350共に最適化により約2倍のスピード改善 PC-350を最適化したものはPC-733のスピードにほぼ一致する。（CPU制限されているから100Mbは出ていないが・・・） PC-733を最適化したものはnative speedまでスピードが上昇する

それぞれの環境で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使用率を減らすには？ オーバーヘッドについては削減することができた。 ⇒I/Oパフォーマンスを上げCPU使用率を減らすには？ ⇒5つの方法に注目する。 CPU（と割込みコントローラ）の仮想化によるオーバーヘッドの削減。 GuestOSの修正。 Guestのドライバの修正。 HostOSの修正。 HostOSの回避（VMMから直接ハードにアクセス）。 ここで４と5はVMの範疇ではないので避けるべき。

4.1 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であり、そのページテーブルはユーザアプリケーションのページテーブルのサブセット（一部）である。 →アイドルに移るときページテーブルを変える必要はない。（具体的には最後のプロセスのページテーブルをそのまま使えばよい。） Kernel thread - ユーザプログラム，あるいはkernelの処理を複数に分割して行なえる

4.3 Guestのドライバの最適化 NICを例として考える。 Guestの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の修正 問題点：OS venderの協力が必要。 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デバイスを制御すればよい。 問題点 個々のVMとそのVMM 、多重送信を制御するための新しいkernelの必要性。 →　I/O　performanceが重要な要求となる場合に適している。（例.VMware ESX Server） 「VMware ESX Server」 　VMwareのサーバ向け仮想化ソフトウェア

Chapter 5 総論

VMwareのホスト化技術によって・・・ ハード毎のドライバ作成の必要性の排除。 ポータビリティ性のある安定した仮想ハードウェアの実現(VMからの利点)。 ユーザ・ディベロッパ双方の労力の削減。 ここで、ホスト化により、 大量のI/Oに対するオーバヘッド という新たな問題が生じる。 ⇒この問題を解消するには？(次ページ) VMware 仮想プラットフォームは、標準のオペレーティングシステムによって提供されていない追加の機能を用意している。たとえば、VMware 仮想プラットフォームは、仮想マシンをカプセル化し、異なった物理的マシン上に自由に移動させることができる。VMware 仮想プラットフォームは、それぞれの仮想マシンに故障の独立性と封じ込め機能を提供。このことが意味するのは、ある一つの VMware 仮想マシンの中でアプリケーションがクラッシュしたりデータが破損した場合でも、仮想マシンの外のデータやアプリケーションには影響を与えないということ

大量のI/Oに対するホスト化によるオーバヘッドを減らすには？ NICの仮想化を例にとると・・・ ⇒World Switchの回数を減らせばよい！！ 以下のような方法を使った。 VMMによるI/Oポートの処理 パケットの結合 IRQの通知 その結果・・・ 低速マシンはTCP転送が倍速になった 高速マシンはCPU使用率が下がった ここで、（条件つきで)I/Oの修正以外の改善策もある。 →次ページ VMware 仮想プラットフォームは、標準のオペレーティングシステムによって提供されていない追加の機能を用意している。たとえば、VMware 仮想プラットフォームは、仮想マシンをカプセル化し、異なった物理的マシン上に自由に移動させることができる。VMware 仮想プラットフォームは、それぞれの仮想マシンに故障の独立性と封じ込め機能を提供。このことが意味するのは、ある一つの VMware 仮想マシンの中でアプリケーションがクラッシュしたりデータが破損した場合でも、仮想マシンの外のデータやアプリケーションには影響を与えないということ

大量のI/Oに対するホスト化によるオーバヘッドを減らすには？ （続き） 様々な条件が整えば以下のような改善策もある。 VMwareの内部について知ることにより →CPU仮想化によるオーバヘッドの削減。 （Guest) OSについて知ることにより →Guest OSの修正。 仮想NICについて知ることにより →Guest ドライバの修正。 （Host) OSを改変することにより →Host OSの修正。 I/Oのみのホスト化からの独立により →Host OSの迂回。

結論 以上の最適化により、(現在のCPU速度、ネットワーク性能では)VMwareは従来のVirtual Machine技術の代替、あるいはそれ以上として十分に機能するものである事がわかる。 互換性とI/O性能はトレードオフの関係にあり、 これからはCPU速度とネットワーク性能に合わせて、バランスをとる必要があるかもしれない。

参考文献 AMD Lance Manual Intel Architecture 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/

Happy Birthday, Suekane!! VMwareの画面 Happy Birthday, Suekane!! 2002.01.21 Fin.