2009年4月11日土曜日

CentOS 5.3をHVMドメイン+PVドライバで動かす

CentOS 5.1以降ではXen対応カーネルが供給されていますのでそれほど重要ではないのですが、LinuxカーネルにはXen用のPVドライバ(ParaVirtual Driver)が提供されています。

PVドライバを利用すると、IAアーキテクチャ向けのカーネルをXenの上で実行しつつ、最大のボトルネックであるディスクI/OやネットワークI/Oだけを仮想化しパフォーマンスを確保することができます。


・ /etc/modules.conf の修正


・ 初期RAMディスクの再生成


・ /etc/fstabの修正


・ /etc/modules.conf の修正


・ 仮想マシン定義ファイルの修正


・ 再起動、動作確認


・ 初期RAMディスクをもう一回再生成




● /etc/modules.confの修正

Xen PVドライバを適用するため、HVMドメインにインストールされたCentOSの /etc/modules.conf を書き換えます。

hvm-domain:/etc/modules.conf (変更前)

alias eth0 8139cp
alias scsi_hostadapter ata_piix

hvm-domain:/etc/modules.conf (変更後)

alias eth0 xen-vnif

● 初期RAMディスクの再生成

Xen PVドライバを含む初期RAMディスクを生成し、HVMドメインにインストールされたCentOSのGRUBの設定を変更します。

hvm-domain# mkinitrd --preload=xen_vbd /boot/initrd-`uname -r`.pv.img \
    `uname -r`;

hvm-domain:/boot/grub/menu.lst

title CentOS (2.6.18-128.el5)  ※オリジナルの起動設定を元に新規追加
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.18-128.el5 ro root=LABEL=/ rhgb quiet
        initrd /boot/initrd-2.6.18-128.el5.pv.img

● /etc/fstabの修正

HVMドメインにインストールされたCentOSの/etc/fstabを修正します。LABEL=によるファイルシステムの指定をすると、ata_piixを通して見えるIDEエミュレートされた仮想ディスクをマウントしてしまうので、/dev/xvdを直指定します。

#LABEL=/                 /                       ext3    defaults        1 1
/dev/xvda1              /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
#LABEL=SWAP-hda2         swap                    swap    defaults        0 0
/dev/xvda2              swap                    swap    defaults        0 0

● 仮想マシン定義ファイルの修正

Domain-0上にあるHVMドメインのの仮想マシン定義ファイルを修正します。

変更前

disk = [ "file:/var/lib/xen/images/centos53_32hvm.img,hda,w" ]

変更後

disk = [ "tap:aio:/var/lib/xen/images/centos53_32hvm.img,hda,w!",
 "tap:aio:/var/lib/xen/images/centos53_32hvm.img,xvda,w!", ]

ひとつめのVBDはQEMU由来のIDEエミュレーションでプライマリ マスタのハードディスクを定義しています。HVMドメイン上のBIOSがOSをブートするために使います。

ふたつめのVBDは、準仮想でおなじみの仮想ブロックデバイスです。HVMドメインで動作するLinuxカーネルにxen_vbdが組み込まれた時点でアクセスできるようになります。

これら2つのVBDは実体として同じファイルを見ています。このままでは/etc/xen/scripts/blockスクリプトが二重マウントチェックでエラーにしてしまうので、オプションに「!」を付けてチェックを回避します。

※ openSUSE 11.1の場合

openSUSE 11.1+openSUSE 11.1純正Xenパッケージの組み合わせでは、xvdaを定義した時点で起動用の hda が自動的に作成されるようです。このため、ひとつめのVBDを明示的に定義する必要はありませんでした。

disk = [ "tap:aio:/var/lib/xen/images/centos53_32hvm.img,xvda,w!", ]

この動作が最近のXenのデフォルトの挙動なのか、それともopenSUSE 11.1の独自フィーチャーなのかはまだ整理できていません。たぶん後者だと思いますが。

● 再起動、動作確認

HVMドメインを再起動します。まずhaltでVMを停止させ、その後xm create等でVMを新たに作成してください。HVMドメイン内でrebootしてもdisk=[ ...]の設定変更が反映されません。

hvm-domain# halt

domain-0# xm create hvm-domain

うまく起動してきましたでしょうか?起動を確認したら以下のコマンドで、PVドライバ経由でI/Oできていることを確認します。

hvm-domain# mount | grep xvd
/dev/xvda1 on / type ext3 (rw)

hvm-domain# swapon -s | grep xvd
/dev/xvda2                              partition       265064  0       -1

hvm-domain# ls -ld /sys/class/net/eth*/* | grep xen
lrwxrwxrwx 1 root root    0  4月 10 11:30 /sys/class/net/eth0/device
     -> ../../../devices/xen/vif-0

mountおよびswapon -sの出力がhdaではなくxvdaであることから仮想ブロックデバイスドライバが、ethXのデバイスがxen/vif-Xであることから仮想ネットワークデバイスドライバが有効であると判断できます。

● 初期RAMディスクをもう一回再生成

これでata_piixドライバは不要になりました。必須ではありませんが、下記の手順でmkinitrdしなおすとata_piixドライバを初期RAMディスクから追放できます。

hvm-domain# rmmod ata_piix
hvm-domain# rm -f /boot/initrd-`uname -r`.pv.img `uname -r`.pv.img
hvm-domain# mkinitrd --preload=xen_vbd /boot/initrd-`uname -r`.pv.img \
    `uname -r`;

ata_piixドライバを追放したカーネルではLABEL=による指定でファイルシステムを探している場合でも、期待どおり/dev/xvda1など仮想ブロックデバイスを通してマウントしてくれます。

LABEL=/                 /                       ext3    defaults        1 1
#/dev/xvda1              /                       ext3    defaults        1 1
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
LABEL=SWAP-hda2         swap                    swap    defaults        0 0
#/dev/xvda2              swap                    swap    defaults        0 0

2009年3月12日木曜日

Xenのインターフェイスバージョン調査

Xen のインターフェイスバージョンがこれまでどのように上がってきたのか確認してみました。


Xen 3.0.x の頃はリリースの度にハイパーコールの互換性がなくなるような変更が加えられていましたが、 Xen 3.1.x 以降はマイナーバージョンのレベルでハイパーコールの互換性が維持されていることがわかります。



リリースアーカイブから

xen-3.0.2-2/xen/include/public/xen-compat.h:#define ... 0x00030101
xen-3.0.3_0-src/xen/include/public/xen-compat.h:#define ... 0x00030204
xen-3.0.4_1-src/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.1.3/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.1.4/xen/include/public/xen-compat.h:#define ... 0x00030205
xen-3.2.0/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.1/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.2/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.2.3/xen/include/public/xen-compat.h:#define ... 0x00030207
xen-3.3.0/xen/include/public/xen-compat.h:#define ... 0x00030209
xen-3.3.1/xen/include/public/xen-compat.h:#define ... 0x00030209

Mercurial レポジトリから

changeset:   17983:4bdc3de246c3
+++ b/xen/include/public/xen-compat.h   Sat Jul 05 14:43:37 2008 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030209
--
changeset:   17027:88818d55e95a
+++ b/xen/include/public/xen-compat.h   Tue Feb 12 11:37:45 2008 +0000
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030208
--
changeset:   16207:aeebd173c3fa
+++ b/xen/include/public/xen-compat.h   Wed Oct 24 15:22:57 2007 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030207
--
changeset:   16103:ef4119637f52
+++ b/xen/include/public/xen-compat.h   Fri Oct 12 11:55:41 2007 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030206
--
changeset:   12453:bda05853cf21
+++ b/xen/include/public/xen-compat.h   Wed Nov 15 16:44:35 2006 +0000
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030205
--
changeset:   11257:86d26e6ec89b
+++ b/xen/include/public/xen-compat.h   Fri Aug 25 18:39:10 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030204
--
changeset:   11119:aff2e2b7a23b
+++ b/xen/include/public/xen-compat.h   Tue Aug 15 15:50:36 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030203
--
changeset:   9889:42a8e3101c6c
+++ b/xen/include/public/xen-compat.h   Sun Apr 30 09:16:15 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030202
--
changeset:   9868:4e0f2272fbcd
+++ b/xen/include/public/xen-compat.h   Thu Apr 27 14:03:22 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030201
--
changeset:   9512:b524714dfb66
+++ b/xen/include/public/xen-compat.h   Sun Apr 02 09:48:04 2006 +0100
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00030101

2009年3月2日月曜日

blktap ramドライバで共有RAMディスクを試してみる

今回は Xen の blktap に含まれている ram ドライバ (tap:ram:) で遊んでみたいと思います。 ram ドライバとは、ドライバドメイン上に確保されたメモリ空間を仮想ブロックデバイスとして割り当てて利用できるようにするためのものです。複数のドメインから本ドライバを利用すると、最初に確保したメモリ空間を共有するようになります。つまり、仮想ブロックデバイス上のデータは複数ドメイン間で共有されることとなります。

本エントリをご覧になりながら動かしてみると判るかと思いますが、正直なところ、実用性については乏しい機能なのですが、共有ディスクを使った実験などを行う際には役にたつかもしれません。



  • block-ram.c へのパッチ作業

  • ひな形ディスクイメージの作成

  • ramドライバを試してみる

  • おさらい。



■ block-ram.c へのパッチ作業

まず残念なお知らせですが、CentOS 5.2 (i386)環境において、おそらく現在リリースされている Xen のリリースバージョンでは以下の部分をパッチしないとうまく動きません。(Mercurial上から落とした最新ソースでもおそらくパッチが必要でしょう)

tools/blktap/drivers/block-ram.c パッチ前

    161         /* Open the file */
    162         o_flags = O_DIRECT | O_LARGEFILE |
    163                 ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
    164         fd = open(name, o_flags);
    165 

tools/blktap/drivers/block-ram.c パッチ後

    161         /* Open the file */
    162         o_flags = O_LARGEFILE |   // no O_DIRECT
    163                 ((flags == TD_RDONLY) ? O_RDONLY : O_RDWR);
    164         fd = open(name, o_flags);
    165 

どうしてこんな状態でリリースされているのかが大変不思議なのですが、 64 ビット環境であればmalloc() したメモリは常にアライメントされる保証でもあるのでしょうかね?そこまでは追いかけてませんが....

パッチした blktap ドライバをインストールするには、ソースツリーで以下の操作をすると楽です。

# make -C tools/blktap
# make -C tools/blktap install

■ ひな形ディスクイメージの作成

準備ができたら、ひな形のディスクイメージを作りましょう。ddコマンドで256MBのファイルを作成し、その中にとりあえずext3ファイルシステムでも作っておきます。

dom0# dd if=/dev/zero of=/home/vm/ram.img bs=1M count=256
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 0.793614 seconds, 338 MB/s

dom0# mkfs.ext3 /home/vm/ram.img
mke2fs 1.39 (29-May-2006)
/home/vm/ram.img is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
65536 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
〜省略〜
This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

[root@localhost drivers]# dumpe2fs /home/vm/ram.img | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

■ ramドライバを試してみる

これをまずDomain-0上にアタッチしてみましょう。

dom0# xm block-attach 0 tap:ram:/home/vm/ram.img xvdb  w
dom0# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

先ほど作ったファイルシステムの UUID が /dev/xvdb に見えていることから、イメージがきちんと認識されていることがわかります。続いて、ほかの準仮想化ドメイン、ここでは testvm にもアタッチしてみます。先ほど /home/vm/ram.img を Domain-0 にアタッチしましたが、次の VM に attach するには他のファイル名を指定する必要があります(xm block-attachの仕様による)ので、ダミーで適当なファイルを作り、それを指定しておきます。

dom0# touch /home/vm/ram.img.2
dom0# xm block-attach testvm tap:ram:/home/vm/ram.img.2 xvdb  w


dom0# xm console testvm
CentOS release 5.2 (Final)
Kernel 2.6.18.8-xen on an i686

localhost login: root
Password: 
Last login: Sun Mar  1 08:33:35 on tty1
-bash-3.2# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

ログインした環境でもやはり同じ UUID が見えています。これは、 testvm に xvdb として、先ほど作成したRAMディスクがアタッチされているからです。

testvm でファイルシステムを再作成してみます。

-bash-3.2# mkfs.ext3 /dev/xvdb
〜省略〜

-bash-3.2# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          7b55589f-2164-4a99-9743-21ebb46562a4

ファイルシステムの UUID が変わりました。mkfs.ext3 により RAM ディスクの内容が変化したからです。このディスクは Domain-0 からも参照しているので、 Domain-0 から見てどうなったかを確認してみると

dom0# dumpe2fs /dev/xvdb | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          7b55589f-2164-4a99-9743-21ebb46562a4

やはりファイルシステムの UUID が変わっています。つまり、 testvm 上で行った変更が Domain-0 側にも反映されています。しかし、もともとファイルとして作成したイメージファイルには変更はありません。

dom0# dumpe2fs /home/vm/ram.img | grep UUID
dumpe2fs 1.39 (29-May-2006)
Filesystem UUID:          16c03fc3-c3c3-41a6-b6df-eac4c1407296

■ おさらい。


  • tap:ram ドライバで、共有RAMディスクを作成できます。

  • 作成できる共有RAMディスクはひとつだけです(ふたつ目以降のブロックデバイスを作ろうとすると、作成済みRAMディスクを参照します)。

  • 共有RAMディスクを作成する際には初期イメージを格納したファイルが必要です。共有RAMディスクはこのファイルの内容が初期状態となります。

  • xm block-attach コマンドのファイル名チェック、ファイル重複使用チェックをくぐりぬけるため、ふたつ目以降の仮想ブロックデバイスを作成する際にはダミーファイルの指定が必要です。

  • 共有RAMディスクへの書き込み内容は、使用が終わるまで(仮想ブロックデバイスからの参照カウントがゼロになるまで)保持されますが、元ファイルなどには反映されません。

うまく使えばクラスタ構成のテスト用領域として使用したり、繰り返しバッチを行うような場合にバッチ用の元ネタを格納しておく領域(使い終わったら一度 detach 後再度 attach すると内容が初期状態に戻る)などの活用が考えられます。とはいえ、使ってみればわかるとおり、仮想RAMディスクがシステムあたりひとつしか作れず融通がきかないこと、レポジトリ上のコードそのままでは動かないことから、実用性はあまり高いとは言えませんね。

2009年2月22日日曜日

RedHatとMicrosoftがサーバ仮想化の相互運用に関して提携

Red HatとMicrosoftがサーバ仮想化ついての相互運用に関して提携を結んだようです。この提携により下記の内容が実現されることになりそうです。


  • Red Hat Virtualization の機能上で Windows Server ゲストの動作検証が行われ、正式にサポートされる

  • Windows ServerのHyper-Vゲストとして、Red Hat Enterprise Linuxゲストの動作検証が行われ、正式にサポートされる

特に Hyper-V は、これまでは Windows Server および SUSE Linux Enterprise Server と、対応するゲストが非常に限定されていました。 Hyper-V 上で事実上標準的な Red Hat Enterprise Linux がゲストとしてサポートされれば、 Hyper-V を利用した Windows & Linux サーバ統合がより現実的なものとなり、現状 VMware ESX が絶対的に優位なサーバ統合の現状に、何らかの変化がおきるのかもしれません。


Red Hat Moves to Expand Server Virtualization Interoperability


blktapベースの仮想ブロックデバイスをDomain-0にマウントするには

最近の Xen では、仮想ブロックデバイス(VBD)のバックエンドドライバとして blktap を利用することができます。 blktap は VBD のバックエンドのためのインターフェイスで、さらに実際の I/O 機能を持つドライバを組み合わせることで利用します。仮想マシンの定義ファイルに下記の指定をする場合、それは blktap の aio ドライバ(async I/O = 非同期I/O)を使用することになります。

disk = [ 'tap:aio:/var/lib/xen/images/linux.ext3,xvda,w' ]

blktap では、 aio 以外に qcow, qcow2, vmdk など、他の仮想マシン技術で使われるディスクフォーマットの利用が可能となっています。

さて、 aio ドライバのように Linux で普通にループバックマウントできる形式であれば、 Domain-0 からとりあえず触りたいような場合は何も考えずにマウントしてしまえばよいのですが、 QEMU の形式である qcow2 フォーマットのイメージを Domain-0 からマウントしたい時はどうしたらいいでしょうか。

このような場合には、 xm block-attach コマンドを使用して Domain-0 に仮想ブロックデバイス(VBD)を割り当てることができます。第二引数はDomain-0のドメインID(ゼロ)を指定しています。

# xm block-attach 0 tap:qcow2:/var/lib/xen/image/linux-image.qcow2 xvda w
# mkdir -p /mnt/linux-image
# mount /dev/xvda /mnt/linux-image

用が済んだら、アンマウント後に xm block-detach コマンドで仮想ブロックデバイス(VBD)を解放します。

# umount /dev/xvda
# xm block-detach 0 xvda

Domain-0 は特権ドメインであり、一般的には VBD をサービスする側なのですが、それと同時に Domain-0 の正体は「一部ハードウェアやハイパーバイザーへの特権アクセスが許されている」点を除けば、あくまでXen にとっては他のドメインと同じゲストに違いありません。



2009年2月16日月曜日

GPL PV Drivers のパフォーマンス

製品の仮想化技術には、 VMware でも Parallels でも、 Windows をゲストとして動作させる時に I/O パフォーマンスを向上させるためのドライバが用意されています。

このような仮想化デバイスのドライバを使用しない場合、仮想マシン上で動作する Windows などの OS は、仮想マシン技術がエミュレートする PCI バス上のディスクコントローラに対して I/O を行います。これに対して、先のドライバは VMware などの仮想化ソフトウェアと直接 I/O データをやりとりするため、パフォーマンスが向上する仕組みになっています。

さて、 Xen においてもこのようなドライバの仕組みは Paravirtual Driver (準仮想化ドライバ) という形で存在しています。 Xen のソースコードをダウンロードすると unmodified_driver/ などというディレクトリがあったりしますが、それがまさにそのドライバです。

アンオフィシャルですが、 Windows 用のオープンソースな PV ドライバも存在しています。


しかし、ただ単純にベンチマークをとってみると...



【検証環境】

・HP ProLiant ML115 G1
・Athlon64 X2 5600+ (2.8GHz x2)
・8GB PC5300 RAM
・Hitachi HTS72323 320GB 2.5inch HDD
・openSUSE 11.1 + Xen 3.3
・Windows xp SP3 (x86)


あれれ~? PV ドライバを入れた場合のほうがパフォーマンス伸び悩んでますね。というか QEMU のハードウェアエミュレーションと比較し完敗です。何かの間違いでしょう。しかし、再計測しても再計測してもこの結果がひっくり返ることはありませんでした。

そこで、このツールで計測をはじめてから計測が終わるまでの時間を、愛用の G-SHOCK で測ってみました。なお Crystal Disk Mark のソースコードを確認したところ決まった量の I/O 負荷をかけて、それの所要時間から性能を算出しているようです。つまり計測値はアテにならなくても、 I/O に要した"時間"は信用できると考えられます。結果は以下のとおりでした。

PV ドライバ使用時: 3分23秒
PV ドライバ未使用時: 3分31秒

なんだ、やっぱり PV ドライバのほうが早かったんですね。約 6 % の性能アップしていたようです。しかし、これでは本当のスループットがわかりませんね。敢えていえば QEMU エミュレーションから 6% しか性能向上がない PV ドライバというのも随分寂しいものです。( XenSource や Novell が作っているドライバはもっと高いパフォーマンスを示してくれることでしょう)

PV ドライバには I/O パフォーマンスを向上させる以外のメリットとして CPU に対する負荷の低減があります。無意味に低レベルなハードウェアの真似(ゲストによる I/O ポートへのアクセスをトラップしエミュレーション)をする必要がなくなるからです。

I/O パフォーマンスについてはまた計測方法を検討して検証をしてみたいと思います。というわけで、今日はおやすみなさい。




2009年2月15日日曜日

"家庭内乱"管理を少しでもラクにするには

このサイトをご覧いただいている方には、自宅のネットワークを仕切っている方、また実家や親戚の家のネットワーク(家庭内乱)管理をついつい頼まれてしまい、なかなか断れずに面倒をみるハメになっている方なんて、そこそこ多いのではないでしょうか?少なくとも私は実家や親戚宅のネットワーク管理にたびたびかり出されています。

また、ネットに繋がるようにして帰ってくるのは簡単ですが、いざしばらくすると「ネットに繋がらなくなった」と電話がかかってきたり、いろいろな都合でネットワークの変更が必要になるケースがあり、とっても面倒なものです。私は、そういう時のために、(内容はケースバイケースですが)簡単な設定資料を作っていたりします。


このネットワークにおいて、以前機器の移設時に配線ミスによる混乱があったため、この資料は、どちらかといえば物理配線にフォーカスした内容となっています。とはいえクライアント側の設定に必要な項目は網羅されているので、この資料があれば



  • 問い合わせを受けたときに何がどうなっているかを思い出せる
  • ユーザ自身で有る程度の配線見直しなどが可能
  • クライアントの設定方法を書いておけばユーザが自分たちで新ノードを追加できる。もしくは設定業者が対応できる
  • 大きなトラブルがおきたとしても、他の人に対応を引き継げる・・・ことがある
などのメリットが生まれます。

ところで、今回紹介した図は2006年1月時点の私の実家のネットワーク構成に基づいたものです。私は実家から東名高速道路で約300km離れた地点に住んでいるため、なかなか度々面倒を見に行くことはできません。その後実家のネットワークはADSLからひかり電話にサービスを変更するためファイバの引き込みONUなどを設置したのですが、その作業の担当者にこの資料を見せることで、スムーズにWAN側の切り替えを済ませることができたそうです。

パスワードなどの機密情報も含めて記載されている点など、賛否両論はあるでしょうが(そもそもセキュリティ要求が高いような場所ではWANの切り替え工事を電話工事の担当者にやらせないと思いますが:-)、この手の資料は、「備えあれば憂いなし」です。


なお、構成が変わったときにはドキュメントの更新もお忘れなく。