触って試すKVM運用ツール「oVirt」：知って見るみるKVM（4）（2/3 ページ）

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

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

oVirtアプライアンスのインストール

　さて、oVirtのアプライアンスをインストールしてみましょう。KVMのイメージなのでファイルをダウンロード、展開し、シェルスクリプトを実行するだけです。ファイルはダウンロードページ（http://ovirt.org/download.html）からリンクをたどれますが、今回はwgetでダウンロードするため、直接URIを指定しています。

$ wget -c ftp://ftp.redhat.com/pub/redhat/ovirt/ovirt-developer-appliance-0.91-1-x86_64.tar
$ su -
# cd /var/lib/libvirt/images
# tar xvf ~user/ovirt-developer-appliance-0.91-1-x86_64.tar
# mv ovirt-developer-appliance-x86_64/developer.img .

　スタンドアロンアプライアンスのイメージはvirt-managerを使って起動させます。virt-managerが内部的に使用しているlibvirt用のイメージディレクトリは/var/lib/libvirt/imagesです。このため、アプライアンスイメージdeveloper.imgは、/var/lib/libvirt/imagesに配置する必要があります。

　スタンドアロンアプライアンスのアーカイブには、ホスト環境設定用のシェルスクリプトが含まれていますが、ここで使用しているバージョン0.91-1のものは、Fedora 11ではそのまま実行しても動きません。理由はkvmパッケージの名称が変更になっているためです。Fedora 9では「kvm」だったものが、Fedora 11では「qemu-kvm」に変更されています。ですので、スクリプトも下記のように修正しておく必要があります。

# diff -u create-wui-appliance.sh.bk create-wui-appliance.sh
--- create-wui-appliance.sh.bk  2009-09-16 00:55:01.717300809 +0900
+++ create-wui-appliance.sh     2009-09-16 00:55:23.118245567 +0900
@@ -179,7 +179,7 @@
fi
 
# now make sure the packages we need are installed
-rpm -q libvirt -q kvm -q virt-manager -q virt-viewer >& /dev/null
+rpm -q libvirt -q qemu-kvm -q virt-manager -q virt-viewer >& /dev/null
if [ $? -ne 0 ]; then
# one of the previous packages wasn't installed; bail out
die "Must have the libvirt, kvm, virt-manager, and virt-viewer packages installed"

　このスクリプトを実行するには、先にlibvirtdを起動させておく必要があります。スクリプトの内部でvirshというlibvirtの管理用ユーザーインターフェイスのコマンドを実行し、仮想マシンの設定を行っているためです。

# service libvirtd start
# bash ovirt-developer-appliance-x86_64/create-wui-appliance.sh -v

　上記のcreate-wui-appliance.shスクリプトのオプション「-v」が、ディベロッパーバージョンとして設定するためのオプションです。これでoVirtを使うための準備が整いました。

oVirtアプライアンスの起動

　それでは、早速oVirtアプライアンスを起動してみましょう。次のように入力します。

# virsh start developer
Domain developer started
# virsh start node3
Domain node3 started
# virsh start node4
Domain node4 started

　ドメインdeveloperがoVirtサーバ（管理サーバ）の物理サーバに相当し、ドメインnode3、node4が管理対象ノードの物理サーバに相当します。図にすると次のようになります。

図1　oVirtアプライアンスの入れ子構造

　「仮想マシンの中に仮想マシンが入れ子になる」というのが、oVirtアプライアンスのイメージです。そのことは、virt-managerから見えるリソースと、oVirtコンソールから見えるリソースの違いから分かります。

　では、virt-managerとoVirtコンソールを起動して見比べ、確認してみましょう。

　virt-managerはGTKのツールなので、アプライアンスを配置した物理サーバにインストールした Fedora 11（以後、ホストOSと呼びます）上でvirt-managerコマンドを実行すれば起動します。

$ sudo virt-manager &

　oVirtの管理コンソールの本体は、前回説明したとおりWebアプリケーションですので、Webブラウザからアクセスします。oVirtアプライアンスはデフォルトでは、oVirtサーバ上、つまりローカルホストでしか管理コンソールにアクセスできないように設定されていますので、sshでXforwardできるように設定しておく必要があります。/etc/ssh/sshd_configを以下のように修正し、sshdを再起動しておきます。

X11Forwarding yes

　Webブラウザを起動する際には、ホストOSで次のコマンドを実行します。

$ LANG=C ssh -Y root@192.168.50.2 firefox

　すると、以下のように表示されます。

画面1　virt-manager（クリックすると拡大します）

画面2　oVirtコンソール（クリックすると拡大します）

　上記のように、virt-managerではdeveloperが見えていますが、oVirtコンソールからはdeveloperが見えないことが分かります。これはハードウェアリソースプールを構成するのはoVirtノードであるためです。developerは管理サーバであるため、ハードウェアリソースを提供しません。なので、ハードウェアリソースプールには表示されない、というわけです（注4）。

注4：前回の記事を書く際、これを理解していなかったので、物理サーバ1台でoVirtをネイティブにインストールしてしまい、ハードウェアリソースがまったく表示されませんでした。