仮想 Linux

仮想化の方法、アーキテクチャー、そして実装の概要

仮想化の意味は、人によってさまざまです。目下、仮想化で大きな焦点となっているのは、サーバーの仮想化、つまり複数の独立したオペレーティング・システムを単一のホスト・コンピューターでホストすることです。この記事では、仮想化の背後にある意図を説明した後、仮想化を実装する方法をいくつか取り上げます。さらに、Linux でのオペレーティング・システムの仮想化など、世間に出回っている仮想化技術についても目を向けてみます。

M. Tim Jones (mtj@mtjones.com), Consultant Engineer, Emulex

M. Tim JonesM. Tim Jones は、埋め込みソフトウェアのエンジニアであり、GNU/Linux Application Programming, AI Application Programming と BSD Sockets Programming from a Multilanguage Perspective の著者でもあります。エンジニアとして経歴は幅広く、静止衛星用のカーネル開発から埋め込みシステム・アーキテクチャー、そしてネットワーク・プロトコル開発まで経験しています。現在は Emulex Corp. のシニア主席エンジニアです。


developerWorks 貢献著者レベル

2006年 12月 29日

「仮想化する」とは、ある形を別の形のように見えるようにすることです。コンピューターの仮想化とは、1 台のコンピューターを複数に見えるようにすること、あるいはまったく別のコンピューターに見えるようにすることです。

仮想化の意味が、複数のコンピューターを単一のコンピューターに見えるようにすることである場合もあります。これは一般的にはサーバー集約、もしくはグリッド・コンピューティングと呼ばれます。

それでは、まず仮想化の起源から話を始めましょう。

仮想化の歴史的考察

仮想化は目新しい話題ではなく、実は 40 年以上の歴史があります。仮想化の最古の使用例には、IBM ® 7044、マサチューセッツ工科大学 (MIT) が IBM 704 で開発した Compatible Time Sharing System (CTSS)、マンチェスター大学の Atlas プロジェクト (世界初のスーパーコンピューターの 1 つ) などがあり、デマンド・ページングおよびスーパーバイザー・コールの先駆けとなりました。

ハードウェアの仮想化

IBM が仮想化の重要性を認識したのは、1960 年代の System/360 ™ Model 67 メインフレームの開発がきっかけです。Model 67 は、Virtual Machine Monitor (VMM) を介してすべてのハードウェア・インターフェースを仮想化しました。初期の頃のコンピューティングでは、オペレーティング・システムはスーパーバイザーと呼ばれていましたが、オペレーティング・システムを別のオペレーティング・システムで実行する能力が備わったことから「ハイパーバイザー」という用語が生まれました (1970 年代に作り出された用語)。

VMM は基礎ハードウェアで直接実行されて、複数の仮想マシン (VM) を許可します。これで、各 VM でそれぞれ独自の専用オペレーティング・システムのインスタンスを実行することが可能になります。つまり、当時の VM はConversational Monitor System (CMS) でした。VM の進化はその後も続き、今日では System z9 ™ メインフレームでも活用されています。このメインフレームは、System/360 系列にまでさかのぼる後方互換性を提供します。

プロセッサーの仮想化

初期の仮想化の使用例にはその他、シミュレートされたプロセッサーの場合の P コード (擬似コード) マシンもあります。P コードは、実際のハードウェアではなく仮想マシンで実行される機械語です。P コードを有名にしたのは、1970 年代初期にカリフォルニア州立大学サンディエゴ校 (UCSD) のパスカル・システムで、このシステムはパスカル・プログラムを P コードにコンパイルしてから P コード仮想マシンで実行します。その結果、P コード・プログラムの移植性が大幅に向上し、P コード仮想マシンが使用できるところであればどこででも P コード・プログラムを実行できるようになりました。

命令セットの仮想化

Java 仮想マシン (JVM)

Java ™ 言語では JVM に P コード・モデルを採用しました。そのため、JVM を移植するだけで、Java プログラムを数え切れないほどのアーキテクチャーに普及させることができました。

これと同じコンセプトは、1960 年代にも用いられています。それが、C 言語の祖先である Basic Combined Programming Language (BCPL) です。この場合の使用方法では、コンパイラーによって BCPL コードが O コードと呼ばれる中間マシン・コードにコンパイルされ、さらに2 次ステップとして O コードがターゲット・マシン固有の言語にコンパイルされます。現代のコンパイラーはこのモデルを使用して、新規ターゲット・アーキテクチャーにコンパイラーを移植する際の柔軟性を提供しています (フロントエンドとバックエンドを中間言語によって分離)。

仮想化の最近の側面として、命令セットの仮想化、あるいはバイナリー変換と呼ばれるものがあります。このモデルでは、(通常は動的に) 仮想命令セットが基礎ハードウェアの物理命令セットに変換されます。コードが実行される段階になると、コード・セグメントの変換が行われます。分岐が発生した場合には、該当する新しいコード・セットが取り入れられて変換されます。これにより、仮想化はキャッシュ操作に非常によく似たものになります。つまり、命令のブロックがメモリーからローカル側の高速キャッシュメモリーに移されて実行されるというわけです。

このモデルが使用された最近の例には、Transmeta が設計した Crusoe 中央演算処理装置 (CPU) があります。このアーキテクチャーでは、codeMorphing という商標名でバイナリー変換が実装されています。同じような例として、完全仮想化ソリューションで使用されているランタイム・コード・スキャンもあります。ランタイム・コード・スキャンは特定プロセッサー命令セットでの問題を対処するために、特権命令を検索してリダイレクトします。


仮想化のタイプ

仮想化とゲーム

仮想化を話題にした記事では、Multiple-Arcade Machine Emulator (MAME) に触れないわけにはいきません。MAME はその名前が示すように、かつてゲーム・センターにあったゲームの完全なマシン・エミュレーターです。ゲームで使用されるプロセッサーを仮想化しているだけでなく、サウンドおよびグラフィックス・ハードウェア、そしてコントロールを含め、マシンがまるごと仮想化されています。MAME はアプリケーションとして素晴らしいだけでなく、ソースの詳細を調べて何がどこまで達成されたかを理解するのにも興味深い対象です。

仮想化に関して言うと、その方法は 1 つだけには限られません。実際には、抽象化レベルは違っていても結果は同じという複数の方法があります。このセクションでは、Linux で最も一般的な 3 つの仮想化方法を紹介し、それぞれの相対的な長所と弱点を明らかにします。この業界では、同じ仮想化方法を表すのに異なる用語を使うことがあります。ここでは一貫性を保つために最も一般的な用語を使用し、その他の用語は参考として記載しています。

ハードウェア・エミュレーション

最も複雑な仮想化を実現するのは、ほほ間違いなくハードウェア・エミュレーションです。この方法では、対象のハードウェアをエミュレートするため、ホスト・システムにハードウェアの VM が作成されます (図 1 を参照)。

図 1. VM によって必須ハードウェアをシミュレートするハードウェア・エミュレーション
図 1. VM によって必須ハードウェアをシミュレートするハードウェア・エミュレーション

エミュレーションと開発

ハードウェア・エミュレーションのなかで最も興味深い使用例は、ファームウェアとハードウェアの共同開発です。ファームウェア開発者は実際のハードウェアが使用可能になるまで待たずに、ターゲット・ハードウェアの VM を使用して実際のコードのさまざまな側面をシミュレーションで検証できます。

おそらく想像できると思いますが、ハードウェア・エミュレーションでの第 1 の問題は、処理速度が耐え難いほどに遅くなることがあるという点です。基礎ハードウェアですべての命令をシミュレートする必要があるため、100 倍の減速になることも珍しくありません。サイクル精度、シミュレーション対象の CPU パイプライン、そしてキャッシュ動作を含めた精度の高いエミュレーションの場合は、実際の処理速度に比べて 1000 倍近く遅くなることもあります。

ただし、ハードウェア・エミュレーションには利点があることも確かです。ハードウェア・エミュレーションでは例えば、ARM プロセッサー・ホスト上の PowerPC ® を対象とした修正なしのオペレーティング・システムを実行できます。さらに複数の仮想マシンを実行して、仮想マシンごとに異なるプロセッサーをシミュレートすることもできます。

完全仮想化

完全仮想化 (ネイティブ仮想化としても知られています) も興味深い仮想化方法です。このモデルでは、ゲスト・オペレーティング・システムとネイティブ・ハードウェアとを仲介する仮想マシンを使用します (図 2 を参照)。ここで鍵となるのは「仲介する」という言葉です。それは VMM はゲスト・オペレーティング・システムとネイティブ・ハードウェアとを仲介するからです。つまり、基礎ハードウェアは、オペレーティング・システムが所有するのではなく、ハイパーバイザーを介してオペレーティング・システムに共有されることから、保護されている命令はハイパーバイザー内で捕捉して処理する必要があります。

図 2. ハイパーバイザーを使用して基礎ハードウェアを共有する完全仮想化
図 2. ハイパーバイザーを使用して基礎ハードウェアを共有する完全仮想化

旧型ハードウェアでのハイパーバイザー

x86 などの一部の旧型ハードウェアは、完全仮想化の方法で問題になります。例えば、VMM が、処理しなければならない特定の機密命令を捕捉しないなどの問題です。このような問題を処理するには、ハイパーバイザーが動的に特権モード・コードをスキャンして捕捉する必要があります。

完全仮想化はハードウェア・エミュレーションより高速ですが、スーパーバイザーが仲介するためパフォーマンスはネイティブ・ハードウェアより劣ります。完全仮想化の最大の利点は、オペレーティング・システムを修正せずに実行できるという点です。唯一の制約として、オペレーティング・システムは基礎ハードウェア (PowerPC など) をサポートする必要があります。

疑似仮想化

疑似仮想化も人気の高い手法で、完全仮想化といくつかの類似点があります。疑似仮想化では、基礎ハードウェアへの共有アクセスにはハイパーバイザーを使用しますが、仮想化対応コードはオペレーティング・システム自体に統合されます (図 3 を参照)。オペレーティング・システム自体を仮想化プロセスに組み込むという手法により、再コンパイルや捕捉の必要がなくなります。

図 3. ゲスト・オペレーティング・システムとプロセスを共有する疑似仮想化
図 3. ゲスト・オペレーティング・システムとプロセスを共有する疑似仮想化

前述したように、疑似仮想化ではゲスト・オペレーティング・システムをハイパーバーザーとして変更しなければならないというところが欠点ですが、疑似仮想化は仮想化していないシステムに匹敵するほどのパフォーマンスを提供します。また、完全仮想化と同じく、複数の異なるオペレーティング・システムを同時にサポートできます。

オペレーティング・システム・レベルの仮想化

最後に取り上げる手法は、オペレーティング・システム・レベルの仮想化で、上記で紹介したものとは異なる手法が使用されます。この手法では、オペレーティング・システム自体を含めてサーバーを仮想化します。この方法は単一のオペレーティング・システムをサポートし、別個のサーバーをそれぞれ分離させるだけです (図 4 を参照)。

図 4. サーバーを分離するオペレーティング・システム・レベルの仮想化
図 4. サーバーを分離するオペレーティング・システム・レベルの仮想化

オペレーティング・システム・レベルの仮想化では、オペレーティング・システム・カーネルを変更する必要がありますが、本来のパフォーマンスが得られるという利点があります。


仮想化が重要である理由

Linux に現在使用できる仮想化オプションを検討する前に、仮想化の利点について検討してみましょう。

ビジネスの観点からすると仮想化を使用する理由はたくさんありますが、そのほとんどの理由の根拠となっているのはサーバーの統合です。簡単に言うと、使用中の多数のシステムを単一のサーバー上で仮想化することができればサーバーの数が減るため、電力、スペース、冷却、そして管理を大幅に削減できます。サーバー使用率を判別するのは難しい場合があるので、仮想化技術ではライブ・マイグレーションと呼ばれる機能をサポートします。ライブ・マイグレーションにより、オペレーティング・システムとそのアプリケーションを新しいサーバーに移行して、使用可能なハードウェアに負荷を分散できます。

仮想化は開発者にとっても同じく重要です。Linux カーネルは単一のアドレス空間を占有しますが、これはつまり、カーネルやいずれかのドライバーが故障するとオペレーティング・システム全体がクラッシュすることを意味します。仮想化すると複数のオペレーティング・システムを実行できるため、そのうちの 1 つがバグによってクラッシュしても、ハイパーバイザーや他のオペレーティング・システムは動作し続けます。すなわち、ユーザー空間のアプリケーションをデバッグするのと同じようにカーネルをデバッグできるようになります。


Linux 関連の仮想化プロジェクト

表 1 に、Linux に使用できる仮想化プロジェクトを示します。この表は主に、オープン・ソースのソリューションに重点を絞っています。

表 1. Linux 関連の仮想化プロジェクト
プロジェクトタイプライセンス
BochsエミュレーションLGPL
QEMUエミュレーションLGPL/GPL
VMware完全仮想化専用
z/VM完全仮想化専用
Xen疑似仮想化GPL
UML疑似仮想化GPL
Linux-VServer オペレーティング・システム・レベルの仮想化GPL
OpenVZオペレーティング・システム・レベルの仮想化GPL

上記以外のソリューションについては、 「参考文献」 セクションを参照してください。

Bochs (エミュレーション)

ライブラリー・レベルの仮想化

この記事では説明していませんが、仮想化には、ライブラリーを介してオペレーティング・システムを部分的にエミュレートするライブラリー・レベルの仮想化という方法もあります。その例としては、Wine (Linux に対応した部分的 Win32 API) および LxRun (Solaris に対応した部分的 Linux API) が挙げられます。

Bochs は移植性のある x86 コンピューター・シミュレーターで、x86、PowerPC、Alpha、SPARC、MIPS などの各種プラットフォームで実行できます。Bochs を興味深いものにしている点は、プロセッサーをシミュレートするだけでなく、キーボード、マウス、ビデオ・グラフィックス・ハードウェア、ネットワーク・インターフェース・カード (NIC) デバイスなどの周辺機器を含めたコンピューター全体をシミュレートすることです。

Bochs は旧型の Intel ® 386 として構成することも、後継プロセッサーである 486、Pentium、Pentium Pro、あるいは 64 ビット拡張を実装したプロセッサーとして構成することもできます。さらに、MMX や 3DNow のようなオプションのグラフィックス命令もエミュレートします。

Bochs エミュレーターを使用すれば、あらゆる Linux ディストリビューション、そして Microsoft ® Windows ® 95/98/NT/2000 (および各種アプリケーション)、さらには Berkeley Software Distribution (BSD) オペレーティング・システム (FreeBSD、OpenBSD など) を Linux 上で実行できます。

QEMU (エミュレーション)

QEMU も Bochs と同様にエミュレーターですが、特筆すべき違いがあります。それは、QEMU は 2 つの動作モードをサポートすることです。1 つは Full System Emulation モードで、プロセッサーと周辺機器を併せたパーソナル・コンピューター (PC) 全体をエミュレートする点では Bochs と似ています。このモードは動的変換を使用し、それ相応の速度で多数のプロセッサー・アーキテクチャー (x86、x86_64、ARM、SPARC、PowerPC、MIPS など) をエミュレートします。このモードを使用すると、Linux、Solaris、FreeBSD 上で Windows オペレーティング・システム (XP を含む) および Linux をエミュレートできます。サポートされるオペレーティング・システムの組み合わせは、これ以外にも多数あります (詳細は、 「参考文献」 を参照)。

QEMU がサポートするもう 1 つのモードは、User Mode Emulation です。Linux でのみホスト可能なこのモードでは、異なるアーキテクチャーのバイナリーを起動できます。そのため、例えば MIPS アーキテクチャーを対象にコンパイルされたバイナリーを x86 で稼働中の Linux で実行することも可能になります。このモードでサポートされるアーキテクチャーはこの他、ARM、SPARC、および PowerPC がありますが、それ以外にも開発が進んでいるところです。

VMware (完全仮想化)

VMware は市販の完全仮想化ソリューションです。ハイパーバイザーはゲスト・オペレーティング・システムとネイティブ・ハードウェアの間に抽象化レイヤーとして位置します。この抽象化レイヤーにより、あらゆるオペレーティング・システムが他のゲスト・オペレーティング・システムを意識することなくハードウェアで稼動できます。

VMware はさらに、使用可能な入出力ハードウェアを仮想化し、ハイパフォーマンス・デバイス用のドライバーをハイパーバイザーに配置します。

仮想化された環境全体が 1 つのファイルとして保持されるため、完全なシステム (ゲスト・オペレーティング・システム、VM、仮想ハードウェアを含む) を新しいホストに簡単かつ素早く移行させてロード・バランスを保つことができます。

z/VM (完全仮想化)

IBM System z ™ は新しい商標名ですが、実際には 1960 年代に端を発する長年の歴史があります。1965 年に、System/360 は仮想マシンを使って仮想化をサポートしましたが、面白いことに、System z はかつての System/360 系列との後方互換性を維持しています。

z/VM ® は、System z を対象としたオペレーティング・システム・ハイパーバイザーです。その中核は Control Program (CP) で、この CP が Linux を含めたゲスト・オペレーティング・システムの物理リソースを仮想化します (図 5 を参照)。これにより、多数のゲスト・オペレーティング・システムに対して複数のプロセッサーとその他のリソースを仮想化することが可能になります。

図 5. z/VM によるオペレーティング・システム・レベルの仮想化
図 5. z/VM によるオペレーティング・システム・レベルの仮想化

z/VM では、相互に通信する必要があるゲスト・オペレーティング・システムのために、実質的にゲスト・ローカル・エリア・ネットワーク (LAN) をエミュレートすることもできます。これは完全にハイパーバイザー内でエミュレートされるため、非常にセキュアです。

Xen (疑似仮想化)

Xen は、XenSource による オペレーティング・システム・レベルの疑似仮想化を目的とした無料のオープン・ソース・ソリューションです。前にも説明したように、疑似仮想化ではハイバーバイザーとオペレーティング・システムが連携して仮想化を行うため、オペレーティング・システムの変更が必要となりますが、本来のレベルに近いパフォーマンスが得られます。

Xen では連携 (ゲスト・オペレーティング・システムに対する変更) が必要となるため、Xen で仮想化できるのは、パッチが提供されるオペレーティング・システムのみです。それ自体がオープン・ソースである Linux の観点からすると、完全仮想化よりも高いパフォーマンスとなるため、これは妥当な譲歩です。一方、広範なサポート (オープン・ソース以外のオペレーティング・システムのサポートなど) という点では、明らかにこの制約が不利となります。

Xen では Windows をゲストとして実行できますが、Intel Vanderpool または AMD Pacifica を実行するシステムの場合に限られます。Xen をサポートするオペレーティング・システムとしては他に、Minix、Plan 9、NetBSD、FreeBSD、および OpenSolaris があります。

User-mode Linux (疑似仮想化)

User-mode Linux (UML) では、Linux オペレーティング・システムがユーザー空間にある別の Linux オペレーティング・システムを実行できます。それぞれのゲスト Linux オペレーティング・システムは、ホスト Linux オペレーティング・システムのプロセス内に存在します (図 6 を参照)。そのため、(独自の関連ユーザー空間を持つ) 複数の Linux カーネルを単一の Linux カーネルのコンテキスト内で実行できます。

図 6. User-mode Linux をホストする Linux
図 6. User-mode Linux をホストする Linux

2.6 Linux カーネルでは UML はメイン・カーネル・ツリー内にありますが、これを使用するには、有効に設定してから再コンパイルする必要があります。このような変更がもたらすのは、何よりもデバイスの仮想化です。これにより、複数のゲスト・オペレーティング・システムが、ブロック・デバイス (フロッピー、CD-ROM、ファイル・システムなど)、コンソール、NIC デバイス、サウンド・ハードウェアなどの使用可能な物理デバイスを共有できるようになります。

ゲスト・カーネルはアプリケーション空間内で実行されるため、この用途に合わせてコンパイルしなければならないことに注意してください (ただし、カーネルのバージョンが異なっていても構いません)。このコンパイルによって、カーネルはホスト・カーネル (ハードウェアに常駐) と呼ばれるものと、ゲスト・カーネル (ホスト・カーネルのユーザー空間内で動作) の 2 種類になります。これらのカーネルをネストして、あるゲスト・カーネルを、ホスト・カーネルで実行中の別のゲスト・カーネルで実行することもできます。

Linux-VServer (オペレーティング・システム・レベルの仮想化)

Linux-VServer は、システム・レベルの仮想化を対象としたソリューションです。Linux-VServer では Linux カーネルを仮想化して、Virtual Private Servers (VPS) としても知られる複数のユーザー空間環境が互いに意識せずに独立して実行できるようにします。Linux-VServer はユーザー空間を分離させるため、Linux カーネルに対して一連の変更を行います。

個別のユーザー空間を互いに分離させるには、まずコンテキストのコンセプトから取り掛かります。コンテキストとは特定 VPS のプロセス用コンテナーで、ps などのツールが VPS のプロセスのみを認識するようにするためのものです。初期ブートの場合は、カーネルがデフォルト・コンテキストを定義します。管理のための傍観者用コンテキストも存在します (すべての実行中プロセスを表示するため)。ご想像のとおり、このカーネルと内部データ構造を変更して、この仮想化方法をサポートするようにします。

さらに、Linux-VServer は chroot 形式で各 VPS のルート・ディレクトリーを分離します。chroot では新しいルート・ディレクトリーを指定できますが、VPS が分離したルート・ディレクトリーから親にエスケープしないようにするための追加機能 (Chroot-Barrier という機能) が必要です。分離したルート・ディレクトリーを指定すると、それぞれの VPS は独自のユーザー・リストとルート・パスワードを持つようになります。

Linux-VServer は 2.4 および 2.6 Linux カーネルの両方でサポートされており、x86、x86-64、SPARC、MIPS、ARM、PowerPC をはじめとする多数のプラットフォームで動作します。

OpenVZ (オペレーティング・システム・レベルの仮想化)

OpenVZ もまた、Linux-VServer と同様にオペレーティング・システム・レベルの仮想化ソリューションですが、いくつか興味深い違いがあります。OpenVZ は分離されたユーザー空間 (VPS) をサポートする仮想化対応 (変更された) カーネルで、一連の管理用ユーザー・ツールがあります。例えば以下のように、コマンド・ラインから新規 VPS を簡単に作成できます。

リスト 1. コマンド・ラインからの VPS の作成
$ vzctl create 42 --ostemplate fedora-core-4
Creating VPS private area
VPS private area was created
$ vzctl start 42
Starting VPS ...
VPS is mounted

また、vzlist コマンドを使って現在作成済みの VPS をリストすることもできます。このコマンドは、標準の Linux ps コマンドと同じように動作します。

プロセスをスケジューリングするため、OpenVZ には 2 レベルの CPU スケジューラーが組み込まれています。スケジューラーはまず、CPU を取得する VPS を決定します。それが決定された後、第 2 レベルのスケジューラーが標準 Linux 優先順位に基づいて実行するプロセスを選択します。

OpenVZ には beancounter と呼ばれる機能も組み込まれています。beancounter は、特定 VPS のリソース配分を定義する多数のパラメーターで構成されます。使用可能なメモリーの量、使用可能なプロセス間通信 (IPC) オブジェクトの数などを定義して、VPS に対する制御レベルを指定します。

OpenVZ に固有の特徴は、チェックポイントを指定して VPS を物理サーバー間で移行できることです。チェックポイントの指定とは、実行中の VPS の状態を凍結してファイルに保存することを意味します。このファイルを新規サーバーに移行してリストアすると、VPS がオンライン状態に戻ります。

OpenVZ は、x86、x86-64、PowerPC をはじめとする多数のハードウェア・アーキテクチャーをサポートします。


完全仮想化と疑似仮想化のハードウェア・サポート

IA-32 (x86) アーキテクチャーを仮想化するとなると、問題が持ち上がることを思い出してください。特定の特権モードの命令は捕捉を行わず、モードに応じたさまざまな結果を返す場合があるからです。その一例として、x86 STR 命令はセキュリティー状態を取得しますが、返される値は該当する要求側の特権レベルに基づきます。これが、異なるオペレーティング・システムを異なるレベルで仮想化するときに問題になります。例えば x86 がサポートする 4 つの保護リングの場合、レベル 0 (最高位の特権) は通常オペレーティング・システムを実行し、レベル 1 と 2 はオペレーティング・システム・サービスをサポートし、そしてレベル 3 (最下位レベル) はアプリケーションをサポートします。この欠点 (その他の欠点も) を認識したハードウェア・ベンダーは、仮想化をサポートして促進する新しい設計を創り出しています。

Intel が現在作成中の新しい仮想化技術では、x86 (VT-x) および Itanium ® (VT-i) アーキテクチャーの両方に対応したハイパーバイザーがサポートされる予定です。VT-x は、VMM (ルート) およびゲスト・オペレーティング・システム (ルート以外) のそれぞれを対象とした 2 つの新しい操作形式をサポートします。ルート形式には完全な特権が与えられる一方、ルート以外の形式には特権が与えられません (リング 0 の場合も例外ではありません)。このアーキテクチャーはまた、VM (ゲスト・オペレーティング・システム) を終了させて VMM にプロセッサー停止状態を保存させる命令を定義する際の柔軟性をサポートします。その他の追加機能については、 「参考文献」 セクションを参照してください。

AMD でも、Pacifica という名前のハードウェア支援による仮想化技術を作成しているところです。Pacifica でとりわけ特徴となっているのは、特殊な命令の実行によって保存されるゲスト・オペレーティング・システム用の制御ブロックを維持することです。この VMRUN 命令により、仮想マシン (および関連ゲスト・オペレーティング・システム) は VMM が制御を取り戻すまで (これも設定可能です) 実行することができます。設定の柔軟性により、VMM ではゲストごとに特権をカスタマイズできます。また、Pacifica ではホストとゲストのメモリー管理ユニット (MMU) により、アドレス変換も改良されています。

上記の新しい技術は、このセクションで説明した Xen、VMware、User-mode Linux をはじめとしたさまざまな仮想化手法で使用できます。


Linux の Kernel Virtual Machine (KVM)

Linux からの最新ニュースは、Linux カーネル (2.6.20) に KVM を統合したことです。KVM はカーネル・モジュールを使用して Linux カーネルをハイパーバイザーに変換するという点で、他に類を見ない完全仮想化ソリューションとなっています。このモジュールにより、他のゲスト・オペレーティング・システムがホスト Linux カーネルのユーザー空間で動作できるようになります (図 7 を参照)。カーネル内の KVM モジュールは /dev/kvm キャラクター・デバイスを介して仮想化されたハードウェアを公開します。ゲスト・オペレーティング・システムは、PC ハードウェア・エミュレーション用に変更された QEMU プロセスを使用して KVM とインターフェースをとります。

図 7. Kernel Virtual Machine (KVM) による仮想化
図 7. Kernel Virtual Machine (KVM) による仮想化

KVM モジュールはカーネルに新しい実行モードを導入します。vanilla カーネルがカーネル・モードとユーザー・モードをサポートする場合、KVM はゲスト・モードを導入します。通常のユーザー・モードがゲストの入出力をサポートする一方、ゲスト・モードは入出力以外のすべてのゲスト・コードを実行するために使用されます。

KVM の導入は、Linux にとって興味深い展開となっています。なぜなら、Linux のメインライン・カーネルの一部として組み込まれた初めての仮想化技術だからです。KVM は 2.6.20 ツリーにありますが、2.6.19 カーネル用のカーネル・モジュールとしても使用できます。仮想化をサポートするハードウェアで実行する場合は、Linux (32 および 64 ビット) と Windows (32 ビット) のゲストがサポートされます。KVM の詳細は、 「参考文献」 セクションを参照してください。


まとめ

「新たな」という言葉の意味に 40 年以上存在するものを含められるとしたら、仮想化は新たな一大事です。仮想化は歴史的にさまざまなコンテキストで使用されてきましたが、現在はサーバーとオペレーティング・システムの仮想化に第 1 の焦点が置かれています。Linux と同様、仮想化にはパフォーマンス、移植性、そして柔軟性に多くのオプションがあります。つまり、自分と自分のアプリケーションに最適な手法を選べるということです。

参考文献

学ぶために

製品や技術を入手するために

  • BochsQEMU は、Windows や Linux などのオペレーティング・システムを Linux オペレーティング・システムのユーザー・スペースで動作できるようにするための PC エミュレーターです。
  • VMware は人気の高い市販の完全仮想化ソリューションで、そのまま修正なしのオペレーティング・システムを仮想化できます。
  • z/VM は 64 ビットの z/Architecture に対応した最新の VM オペレーティング・システムです。z/VM はハードウェア支援による完全仮想化を行い、Linux を含めた広範なオペレーティング・システムをサポートします。
  • Xen はオープン・ソースの疑似仮想化ソリューションです。ゲスト・オペレーティング・システムには変更が必要ですが、ハイパーバイザーと連動して実際に近いパフォーマンスを実現します。
  • User-mode Linux もオープン・ソースの疑似仮想化ソリューションです。各ゲスト・オペレーティング・システムが、ホスト・オペレーティング・システムのプロセスとして動作します。
  • coLinux (Cooperative Linux) は、2 つのオペレーティング・システムが協調して基礎ハードウェアを共有できる仮想化ソリューションです。
  • Linux-Vserver は、個々のゲスト・サーバーをセキュアに分離する、GNU/Linux システムを対象としたオペレーティング・システム・レベルの仮想化ソリューションです。
  • OpenVZ は、チェックポイントの指定と仮想専用サーバーのライブ・マイグレーションをサポートするオープン・システム・レベルの仮想化ソリューションです。
  • Linux KVM は、Linux のメインライン・カーネルに初めて統合された仮想化技術です。単一のカーネル・ロード可能モジュールにより、仮想化対応ハードウェアで実行する Linux カーネルがハイパーバイザーとして機能し、修正なしの Linux および Windows ゲスト・オペレーティング・システムをサポートすることが可能になります。
  • developerWorks から直接ダウンロードできる IBM トライアル・ソフトウェア を使用して、Linux で次の開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux, Open source
ArticleID=245749
ArticleTitle=仮想 Linux
publish-date=12292006