本エントリをご覧になりながら動かしてみると判るかと思いますが、正直なところ、実用性については乏しい機能なのですが、共有ディスクを使った実験などを行う際には役にたつかもしれません。
- 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ディスクがシステムあたりひとつしか作れず融通がきかないこと、レポジトリ上のコードそのままでは動かないことから、実用性はあまり高いとは言えませんね。
0 件のコメント:
コメントを投稿