クラウドコンピューティングの基盤技術であるKVMに関する予備的研究

[[281929]]

KVM は業界で最も人気のあるハイパーバイザーであり、正式名称はカーネルベースの仮想マシンです。これは Linux カーネル内のカーネル モジュールとして存在します。モジュール名はkvm.koです。カーネルによってスケジュールされ管理されるプロセスと見なすこともできます。 Linux バージョン 2.6.20 以降では、カーネルのトランク開発に完全に正式に追加され、コードが正式にリリースされました。 KVM は主に CPU とメモリの仮想化を管理するために使用され、IO デバイスの仮想化は Qemu によって完了します。なぜこのような分業が行われているのかを知るには、読み続けてください。

KVM と Qemu の過去と現在

Qemu は、純粋にソフトウェアによって実装されたオープンソースの「シミュレーション」ソフトウェアです。 CPU、メモリ、各種 IO デバイス、マウス、キーボード、USB、ネットワーク カード、サウンド カードなどを含む完全な仮想マシンの実装をシミュレートできます。基本的にシミュレートできないものは何もありません。 KVM との関係が何なのか疑問に思う人もいるかもしれません。彼らを協力関係、つまりお互いがいなければ生きていけない良き友人と考えることができます。

KVM は Qemu なしでは動作しません。 KVM 実装の初期段階では、開発とコードの再利用を簡素化するために、Qemu をベースに変更が行われました。主な点は、IO 仮想化モジュールをユーザー空間に実装したまま、パフォーマンスを重視する CPU 仮想化とメモリ仮想化の部分をカーネルに移動することです。このアプローチは主にパフォーマンス上の理由によるものです。 CPU とメモリの仮想化は非常に複雑な仮想化モジュールであり、非常に頻繁に使用されます。ユーザー空間に実装された場合、ユーザー状態とカーネル状態が頻繁に切り替わるため、パフォーマンスに大きな影響が及ぶことは避けられません。 IO 仮想化をユーザー空間で別途保持する必要があるのはなぜですか?これはトレードオフの結果です。まず、IO デバイスが多すぎます。 2 番目に、IO 仮想化は他の 2 つのモジュールと比較してあまり頻繁に使用されないため、オーバーヘッドは小さくなります。したがって、カーネルを可能な限り純粋に保つために、このような割り当てが行われます。

Qemu は KVM なしでは動作しません。前述のように、Qemu はユーザー空間で実行される純粋なソフトウェア実装であり、パフォーマンスが非常に低くなります。したがって、Qemu の観点から見ると、Qemu は KVM の仮想化機能を使用して、独自の仮想マシンに高速化を提供していると言えます。

初期の頃は両者の区別はなく（共存せず）、KVM によって変更されたモジュールは qemu-kvm と呼ばれていました。 Qemu1.3 バージョン以降では、2 つが 1 つに統合されました (共存)。 Qemu を使用して仮想マシンを作成するときに KVM モジュールをロードする場合は、パラメータ --enable-kvm を指定する必要があります。

KVMとQemuの関係

KVM アーキテクチャ

KVM は、ハードウェア仮想化 (Intel VT または AMD-V) に基づく仮想化ソリューションです。上記の Qemu との関係の分析を通じて、仮想化分野におけるその位置が基本的にわかります。実際には、CPU とメモリの仮想化のみを担当し、デバイスのシミュレーションは担当しませんが、シミュレーション用のユーザー空間 Qemu へのインターフェースを提供します。このインターフェースは/dev/kvmです。

Qemu は、/dev/kvm インターフェイスを通じて仮想マシンのアドレス空間を設定し、シミュレートされた I/O デバイスを提供し、関連するデバイス エコー操作をホスト マシンにマップして、I/O デバイス全体の仮想化操作を完了します。

KVM アーキテクチャ

/dev/kvm インターフェースは、Qemu と KVM 間の相互作用のための「ブリッジ」です。基本的な原理は次のとおりです: /dev/kvm 自体はデバイス ファイルであるため、ioctl 関数を通じてファイルを制御および管理することができ、それによってユーザー空間とカーネル空間間のデータ相互作用が完了します。 KVM と Qemu 間の通信プロセスは、主にデバイス ファイルに対する一連の ioctl 呼び出しです。

仮想マシンの作成を例に挙げてみます。仮想マシンは本質的には、ユーザー状態データ構造とカーネル状態データ構造を含むホスト マシンのプロセスです。ユーザー状態部分は Qemu によって作成および初期化され、カーネル状態部分は KVM によって完了されます。完了すると、作成された仮想マシンを表すファイル ハンドルが返されます。ファイル ハンドルの ioctl 呼び出しを使用すると、仮想マシンのアドレス空間とホストのアドレス空間の間のマッピング関係を確立したり、仮想マシンが使用する複数のスレッド (仮想プロセッサ、vCPU) を作成したりなど、仮想マシンを適切に管理できます。作成された vCPU に対して、対応するファイル ハンドルも生成されます。同様に、vCPU のファイル ハンドルへの ioctl 呼び出しを使用して vCPU を管理することもできます。

これについては後ほど、具体的な内容を解説する特別記事を掲載する予定です。

VMM 管理ツール - libvirt

現在、仮想化の分野は盛んであると言えます。 KVM、Xen、VMware、VirtualBox、Hyper-V など、さまざまなシナリオ向けに多くの仮想化ソリューションが提案されています。これらのソリューションの具体的な機能については、前の記事「仮想化テクノロジの概要」を参照してください。ソリューションが多数ある場合、共通モジュールも多数あるはずです。違いは、異なるハードウェア メーカーへの適応にある可能性があります。より多くのメーカーをサポートし、より多くの分野に適用するために、多くの IaaS ソリューションでは複数の仮想化テクノロジーを統合する必要があります。このとき、プラットフォームベースの管理ツールがあれば非常に便利ですが、libvirt はそのようなツールです。

libvirt アーキテクチャ

libvirt は複数の仮想化ソリューションをサポートするだけでなく、OpenVZ や LXC などのコンテナ仮想化システムもサポートします。 virsh、virt-install、virt-manager など、GUI およびコマンド ライン形式をサポートする仮想マシン管理ツールの完全なセットを提供します。汎用性と管理の容易さから、OpenStack、OpenNebula、Eucalyptus など、多くのクラウド コンピューティング フレームワーク プラットフォームでは、仮想マシンの管理に最下位レベルで libvirt の API を使用しています。ここではこのツールについてのみ説明しましたが、ご興味があればインストールして試してみてください。

KVM と Qemu の git パスは以下の通りです。興味があれば、ソースコードをダウンロードして勉強してみてください。

 git をビルドします。
 git クローン git://git.kernel.org/pub/scm/virt/kvm/kvm.git
 qemu.git (kvm を含む):
 git クローン git://git.qemu-project.org/qemu.git