Linux標準の仮想化技術「KVM」の仕組み：知って見るみるKVM（1）（1/2 ページ）

アナウンス後わずか2カ月でLinux Kernelにマージされたことで一躍注目を浴びることになった仮想化技術「KVM」。しかし、その具体的な仕組みや使用方法となると、意外と知られていないのではないでしょうか。この連載ではそんなKVMについて紹介します（編集部）

[まえだこうへい，Debian JP Project]

　KVMは、Linux Kernel自体をハイパーバイザとする仕組みで、正式名称を「Kernel-based Virtual Machine」といいます。KVMは現時点では、Intel VT-xやAMD-VといったCPUの仮想化支援機能を必要とし、完全仮想化によりOSの仮想化環境を提供します。

　この記事では、「KVMの名前は聞いたことはあるが詳しくは知らない」という方、「興味はあるけど使い方がよく分からない」という方を想定し、全3回でKVMの概要と基本的な使い方、今後の課題について紹介したいと思います。

OS仮想化技術のおさらい

　サーバの仮想化技術自体は、メインフレームや商用UNIXなどのエンタープライズ向けの製品では昔からありました。しかし、OSの仮想化技術がとても身近な存在となったのは、この数年の、主にIntel Architecture向けのハードウェア、ソフトウェアの両面における急速な仮想化技術の発展によるものでしょう。

　おかげで、仕事場だけでなく自宅でも、OSの仮想化技術を活用したサーバ統合を行うことが可能になっています。本記事の読者の皆さんも、VMware ESXiやXen、あるいはそのほかの仮想化技術をすでに使われている方も多いかと思います。

　一般的にOSの仮想化は、ほかのOSの上で仮想マシンを動かすものと、ハードウェアの上で直接仮想マシンを動かすものの大きく2種類に分かれます。

図1　2種類の仮想化技術

　前者はVMware Serverや、QEMUなどのホストOSの上で動く仮想化技術です。一方、後者のハードウェアの上で直接仮想マシンが動くタイプの仮想化技術は、「ハイパーバイザ」あるいは「仮想マシンモニタ」と呼ばれる、ある意味仮想化専用のOSの上で仮想マシンを動かす技術です。前述のソフトウェアは後者に当たります（仮想化技術の分類方法は人によって異なり、あまり細かい分類は意味がないのでここでは触れません）。

KVMの概要

　今回紹介するKVMは、ハードウェアのエミュレーションやゲストOSの管理用のフロントエンドとして「QEMU」を使い、Linuxの上でゲストOSを動かすので、一見前者のホストOS型に見えます。しかしLinux自体をハイパーバイザにしてしまうことを考慮すると、後者のハイパーバイザ型といえるでしょう。

　KVMはもともと、イスラエルのQumranet社（http://www.qumranet.com/）が開発したオープンソースソフトウェアで、2006年10月にアナウンスされた後、たった2カ月後の2006年12月にLinux Kernelにマージされたことで話題になりました。Linux kernel 2.6.20から標準機能として利用でき、最近のディストリビューションでもデフォルトで使用可能になっているものが多くなっています。

関連記事：

2007年2月版　仮想化技術「KVM」の高速化パッチ登場！

http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch02a.html

　KVMは、XenやVMware ESXiなど、同じハイパーバイザ型の仮想化技術であるとはいえ、そのアーキテクチャには大きな違いが3つあります。

図2　KVMのアーキテクチャ

1. 仮想化支援機能を有するCPUが必要で完全仮想化のみであること

　準仮想化を主とするXenを例に比較してみましょう。Xenはもともと、CPUの仮想化支援機能を必要としない準仮想化から発展してきました。これは実際のハードウェアをエミュレートする代わりに、Xenの仮想化環境に合わせてゲストOSのカーネルをXen専用に最適化します。

　一方完全仮想化は、OSではなくハードウェア自体を仮想化します。例えば、QEMUのようにソフトウェアだけで完全仮想化を実現するものもあります。ハードウェア自体も仮想化するため、x86の上でsparcやppc、armなどのまったく別のアーキテクチャを動かすこともできます。ただし、ソフトウェア的にハードウェアをエミュレーションしているため、オーバーヘッドも非常に大きくなります。

　しかし、Intel VT-xやAMD-Vの登場により状況が変わりました。いままでソフトウェアでハードウェアをエミュレーションしていた部分を、CPUが肩代わりしてくれるようになったからです。XenやKVMは完全仮想化を実現するために、このCPUの仮想化支援機能を使うことで、完全仮想化のオーバーヘッドを軽減しています。それでも準仮想化に比べれば最適化されていない分、パフォーマンス面では劣ります。

　しかし、メリットもあります。ハードウェア自体を仮想化するため、カーネルを改変しなくても、普通のOSをそのままで動かすことができます。例えば、WindowsをゲストOSとして動かすことも可能です。

　ただしLinuxの場合、現在ではハードウェアネイティブ、準仮想化環境のどちらでも動くようなカーネルを提供するディストリビューションが増えていたり、完全仮想化でもデバイスドライバだけは準仮想化を行うようにしたりと、お互いの利点をうまく活用するようにシフトしてきています。

2. 独自のハイパーバイザを持たず、Linux自体をホストOSとしてゲストOSの制御を行うこと

　VMwareのような専用のハイパーバイザは、その開発も独自に行われています。つまり、各種ハードウェアに対するデバイスドライバも一から作らなければならない、ということです。この点は大きなデメリットといえるでしょう。

　一方、KVMは独自にハイパーバイザを開発せず、Linuxをハイパーバイザとする機能を提供します。このため、とてもシンプルで保守性の高い構造になっています。これはLinuxのカーネルモジュールであることの最大の利点です。前述のハードウェアへの対応に関しても、Linuxのものをそのまま利用できるという点もまたメリットです。

3. 管理用ツールとしてKVM用に拡張されたQEMUが必要であること

　運用面については、QEMUの操作を覚える必要がありますが、概念としては、KVMのゲストOSはホストのLinuxから見ると単一のユーザープロセスです。ですから、通常のLinuxのプロセス管理の手法が使えます。つまり、killコマンドやCtrlキーを用いたショートカットによって、通常のLinuxプロセスと同様にゲストOSの破壊や終了、一時停止、再開といった制御を行ったり、topコマンドなどでリソースの使用率を確認することができます。

　またパーミッションに関しても、通常のLinuxでの扱いと同じです。あるユーザーで起動したゲストOSは、ホストのLinuxから見ればそのユーザーの「プロセス」ということになります。ゲストOSからのリソース要求は/dev/kvmキャラクタデバイス経由で行われ、すべてのアクセスはホストのカーネルにチェックされます。つまりシステム管理者は、既存のツールで仮想マシンを管理することができるわけです。

　ただ、通常の場合、一般のLinuxディストリビューションをホストOSとして使うことになるため、デメリットもあります。ハイパーバイザとして考えた場合、普通のディストリビューションでは余計なパッケージや機能が多過ぎます。またX環境も必要です。従ってサーバ用の統合環境として使うには、自分でパッケージを最小限のものに絞り、要塞（ようさい）化してセキュアな環境を作る必要があります（もっとも、これはXenを使っていたとしても同じですが）。