masakazu's Weblog

DRBD – Integrating with Heartbeat V2(http://www.drbd.org/drbd8-howto2.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

As with Heartbeat V1, the preferred way of installing Heartbeat V2 is through your distribution’s package management frontend (yum, apt, rug, whatever). If you do want to build and install from source, the Linux-HA download area has the necessary archives.

Heartbeat V1 と同様、 Heartbeat V2 のお勧めのインストール方法はディストリビューションのパッケージ管理ツール(yum, apt, rug, など)を利用する方法である。もしソースからビルドとインストールを行いたいのであれば、 Linux-HA のダウンロードサイトに必要となるアーカイブがある。

On the Linux-HA site, you will also find the Getting Started V2 howto that will enable you to get an initial Heartbeat V2 configuration up and running.

Linux-HA サイトには、 Heartbeat V2 の初期設定と起動のための Getting Starget V2 howto も見つけられるだろう。

The same prerequisites apply for Heartbeat V2 as do for Heartbeat V1. In fact, you might run Heartbeat V2 just like V1, with unchanged configuration. If, however, you want to use Heartbeat’s new Cluster Resource Manager (CRM) introduced in V2, you need to include this line in your /etc/ha.d/ha.cf:

Heartbeat V1 と同様の前提条件が Heartbeat V2 でも適用される。実際、設定を変更せず Heartbeat V2 を V1 と同じように実行できるかもしれない。しかし、Heartbeat V2 で新しく導入されたクラスターリソースマネージャ(CRM)を利用したいのであれば、 /etc/ha.d/ha.cf に以下の行を追加する必要がある:

crm yes

Simple, isn’t it? Note that if you have that option enabled, Heartbeat will no longer read the haresources file on startup, and will issue a warning if that file exists.

単純だろう。このオプションを有効にすると、 Heartbeat はもう haresources ファイルを起動時に読み込まなくなり、もしこのファイルが存在した場合に警告するようになる。

Heartbeat V2 resources are defined in the Cluster Information Base XML file, usually found in /var/lib/heartbeat/crm/cib.xml. This may be edited manually, see the Linux-HA site for more information (however, see the following paragraph if you prefer a more user-friendly approach).

Heartbeat V2 のリソースはクラスター情報ベースという XML ファイルで定義される。このファイルは普通 /var/lib/heartbeat/crm/cib.xml にある。このファイルは手動で編集される。詳細な情報は Linux-HA サイトを参照せよ。(ただしよりユーザーフレンドリーな方法を好むようであれば次の節を参照。)

Heartbeat V2 includes a GUI for the cluster resource manager, which will manipulate the Cluster Information Base for you. It is written in Python and requires GTK+, Glade, and the associated Python bindings. It’s named ha_client.py, though some distributions rename it to hbgui or similar.

Heartbeat V2 はクラスターリソースマネージャのための GUI を含んでいる。これはクラスター情報ベースを操作する。これは Python で書かれ GTK+, Glade, そして関連する Python バインディングを必要とする。 ha_client.py という名前で、いくつかのディストリビューションはこれを hbgui などと名前を変更している。

With Heartbeat V2, you may address DRBD resources in one of two ways:

Heartbeat V2 では DRBD リソースを二つのうち一つの方法で示すことになる。

• the drbddisk resource type, as in Heartbeat V1,
  
  Heartbeat V1 で drbddisk リソースタイプ
• the drbd resource type, using the Heartbeat V2/OCF interface.
  
  Heartbeat V2/OCF インターフェースで drbd リソースタイプ

In order to set up a working DRBD configuration with Heartbeat V2, follow these steps:

Heartbeat V2 と動作する DRBD の設定をするためには以下の手順に従う:

• Set up your DRBD resource (using either the drbddisk or drbd resource type)
  
  DRBD リソースを設定する(drbddisk か drbd リソースタイプを使って)
• Set up your filesystem resource
  
  ファイルシステムリソースを設定する
• Set up your IP address resource
  
  IP アドレスリソースを設定する
• Set up your service resource
  
  サービスリソースを設定する
• Create an order constraint so the DRBD resource is activated before the filesystem resource (so Heartbeat doesn’t attempt to mount a file system on a node that’s still in secondary mode)
  
  ファイルシステムの前に DRBD リソースが有効になるよう順序制約を作る(Heartbeat はまだセカンダリモードのノードのファイルシステムをマウントしようとしない)
• Create a colocation constraint so the filesystem, IP address, and service resources always run on the same node
  
  ファイルシステムと IP アドレスとサービスリソースが同じノードで実行されるよう位置制約を作る
• (optional) Set a preferred node for the service resource.
  
  (オプションで) そのサービスの優先ノードを設定する

DRBD – Integrating with Heartbeat V1(http://www.drbd.org/drbd8-howto1.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

The preferred way of installing Heartbeat is through your distribution’s package management frontend (yum, apt, rug, whatever). If you do want to build and install from source, the Linux-HA download area has the necessary archives.

Heartbeat をインストールする完全な方法はあたなが利用しているディストリビュージョンのパッケージ管理ツール(yum, apt, run, など)を利用することだ。もしソースコードからビルドしインストールしたいのであれば Linux-HA のダウンロードサイトに必要なアーカイブがある。

On the Linux-HA site, you will also find the Getting Started howto that will enable you to get an initial Heartbeat configuration up and running.

Linux-HA サイトには、 Heartbeat の初期設定と起動のための Getting Starget howto も見つけられるだろう。

In order to have your DRBD resources managed by Heartbeat, the following conditions must be met beforehand:

あなたの DRBD リソースを Heartbeat で管理するためには、次の条件を事前に満たさなければならない:

• Heartbeat, the DRBD kernel module, and the DRBD userland tools must be installed on both cluster nodes (if you’re thinking “duh” now, that’s perfectly appropriate)
  
  Heartbeat, DRBD kernel モジュール, そして DRBD のツールが両方のクラスターノードでインストールされていなければならない(あなたが現在 “duh” を考えているなら、それは完全に適切です)。
• You must have your /etc/ha.d/ha.cf and /etc/ha.d/authkeys configured correctly
  
  /etc/ha.d/ha.cf と /etc/ha.d/authkeys が適切に設定されていなければならない。
• DBRD resources must be configured in /etc/drbd.conf, and that file must have been distributed cluster-wide
  
  RDBD のリソースが /etc/drbd.conf で設定されていなければならない。そしてこのファイルはクラスター間で配布されていなければならない。
• The DRBD kernel module must be loaded (the resource scripts won’t do that for you, your specific distribution will, however, offer a facility to automate this at system boot)
  
  DRBD kernel モジュールがロードされていなければならない(リソーススクリプトはこの作業を行ってくれない、しかしながら、特定のディストリビューションは、システムリブートの時点でこの作業を自動で行ってくれる)。
• Network connectivity must be established on the DRBD replication path and all Heartbeat communication paths
  
  ネットワーク接続性が DRBD レプリケーション経路と Heartbeat 通信経路で確立されていなければならない。
• Not required, but highly recommended: you should have tested and verified manual migration of your DRBD resources
  
  必須ではないが強く勧める: DRBD リソースへのテストと手動でのマイグレーションをすでに行っている。

The haresources file, /etc/ha.d/haresources, is where you’ll configure your managed DRBD as a cluster resource. Normally it makes little sense to have DRBD managed without an associated file system. An entry for DRBD in the haresources file might look like this:

haresources ファイル /etc/ha.d/haresources は、あなたの管理する DRBD をクラスターリソースとして設定する場所である。通常、ファイルシステムと関連しない DRBD を管理することには意味がない。DRBD に対する haresources ファイルの設定は以下のようになる:

joe drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3

This will instruct Heartbeat to manage the DRBD resource r0 concurrently with the ext3 filesystem /var/lib/mysql, which will be mounted from the corresponding block device /dev/drbd0. The preferred node for this resource is joe.

これは /dev/drbd0 というブロックデバイス上の ext3 ファイルシステムで /var/lib/mysql にマウントされている DRBD リソース r0 を管理するよう Heartbeat に指示する。このリソースの優先ノードは joe である。

Of course, the more typical (and complete) usage would be this:

もちろん、より典型的(かつ完全)な利用はこのようになる:

joe drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3 192.168.0.42 mysqld

… which in addition to the DRBD device and file system will also include a service IP address (192.168.0.42) and a MySQL RDBMS daemon (mysqld) in the same cluster resource.

… DRBD デバイスとファイルシステムに加え、同じクラスターリソース上のサービス IP アドレス(192.168.0.42) と MySQL RDBMS デーモン(mysqld) も設定している。

DRBD – Migrating DRBD resources(http://www.drbd.org/drbd8-howto0.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

Suppose we have our DRBD resource r0, corresponding to /dev/drbd0, mounted on /mnt on one cluster node (joe), and want to mount it on the other (jane). This page outlines the process of doing this manually.

以下を想定する。DRBD リソース r0 がある。r0 は /dev/drbd0 に該当する。r0 はクラスターノードの一方(joe) で /mnt にマウントされている。そしてもう一方のクラスターノード(jane) でマウントしたい。このページではこれを手動で行う方法について説明していく。

At first, let’s have a look what the current DRBD status is from joe’s perspective:

最初に、 joe 側で DRBD の状態がどのようになっているかを確認する。

root@joe:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

The first thing we do now is free /dev/drbd0 (if we don’t do this, DRBD will refuse to change that device’s status):

まず最初にすることは /dev/drbd0 を解放すること(こうしないと DRBD はデバイスの状態を変えようとしても拒否する)。

root@joe:~# umount /dev/drbd0

Then we demote r0 on joe, so that the device is secondary on both nodes:

そしたら joe の r0 を降格させる。そうすると両方のノードでデバイスはセカンダリとなる。

root@joe:~# drbdadm secondary r0
root@joe:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:81 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

At this time we can promote jane to become the primary node for this resource:

この時点で jane をこのリソースに対するプライマリノードに昇格させることができる。

root@jane:~# drbdadm primary r0
root@jane:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:81 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Finally, we can mount the device on Jane:

最後に jane でデバイスをマウント出来る。

root@jane:~# mount /dev/drbd0 /mnt

DRBD disallows a few things so as to keep you from shooting yourself in the foot. You might try the following things just to see what happens:

DRBD は自分で自分の足を撃ってしまわないよういくつかの制限を設けている。なにが起きるのかを確認するために次の事柄をためしてみたいかもしれない。

• Demoting a primary device to secondary while it’s still mounted. This will fail with a “device held open by someone” error.
  
  まだマウントされている状態でプライマリデバイスをセカンダリに降格させようとする。この場合 “device held open by someone” というエラーで失敗するだろう。
• Making a device primary while the other one is primary too, unless this is explicitly allowed.
  
  (明示的に許可されていない状態で)他方がプライマリの状態でデバイスをプライマリにしようとする。
• Mounting the backing device directly, while being used by DRBD.
  
  DRBD で利用されている状態でブロックデバイスを直接マウントしようとする。

DRBD – Getting started(http://www.drbd.org/drbd8-howto.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

If you install via tarball, you want to read the README and INSTALL notes first.

もし tarball からインストールしたいのであれば、 README と INSTALL を最初に読んだ方がよい。

You want to also read the upgrade*.txt files in the drbd src directory, or online in the drbd subversion repository.

また、 drbd ソースディレクトリかオンラインの drbd subversion リポジトリに存在する upgrade*.txt ファイル群も読んだ方がよい。

Along with the DRBD tarball or your installed DRBD package, you should find a well commented example configuration file. In the tarball this is in ./scripts/drbd.conf, in installed binary packages it most likely ends up in /usr/share/doc/drbd, /usr/share/doc/packages/drbd, or similar.

DRBD の tarball もしくはインストールされた DRBD パッケージと一緒に、たくさんコメントが書かれた設定ファイル例を見つけられるだろう。 tarball の場合 ./scripts/drbd.conf に、バイナリパッケージでインストールした場合はたいてい /usr/share/doc/drbd とか /usr/share/doc/packages/drbd とかにある。

You edit that to your needs, copy it to /etc/drbd.conf on both nodes, and check that the meta-disk points to the right location.

必要に応じてそのファイルを編集し、両方のノードに /etc/drbd.conf としてコピーし、 meta-disk が正しい場所を向いているか確認する。

DRBD allows you to either place its meta data on the same backing device where it puts the actual usable production data (internal meta data), or on a separate block device (external meta data). Before DRBD 8, the space required for DRBD meta data was fixed at 128MB, regardless of device size. Starting with DRBD 8, you may refer to this table for estimates of DRBD meta data sizes:

DRBD ではデータを格納するデバイス上にメタデータを同居させる方法(内部メタデータ)と、別のデバイスに分ける方法(外部メタデータ)のどちらかの方法でメタデータを格納出来る。 DRBD 8 以前では、DRBD メタデータに要求されるスペースはデバイスのサイズに関わらず 128MB に固定されていた。 DRBD 8 からは、DRBD メタデータのサイズは以下のテーブルから見積もることができる。

Make sure you don’t direct DRBD to write its meta data to a place where you already have existing data you still need. Also, if you are using internal meta data on an existing block device with a file system on it, make sure you shrink that file system first!

まだ必要としているデータが存在している場所に対して DRBD がメタデータを書き込まないように注意しよう。また、すでにファイルシステムを持っているブロックデバイスで内部メタデータを使用する場合は、はじめにファイルシステムを圧縮している(縮めている)ことを確認すること。

Now that we have that drbd.conf, copy it to /etc/drbd.conf on both nodes. Then, on both nodes, do a drbdadm up all. It should come up as both nodes Secondary and Inconsistent.

drbd.conf が出来たら、両方のノードに /etc/drbd.conf としてコピーする。そしたら両方のノードで drbdadm up all を実行する。両方ともセカンダリかつ不整合として起動するはず。

The latter is because the underlying storage is not yet synchronized, and DRBD has no way of knowing whether you want the initial sync from left-to-right, or right-to-left. So you have to tell it. If you have no data in the underlying block devices, it does not matter. But if you have an existing filesystem on the lower level device, and now you sync in the wrong direction, you’d need to get your latest backup ready afterwards…

なんでそうなるか。それはストレージがまだ同期されていないからで、その上 DRBD は右から左に同期すべきなのか、それとも左から右なのか、あなたが最初の同期をどちらにしたいのか知る方法がないから。なのでそれを教えてあげなければならない。もしなにもデータを持っていないブロックデバイスで構成しているのであれば、それはどうでもいいことだろう。しかしすでに構成するデバイスがファイルシステムを持っていて、仮に間違った方向に同期してしまったなら、あなたは最新のバックアップデータの準備をしなければならなくなるだろう。

You choose which node shall become Primary for the first time (the one with the good data, if you have some), then you do drbdadm — –overwrite-data-of-peer primary all. The result is a full synchronization of the underlying devices (we call this the initial full sync).

まず最初にプライマリになってほしいノード(もしデータがある状態なら条件の良いデータを持っている方)を選択する。そして drbdadm — -overwrite-data-of-peer primary all を実行する。結果としてデバイスの完全な同期がとられる(これを初期フル同期と呼ぶ)。

The device is usable right away, so if you have no file system already, you should create one now.

実行後すぐにデバイスは利用可能になる。もしファイルシステムがない状態なら作ることが出来る。

Solaris 10 で iSCSI Initiator を設定したときのメモ。

Solaris 10 で iSCSI Initiator を利用する場合、 Solaris 10 が 1/06 以降のリリースである必要があります。

以下の文書を参考にしています。

• Solaris のシステム管理 (デバイスとファイルシステム) >> 15. Solaris iSCSI イニシエータの構成 (手順)
  - http://docs.sun.com/app/docs/doc/819-0386/fmvcd?a=view

Solaris では iSCSI Initiator を設定するためのコマンドとして iscsiadm というモノが用意されています。

iSCSI Initiator が iSCSI Target を利用しようとした場合、 iSCSI Initiator はネットワーク上の iSCSI Target を何らかの方法で認識しなければならないわけですが、 iSCSI Initiator が iSCSI Target を発見するための方法として、以下の 3 つの方法が用意されています。

1. 静的デバイス発見 – iSCSI Target を静的に構成する方法
2. SendTargets による動的デバイス発見 – iSCSI Target の IP アドレスとポートの組み合わせから iSCSI Target を発見する方法
3. iSNS による動的デバイス発見 – iSNS サーバの IP アドレスとポートの組み合わせから iSCSI Target を発見する方法

ここでは SendTargets による動的デバイス発見で iSCSI Target を認識させます。

なお、前回の例で iSCSI Target として利用した Solaris Express では iSNS は利用できませんが、将来的には iSNS も実装することになっているようです。Solaris Express の iSCSI Target で iSNS が利用できるようになったら評価してみようと思っています。

まずは iSCSI Target を SendTargets の発見アドレスとして登録します。以下で 192.168.1.15 は iSCSI Target の IP アドレスで、 3260 はポート番号です。

bash-3.00# iscsiadm add discovery-address 192.168.1.15:3260

そして SendTargets を有効化します。

bash-3.00# iscsiadm modify discovery --sendtargets enable

これで 192.168.1.15 に登録された iSCSI Target が利用できるようになります。

iscsiadm コマンドで現在認識している iSCSI Target の一覧を表示することができます。

bash-3.00# iscsiadm list target
Target: iqn.1986-03.com.sun:02:5185308e-59e1-efe5-dcac-b4ce033808ba.target01
Alias: target01
TPGT: 1
ISID: 4000002a0000
Connections: 1
Target: iqn.1986-03.com.sun:02:66dbbe37-13fa-6637-c597-cf1f57b3d85c.target02
Alias: target02
TPGT: 1
ISID: 4000002a0000
Connections: 1
Target: iqn.1986-03.com.sun:02:861c6552-3a19-43b8-ccff-91ef396f98de.target03
Alias: target03
TPGT: 1
ISID: 4000002a0000
Connections: 1

試しに format コマンドを実行してみると、以下のようにデバイスが増えています。

bash-3.00# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 <DEFAULT cyl 2607 alt 2 hd 255 sec 63>
/pci@0,0/pci1000,30@10/sd@0,0
1. c2t0100000C29AE111100002A0046CD8AAFd0 <DEFAULT cyl 97 alt 2 hd 64 sec 32>
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8aaf
2. c2t0100000C29AE111100002A0046CD8C5Dd0 <DEFAULT cyl 97 alt 2 hd 64 sec 32>
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8c5d
3. c2t0100000C29AE111100002A0046CD8C5Ed0 <DEFAULT cyl 97 alt 2 hd 64 sec 32>
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8c5e
Specify disk (enter its number):

あとは普通の SCSI ディスクと同じように扱えます。

例えば上記 3 つで raidz pool を作りたければこんな感じです。

bash-3.00# zpool create tank raidz c2t0100000C29AE111100002A0046CD8AAFd0 \
> c2t0100000C29AE111100002A0046CD8C5Dd0 \
> c2t0100000C29AE111100002A0046CD8C5Ed0
bash-3.00# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME                                       STATE     READ WRITE CKSUM
tank                                       ONLINE       0     0     0
raidz1                                   ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8AAFd0  ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8C5Dd0  ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8C5Ed0  ONLINE       0     0     0
errors: No known data errors
bash-3.00# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c1t0d0s0    20093023 3593070 16299023    19%    /
/devices                   0       0       0     0%    /devices
ctfs                       0       0       0     0%    /system/contract
proc                       0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
swap                  684520     724  683796     1%    /etc/svc/volatile
objfs                      0       0       0     0%    /system/object
/usr/lib/libc/libc_hwcap1.so.1
20093023 3593070 16299023    19%    /lib/libc.so.1
fd                         0       0       0     0%    /dev/fd
swap                  683832      36  683796     1%    /tmp
swap                  683824      28  683796     1%    /var/run
tank                  144552      32  144462     1%    /tank

Solaris Express で iSCSI Target を設定したときのメモ。

将来的には Solaris 10 でも iSCSI Target の設定が出来るようになるようですが、現時点では Solaris Express でないと iSCSI Target は設定できません。

ちなみに iSCSI Initiator は Solaris 10 でも利用可能です。この Entry に続いて Solaris 10 で iSCSI Initiator を設定するためのメモを書く予定でいます。

以下の文書を参考にしています。

• OpenSolaris Project: Solaris iSCSI Target
  - http://www.opensolaris.org/os/project/iscsitgt/
• Creating your first target
  - http://www.opensolaris.org/os/project/iscsitgt/getstarted/

Solaris Express では iSCSI Target を設定するためのコマンドとして iscsitadm というモノが用意されています。

iSCSI Target Daemon を起動するために、まずは base directory を設定します。 base directory には Target と LU を構成するためのデータが格納されます。もし利用可能な ZFS pool があるようであればそこに格納した方が望ましい、と上記 “Creating your first target” には書かれていますが、ここではめんどくさいので普通に UFS 上の directory を指定します。

以下の例では /export/iscsi という directory を作成し base directory として設定しています。

bash-3.00# mkdir /export/iscsi
bash-3.00# iscsitadm modify admin -d /export/iscsi

base directory の設定が終われば Target を作成できます。

以下の例では 1GB の Target を disk01, disk02, … という名前で 5 個作成しています。

bash-3.00# iscsitadm create target --size 1g disk01
bash-3.00# iscsitadm create target --size 1g disk02
bash-3.00# iscsitadm create target --size 1g disk03
bash-3.00# iscsitadm create target --size 1g disk04
bash-3.00# iscsitadm create target --size 1g disk05

ps コマンドで確認してみると iscsitgtd という Daemon が起動していることがわかります。

bash-3.00# ps -ef | grep scsi
root   644   566   0 19:46:49 pts/1       0:00 grep scsi
root   627     1   0 19:15:12 ?           1:28 /usr/sbin/iscsitgtd

また base directory には以下のような file と directory が作成されています。

bash-3.00# ls -l /export/iscsi
total 24
-rw-------   1 root     sys         1183 Aug 20 19:15 config.xml
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk01 -> /export/iscsi/iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk02 -> /export/iscsi/iqn.1986-03.com.sun:02:66528f32-b1b9-6b0a-cfe9-c8c98f8578dc.disk02
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk03 -> /export/iscsi/iqn.1986-03.com.sun:02:fd06731d-42b9-c1c9-bf0e-e4b41ccd8d17.disk03
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk04 -> /export/iscsi/iqn.1986-03.com.sun:02:6a93da14-9ddb-4913-e502-fd4f846be66a.disk04
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk05 -> /export/iscsi/iqn.1986-03.com.sun:02:32e0173b-5155-6722-e3d1-ae1cf42a71d6.disk05
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:32e0173b-5155-6722-e3d1-ae1cf42a71d6.disk05
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:66528f32-b1b9-6b0a-cfe9-c8c98f8578dc.disk02
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:6a93da14-9ddb-4913-e502-fd4f846be66a.disk04
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:fd06731d-42b9-c1c9-bf0e-e4b41ccd8d17.disk03

config.xml の中身は次のようになっています。

<config version='1.0'>
<target>
disk01
<lun-list>
<lun>0x0</lun>
</lun-list>
<iscsi-name>
iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01
</iscsi-name>
</target>
... 以下 <target></target> が disk02, disk02 ... の分記述されている ...
</config>

disk01(実態は iqn.1986-03.com.sun… という長ったらしい名前の directory) の中身はこんな感じです。

bash-3.00# ls -l /export/iscsi/disk01/
total 2098194
-rw-------   1 root     sys      1073741824 Aug 20 19:20 lun.0
-rw-------   1 root     sys          345 Aug 20 19:20 params.0

恐らく file size から lun.0 は scsi device image だと思われます。

params.0 の中身はこんな感じで、こちらは LU の設定情報でしょう。

<params version='1.0'>
<size>0x200000</size>
<status>online</status>
<interleave>1</interleave>
<bps>512</bps>
<spt>16</spt>
<cylinders>32768</cylinders>
<heads>4</heads>
<rpm>7200</rpm>
<dtype>disk</dtype>
<vid>SUN</vid>
<pid>SOLARIS</pid>
<guid>0100000c29ae111100002a0046c969cc</guid>
</params>

disable 化されてた新しい Mac mini の VT-x オプションだけど、 Parallels の Support Forum にあった以下の方法で enable 化できました。

• How To Enable VT (aka VTX or VT-x) with rEFIt and vmx-var-set.efi
  - http://forum.parallels.com/showthread.php?t=3273

rEFIt のバージョンが違ったからか “14. In rEFIt menu, select Console.” の部分が微妙に違ってたけど、それ以外は書いてある通りに進んでいけば OK でした。

CentOS 4 と CentOS 5 の x86_64 版インストールしてみたけど、問題なく動作してるみたいです。