運用上の課題を解決する管理ツール：知って見るみるKVM（3）（3/3 ページ）
アナウンス後わずか2カ月でLinux Kernelにマージされたことで一躍注目を浴びることになった仮想化技術「KVM」。しかし、その具体的な仕組みや使用方法となると、意外と知られていないのではないでしょうか。この連載ではそんなKVMについて紹介します（編集部）
敷居が高い原因は？
今回の検証で、導入の敷居が高いと感じた要因を下記に挙げてみます。
●現状では、サポート対象のOSは基本的にFedora 10以降のみ
2009年6月上旬にFedora 11がリリースされましたが、リリース段階ではまだoVirtは含まれていませんでした。また、開発元のドキュメントには「10以降サポート」と書いてはあるものの、Fedora 11リリース時の段階ではFedora 10にしか対応していませんでした。なお、ほかのディストリビューションでは仮想アプライアンスを使えば導入は可能なようですが、ドキュメントが更新に追い付いていない状態です。
●ドキュメントの更新が追い付いていない。注意事項の記述が目立ちにくい
oVirt自体の開発速度が速いので、前者はある意味、仕方のないことかもしれません。後者は、ドキュメントに沿って行うと、一見、自分が何か失敗したのだと勘違いする処理結果があります。ところがドキュメントをよく読むと、http://ovirt.org/install-instructions.htmlに、
Even if it succeeds, it always exits with an error code of ``1''. Yes, this is a bug.
（訳：成功したとしてもいつもエラーコード1が出力される。これはバグだ）
と記述されています。「this is a bug.」のところは、もっと目立つようにしてほしいものですね。
●サブシステムが多い
検証中に悩まされたのはこの点です。oVirtを構成するサブシステムが多いので、1つ解決してはまた別の問題、1つ解決してはまた別の問題、という具合に、対応してもなかなかうまくいかず、どつぼにハマってしまったような気になります。
今後、インストーラがさらに簡単になり、自動的にほぼ問題なくインストールできるようになれば、導入自体の難易度は下がると思います。ただ一方、ユーザーにとってのブラックボックスとなる部分は増加します。これはトレードオフなので仕方ないことではありますが、運用するうえでは、やはりサブシステム間の関係を理解し、全体を把握していないと、障害が発生した際の対応が非常に困難になると推測できます。
なお、トラブル原因の当たりは付けているのですが、確認して検証の続きをやる時間が取れないので、検証の続きは次回に。
またoVirtの開発目標は、oVirt projectのWebサイトのホームページ（http://ovirt.org/）に「oVirt goals」として記載されています。ここには以下のように記載されています。
- Empower virtual machine owners without giving up control of hardware
（訳：ハードウェアの制御を失うことなく、仮想マシン所有者に力を与える） - Automate virtual machine clustering, load balancing, and SLA maintenance
（訳：仮想マシンのクラスタリングや負荷分散、SLA維持（注8）を自動化する） - Simplify management of large numbers of machines
（訳：多数のマシン管理を単純化する） - Work across platforms and architectures
（訳：プラットフォーム、アーキテクチャの違いを超えて動作するようにする）
これを見ても分かるとおり、oVirtはビジネス向けの機能強化を図っていくものと期待できます。特に、最近のRed Hatのリリースなどでは、いわゆるクラウドコンピューティングに言及した発表がなされるのを報道記事で目にしますが、ここでの内容はそれを意識しているものと思われます。ここでは深く言及しませんが、サービスレベルの向上につながる機能が実装され、それがシンプルに、簡単に扱えるようになるのであれば、運用管理の観点からはとても好ましいことでしょう。
注8：原文では「SLA maintenance」となっていますが、意味を考えると「SLAの維持」を自動化するのではなく、「サービスレベルの維持を自動化すること」と考えるのが妥当でしょう。
そもそもKVMの優位性は？
さて、ここまでの説明を踏まえて、あらためてほかの仮想化技術に比べたKVMの優位性について考えてみましょう。
明確な優位性としては、1回目でも触れましたが、Linux Kernelのメインラインにマージされていることが挙げられます。KVMはそのアーキテクチャ上、VMwareやXenに比べるとパフォーマンスが劣るのではないかと思われています。とはいえ、カーネルを再構築しなくても、コマンドラインだけでノートPCでも気軽に使える点はメリットです。
そうした意味合いからKVMは、サーバ仮想化の手段としてではなくとも、ニッチな領域で生き残っていく（注9）のではないかと思います。ちなみに筆者個人としては、わざわざ同じ土俵で勝負をしなくてもいいのではと思っています。
注9：ニッチとはいっても、将来的にスケールしない領域であれば、ビジネス的には意味がありませんが。
まとめ
今回、KVMを実際に運用していくうえでの課題として2つの管理ツールを挙げました。そしてその中で、主にRed Hatによって開発されているoVirtについて紹介しました。
ただ残念ながら、今回の検証では実際にoVirtを動かし、仮想マシンを制御するところまではできていません。そこで次回は、実際に正常に稼働するところまで検証・確認し、紹介できるようにしたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.