今後、KVMが普及するかどうかは、oVirtの出来とリリースのタイミングに少なからず影響を受けそうです。そこで、もう少しoVirtにフォーカスしてみます。
今回の記事を書くにあたり、Fedora 10でoVirtの検証を行ってみました。ところが、実は、検証作業がうまくいっていません。oVirtを構成する各サブシステムは一見正常に動いているように見えるのですが、oVirtで管理するハードウェアリソースプールの大本になるそもそものハードウェアリソースがまったく見えない状態で止まっている状況です。情けない話です……。
原因の当たりは付けているのですが、それを解決しても本当に動くのか確証が持てないので、今回は検証そのものの話ではなく、oVirtの概要について見てみることにします。oVirtはサブシステムが非常に多く、各サブシステムについて説明するだけでそれぞれ1つの記事が書けるくらいのボリュームがあります。
oVirtは、Webベースの管理コンソール、認証、DNSやDHCP、共有ストレージの機能を提供し、複数のハイパーバイザとその上で動く仮想マシンを管理するツールです。各機能はoVirt自体が実装しているわけではなく、前述のとおり、各種のサブシステムを組み合わせています。oVirtの本体は、Ruby on Railsで実装されているWeb UIによる管理コンソールで、各サブシステムを連携、統合しています。
oVirtは最低1台の物理マシンがあれば構成できますが、これは開発環境やテスト環境などの用途に限定することが推奨されています。本番環境として使うには、最低2台、推奨としては3台以上の物理マシンが必要です。
その構成は、
です。oVirtノードというのが、仮想マシンを動かす、oVirtの管理対象ノードです。2台構成の場合は、管理サーバと共有ストレージを同一マシンで構成します。1台構成の場合はそのまんま1台にすべてを集約することになります。ハードウェアの仮想化支援機能(Intel VTやAMD-V)が必要なのは、ハイパーバイザー用の環境である、oVirtノードだけです。ストレージサーバは、iSCSIかNFSをoVirtノードから利用できる必要があります。
ネットワーク構成には、2つのセグメントが必要です。管理用セグメントと、仮想マシンのサービス用セグメントです。論理構成の概要は図1のようになります。各サーバの構成は以下のようになります。
注6:すでにネットワーク上に各サーバが存在する場合は、管理サーバ上に別途導入する必要はありません。
現状では、Fedora 10以降であることがソフトウェア要件です。さらに、oVirt用のyumリポジトリを登録し、そこから「ovirt-server」「ovirt-server-installer」「ovirt-node-image」「ovirt-node-image-pxe」のRPMパッケージを導入する必要があります。
Fedora 10を最小構成でインストールした環境でoVirtをインストールすると、依存関係によって78ものパッケージが導入されます。データサイズにすると117MBもの容量です。最小構成でインストールするちょっとしたOS並みですね。
なお、今回はFedora 10で検証を行ってみましたが、Debianでは2009年7月現在ではまだパッケージ化されていません。ただし、ovirt(http://bugs.debian.org/501017)、ovirt-server(http://bugs.debian.org/502025)、ovirt-node(http://bugs.debian.org/502024)としてITP(注7)されています。かなり時間はかかりそうですが、いずれそのうちDebianでも正式パッケージになるかもしれません。
注7:「Intent To Package」の略。Debianパッケージにする旨をBTSに宣言することです。
Copyright © ITmedia, Inc. All Rights Reserved.