KVMのゲストOSインストールが遅い件(イメージファイルのパフォーマンス)

(2010-04-11追記)
KVM環境を再構築して、ゲストOSのインストールをしたところ、どのファイルフォーマットを使っても、体感的にはあまり変わりませんでした。
ゲストOSのディスク容量が巨大な場合はフォーマットで速度差が出ると思いますが、今回は20GBだったのでほとんど気になりませんでした。
再構築前の環境での、ゲストOSインストールが遅かった原因については不明です。

KVMのゲストOSインストールが、やたら遅いです。
OSをネットワークインストールしているので、ネットワークインタフェースの問題もあると思うのですが、それにしても遅いです。
ということで、ちょっと調べてみました。
結論から言うと、イメージファイルのフォーマットが問題かと思います。

まず、KVMで利用するイメージファイルのフォーマットですが、以下の2種類があります。

- qcow2 : ファイルサイズが指定サイズより小さく、使用している領域分のみ確保する。データ増加に伴い、ファイルサイズを拡張するので、拡張時にオーバヘッドがある。
- raw : 初めから指定サイズ分のイメージファイルを作成する。無駄にディスクを使う。

私は初め、qcow2形式を使っていたので、ファイルサイズ拡張時のオーバヘッドが原因だと推測して、raw形式を使ってゲストOSをインストールしてみました。
qcow2形式に比べれば速くなったのですが、非VMと比較するとかなり遅い印象を受けました。
仮想環境だからと言われればそれまでなのですが、サーバとして使用する場合を考えると、このディスクI/Oの性能は許容できないのではないかと思いました。

で、調べてみると結局raw形式でも実は指定サイズ分の領域を確保していないということが分かりました。
raw形式のファイルは、作成時点では実際の領域が確保されていないが、サイズ情報は変更されあたかも領域を確保しているような動作をしているようです。(スパースファイル)

$ qemu-img create -f raw test.img 20G 
Formatting 'test.img', fmt=raw size=21474836480
$ ls -kl
-rw-r--r-- 1 user user 20971520 2010-04-10 13:40 test.img
$ qemu-img info test.img 
image: test.img
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 0

上記のようにサイズ情報は20GBとなっているのに、ディスクサイズ(disk size)は0となっています。
つまり、raw形式でもファイルサイズ拡張時にオーバヘッドがあることになります。

では、事前に指定サイズ分の領域を拡張するにはどうすればよいか。
ddコマンドでノンスパースなイメージファイルを作成すれば大丈夫です。

$ dd if=/dev/zero of=test.img bs=1M count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 211.835 s, 101 MB/s
$ ls -kl
-rw-r--r-- 1 user user 20971520 2010-04-10 15:13 test.img
$ qemu-img info test.img 
image: test.img
file format: raw
virtual size: 20G (21474836480 bytes)
disk size: 20G

先ほどのraw形式とは異なり、ディスクサイズ(disk size)が20Gになっています。
ノンスパースなrawファイルを使用すると、インストールがかなり速くなります。

各ファイルフォーマットでのインストール時間比較はできなかったのですが、ノンスパースなrawファイルによるI/O性能の改善を体感的に確認できました。
サーバ使用する場合は、qcow2によるディスク節約のメリットよりも、ノンスパースrawのパフォーマンスを優先したほうがよいと思いました。