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

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ディスクがシステムあたりひとつしか作れず融通がきかないこと、レポジトリ上のコードそのままでは動かないことから、実用性はあまり高いとは言えませんね。