Xenのディスクイメージファイルは以下のように固定ディスクをそのままファイルに移したような構造になっています。

# file test.img
test.img: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x82, starthead 0, startsector 208845, 2104515 sectors; partition 3: ID=0x83, starthead 0, startsector 2313360, 18651465 sectors, code offset 0x48

なので、基本的にはループバック・デバイスとしてマウントする事が可能です。
ただし、ディスクイメージはパーティションに区切ってあると思いますので、その分にひと手間ひつようです。

基本的な作業の流れは以下のとおり。

1. losetup コマンドでディスクイメージファイルをループバック・デバイスに割り当てる。
2. kpartx コマンドでディスクイメージ内の各パーティションにデバイスファイルを割り当てる。
3. 必要なパーティションのデバイスファイルを mount コマンドでマウントする。

losetup コマンドでディスクイメージファイルをループバック・デバイスに割り当てる。

losetup -fコマンドで空いているループバック・デバイスを探して、そのデバイスにイメージファイルを割り当てます。

# losetup -f
/dev/loop0
# losetup /dev/loop0 /var/lib/xen/images/test.img
# losetup -a
/dev/loop0: [0900]:153944114 (/var/lib/xen/images/test.img)

kpartx コマンドでディスクイメージ内の各パーティションにデバイスファイルを割り当てる。

ループバック・デバイスに割り当てた仮想ディスクにパーティションの状況をfdiskコマンドで調べます。

# fdisk /dev/loop0

このディスクのシリンダ数は 1305 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
   (例. DOS FDISK, OS/2 FDISK)

コマンド (m でヘルプ): p

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *           1          13      104391   83  Linux
/dev/loop0p2              14         144     1052257+  82  Linux swap / Solaris
/dev/loop0p3             145        1305     9325732+  83  Linux

コマンド (m でヘルプ): q

3つのパーティションが存在することが確認できます。
kpartx -aでそれぞれのパーティションをデバイスファイルに割り当てます。
/dev/mapperディレクトリの下に新たなデバイスファイルが作成されます。

# kpartx -a /dev/loop0
# ls -l /dev/mapper/
合計 0
crw------- 1 root root  10, 62  2月 24 00:07 control
brw-r----- 1 root disk 253,  0  3月  5 22:07 loop0p1
brw-r----- 1 root disk 253,  1  3月  5 22:07 loop0p2
brw-r----- 1 root disk 253,  2  3月  5 22:07 loop0p3

仮想ディスクでLVMを使っているとここから先がめんどくさいので、私はXenの仮想ディスクではLVMは使いません。

必要なパーティションのデバイスファイルを mount コマンドでマウントする。

あとは通常のディスクと同じようにマウントするだけです。

# mount -t ext3 /dev/mapper/loop0p1 /mnt/tmp
# ls -l /mnt/tmp
-rw-r--r-- 1 root root  952782 11月  4 08:46 System.map-2.6.18-164.6.1.el5xen
drwxr-xr-x 2 root root    1024 11月  9 15:51 grub
-rw------- 1 root root 2383144 11月  9 15:51 initrd-2.6.18-164.6.1.el5xen.img
drwx------ 2 root root   12288  6月 17  2009 lost+found
-rw-r--r-- 1 root root   80032  3月 13  2009 message
-rw-r--r-- 1 root root  107413 11月  4 08:47 symvers-2.6.18-164.6.1.el5xen.gz
-rwxr-xr-x 1 root root  817164 11月  4 09:53 xen-syms-2.6.18-164.6.1.el5
-rw-r--r-- 1 root root  375762 11月  4 06:11 xen.gz-2.6.18-164.6.1.el5

使い終わった後の手順

必要なくなった仮想ディスクを開放するには、逆の手順で行います。

# umount /mnt/tmp
# kpartx -d /dev/loop0
# ls -l /dev/mapper/
合計 0
crw------- 1 root root 10, 62  2月 24 00:07 control
# losetup -d /dev/loop0
# losetup -a
# losetup -f
/dev/loop0

今回の秋の連休は有休も使って9連休にしていました。
休み明けのボケた頭では仕事にならないので、午前中は開発用サーバたちのパッケージのアップデートをしていたところ、その中の１つにログインできませんでした。

そのホストは OpenSolaris 2009.06 の中に立てた Linux Branded Zone（BrandZ と書いた方がいいのかな）にインストールした CentOS3 でした。Solaris の Zone なので、ホストOS の方からは自由に Linux のファイルシステムに入っていけます。中のファイルを調べたところ、ログファイルの１つが46GB以上に肥大化してしまってディスクの残り容量が無くなってしまっているのが原因のようでした。

これなら、巨大化したログファイルを削除すれば問題解決だな、と軽い気持ちでrm ログファイル を実行したところ、意外な結果が戻ってきました。

cannot delete file: no space left on device.

ディスクに空き領域が無いからファイルを消したいのに、空き領域が無いからファイルを消せないと言われても。。。

ファイルシステムが壊れているのかと zpool scrub を実行してもエラーは無し。

Google 先生に質問してみたところ、zfs の既知のバグのようでした。曰く、ディスクの残り容量が無くなるとスナップショットが存在するファイルは削除できない。スナップショットの無いファイルを消して空き領域を作るか、スナップショットを削除すればよいようです。

が、zfs は使っているもののスナップショットなんて取ったことはありません。
不思議に思い zfs list -t snapshotを実行したところ、以下のように大量のスナップショットが存在していました。

rpool/ROOT/OpenSolaris-200906-090928@2009-07-10-00:41:02                      17.4M      -  2.85G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-10-17:54     39.5K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-10-17:54      40K      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:monthly-2009-07-10-17:54   1.11M      -  6.93G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-11-00:00     3.67M      -  6.94G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-12-00:00     2.86M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-13-00:00     5.29M      -  7.14G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-14-00:00     21.1M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-15-00:00    1.29M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-16-00:00      528K      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-17-00:00     3.73M      -  7.26G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-18-00:00     1.67M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-19-00:00     1.05M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-20-00:00     1.08M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-21-00:00     1.22M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:weekly-2009-07-22-00:00    1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-23-00:00     1.35M      -  7.35G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-24-00:00     5.91M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-25-00:00     5.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-26-00:00     5.87M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-27-00:00     6.60M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:daily-2009-07-28-00:00     6.42M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-11:00    1.73M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-12:00    1.71M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-13:00    1.93M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-14:00    1.88M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-15:00    1.79M      -  7.40G  -
rpool/ROOT/OpenSolaris-200906-090928@zfs-auto-snap:hourly-2009-07-28-16:00    1.26M      -  7.40G  -
...

犯人（？）は zfs の自動スナップショット機能でした。たしかにインストール直後に試しにタイムスライダーを有効にしたことがありましたが、こんな事になるとは。

大量のスナップショットを削除するようにシェルスクリプトを作成して問題は解決しました。ただ、ググっている時に「rpool の容量がなくなるとリブートもできなくなる」のような話もあったので、タイムスライダー（自動スナップショット）はちょっと恐くて使えないなぁ。