墜落日記 - 2010年8月16日の墜落

XenServer 5.6 上での PCI パススルーに大苦戦

物は試しと言うことで、ストレージサーバに XenServer 5.6 を導入し、PCI パススルーに挑戦してみた。

XenServer 5.6 の導入は至極順当に完了した。
SATA に接続されている SSD を sda と順当に認識して、問題なくインストールは完了。
例によって 3ware SAS 9750-8i は認識しないが、ココまで来たら慣れっこだ。
で、SSD の残り領域に Debian GNU/Linux Squeeze をインストールして、早速 PCI パススルーに挑戦してみる。

PCI パススルーは Xen 3.2 から対応しているようだが、XenServer 5.6 は Xen 3.4 ベースなので対応は出来ると思う。
ただ、Xen での PCI パススルーの情報はボチボチ見付かっても、XenServer での PCI パススルーの情報はほとんど無い。
Citrix のフォーラムで英語の方に若干のやりとりがある程度だ。
それら断片的な情報をつなぎ合わせて、手順を構築してみた。

まず lspci コマンドで 3ware SAS 9750-8i を識別する BDF を取得する。
すると「01:00.0 RAID bus controller: 3ware Inc 9750 SAS2/SATA-II RAID PCIe (rev 03)」という項目が見付かるので、ここで BDF は 01:00.0 と取得できる。
更に /etc/rc.local に以下を記述して、dom0 から 3ware SAS 9750-8i を切り離す。

BDF=0000:01:00.0
modprobe pciback
[ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
　　　echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind

ここで dom0 を再起動して、dmesg | grep pciback で起動ログを調べてみると、BDF 0000:01:00.0 が切り離されているっぽい。
lspci コマンドが吐き出すリストからは消えないのだろうか？　とか思ってみるが、消えるのが正しいのか、消えないのが正しいのか、確証無し。

さらに仮想マシンに PCI デバイスを割り当てる設定を行う。
まず xe vm-list で仮想マシンの UUID を調査する。
で、取得した UUID と BDF を元にして、以下の様にしてパラメータを設定してやる。

xe vm-param-set uuid=<UUID> other-config:pci=0/0000:01:00.0

で、以下の様に打ってパラメータを確認すると、確かに「pci: 0000:01:00.0」が追加されているのが見て取れた。

xe vm-param-list uuid=<UUID> | grep other-config

これで手筈は整ったかな？　ということで、レッツ、仮想マシン、起動っ！！

ハングアップ(爆)

lspci コマンドを叩かせても貰えず、仮想マシンはホストごとハングアップした。
最初、間抜けにも BDF を 03:00.0 と間違えてホストごとハングアップしたのだけど、その時は単純にハードウェアを探しに行って逝ってしまった様だった。
しかし BDF を正しく 01:00.0 と修正してやると、デバイス自体は見付かったがちょっかいかけようとして逝ってしまった様に見える。
同じハングアップでも、両者でタイミングが明確に違うのだ。

これは例えば dom0 から実は切り離されていなかったなど根本的に手続きが足りないのか、手順はあっていて 3ware SAS 9750-8i が PCI パススルー動作できない仕様なのか、切り分けが難しい。
手順に自分なりの明確な根拠がないから判断基準がない。
これは困ったぞ………(汗々)

ああ、あと微妙な思い付き。
これも先日の日記へのコメントでヒントを貰ったのだけど、VMware vSphere も 4.0 から VMDirectPath という名前で PCI パススルーに対応しているらしい。
ただ、VMDirectPath は感触的にはネットワークデバイスの直結を念頭にしているらしく、3ware SAS 9750-8i を直結できるか否かは微妙だ。

さて、仮に VMDirectPath が利用できるとして、どのような組み合わせが出来るだろうか？

まずストレージサーバの SSD には VMware vSphere Hypervisor を載せる。
VMware vSphere Hypervisor だけでは当然 SSD は駄々余りなので、最初のストレージを構築する。
最初のストレージに格納される仮想マシンはストレージサーバを構築する Debian GNU/Lunux Squeeze だ。

仮想マシンへ VMDirectPath で与える I/O デバイスは何にするか？
当然、3ware SAS 9750-8i は与える必要があるし、これは直接認識しなければ 3DM2 で管理も出来ない。
あとは 4 系統ある eth のうち、2 系統を VMDirectPath で与えてしまおうか？
そうすると eth×2 のボンディングを構成できるので、外部の仮想ホストへのストレージ提供の帯域を確保できる。
ストレージサーバ内部の仮想ホストへのストレージは仮想 NIC 同士が仮想スイッチを介して直接やりとりすれば良いかな？
仮想スイッチと繋がるだけの内部ネットワークだと物理 NIC と繋げる必要もないだろう。

で、万が一ここまで上手く行ってしまったとしたら、XenServer の時と同様に鶏と卵のような関係になるストレージサーバ内部のストレージを VMware vSphere Hypervisor がちゃんと使えるか？　という部分が問題になる。
VMware vSphere Hypervisor が起動した段階ではまだ最初の仮想マシンは上がっていないので、当然最初の仮想マシンが提供するネットワークストレージは存在しない。
最初の仮想マシンを起動してネットワークストレージが有効になってから、後続の仮想マシンを起動できるように遅延起動を設定したりも必要だし、そもそも VMware vSphere Hypervisor 起動時では認識不能なネットワークストレージを自動的に切り離したりしはしないか？　という疑問も解消せねばならない。

XenServer での PCI パススルーが成功すれば全ての仮想マシンを XenCenter で管理できる利便性を得られるのだけど、ストレージサーバのみが VMware vSphere Client で、その他の仮想ホストの管理は XenCenter と使い分けるのも致し方ないかな？

う～ん、疲れてきた………(汗々)