VMware DirectPath I/Oでビデオカードを使ってみました - その2

少し前に、“VMware DirectPath I/Oでビデオカードを使ってみました - AIDEMOIRE”でVMwareのDirectPath I/Oを使って仮想ゲストから物理ビデオカードへ直接出力する実験を試みました。結局は殆どのOSでは上手く行かず、辛うじてKali Linuxという特殊な（？）Linuxだけが出力できた、という内容でした。

その後、ESXiサーバからビデオカードは撤去して、別のデスクトップPCに付けて（仮想マシンではなく）物理マシンとして2画面出力の実験などをしてました。（“物理PCでのRadeon HD 6450の設定奮闘記 - AIDEMOIRE”）

ところが、その後、ESXiをiSCSIブートできるようにしたので（“ESXi 5をソフトiSCSIでブート - AIDEMOIRE”）こちらのマシンでもDirectPath I/Oの実験ができるようになりました。しかも、ESXiハイパーバイザは最新の5.5に上がりました。（“チープなRealtekでESXi 5.5を使う方法 - AIDEMOIRE”）

そこで試していたら、幾つか新しいことが分かったので情報を更新しておきます。

Kaliのドライバは不完全でした

改めて振り返ると以前の実験でもそうだったのですが、DirectPath I/Oでビデオ出力に成功した時の fglrxドライバは不完全なものでした。その時点では、“Linux 3.7系でfglrxのカーネルドライバがコンパイルできない！ - AIDEMOIRE”という問題に気づかずに試していました。

今回は、この問題が分かっていたのでパッチの有り無しで試してみましたが、

パッチを当てず不完全な状態で実行 ⇒ 成功
パッチを当てて完全な状態で実行 ⇒ 失敗！！

となりました。

なんと、カーネルモジュールを組み込まない状態では出力に成功するのですが、パッチを当ててカーネルモジュールを組み込んだ状態では出力できないという結果になってしまいました。Kali LinuxでDirectPath I/Oが使えたと言うのは“本当に”偶然だったようです。

なお、パッチを当てる前の状態での Xorg.0.logの抜粋を載せておきます。

[     6.479] (EE) fglrx(0): atiddxDriScreenInit failed, GPS not been initialized.
[     6.479] (WW) fglrx(0): ***********************************************************
[     6.479] (WW) fglrx(0): * DRI initialization failed                               *
[     6.479] (WW) fglrx(0): * kernel module (fglrx.ko) may be missing or incompatible *
[     6.479] (WW) fglrx(0): * 2D and 3D acceleration disabled                         *
[     6.479] (WW) fglrx(0): ***********************************************************
[     6.482] (II) fglrx(0): FBADPhys: 0xf00000000 FBMappedSize: 0x10000000
[     6.485] (II) fglrx(0): FBMM initialized for area (0,0)-(1920,8191)
[     6.485] (II) fglrx(0): FBMM auto alloc for area (0,0)-(1920,1920) (front color buffer - assumption)
[     6.485] (II) fglrx(0): Largest offscreen area available: 1920 x 6271
[     6.487] (==) fglrx(0): Backing store disabled
[     6.487] (II) Loading extension FGLRXEXTENSION
[     6.487] (**) fglrx(0): DPMS enabled
[     6.487] (II) fglrx(0): Initialized in-driver Xinerama extension
[     6.487] (WW) fglrx(0): Textured Video not supported without DRI enabled.
[     6.487] (II) LoadModule: "glesx"
[     6.487] (II) Loading /usr/lib/xorg/modules/glesx.so
[     6.559] (II) Module glesx: vendor="X.Org Foundation"
[     6.559]    compiled for 1.4.99.906, module version = 1.0.0
[     6.559] (II) Loading extension GLESX
[     6.559] (II) fglrx(0): GLESX enableFlags = 576
[     6.562] (II) LoadModule: "amdxmm"
[     6.562] (II) Loading /usr/lib/xorg/modules/amdxmm.so
[     6.569] (II) Module amdxmm: vendor="X.Org Foundation"
[     6.569]    compiled for 1.4.99.906, module version = 2.0.0
[     6.569] (EE) fglrx(0): XMM failed to open CMMQS connection.(EE) fglrx(0):
[     6.569] (EE) fglrx(0): XMM failed to initialize
[     6.569] (WW) fglrx(0): No XV video playback available
[     6.569] (II) fglrx(0): Enable composite support successfully
[     6.569] (WW) fglrx(0): Option "VendorName" is not used
[     6.569] (WW) fglrx(0): Option "ModelName" is not used
[     6.569] (==) fglrx(0): Silken mouse enabled
[     6.569] (==) fglrx(0): Using HW cursor of display infrastructure!
[     6.570] (II) fglrx(0): Disabling in-server RandR and enabling in-driver RandR 1.2.
[     6.668] (--) RandR disabled

ログを見ると（当たり前ですが）カーネル・ドライバが見当たない、と言っています。そこでXウィンドウの起動を諦めるかと思いきや、カーネル・モジュールを使わずに初期化を行い起動しています。

Intel VT-dは必要なのか？？

今回、実験で使ったPCのMOBOは ASUS P8H77-M LEというボードです。このボードのチップセットは名前の通り“H77”で、このチップセットでは VT-dをサポートしていないのです。インテルのホームページ ARK | Intel® H77 Express Chipset (Intel® BD82H77 PCH) でもVT-dに関しては“NO”となっています。また、BIOSでもVT-dをONにする設定項目は有りません。

しかし、（不完全なドライバとは言え）Kali Linuxで DirectPath I/O が使えたのは事実です。

で、ちょっと調べてみるとIntelのホームページにこんなのがありました。デスクトップ・ボード — インテル® バーチャライゼーション・テクノロジー (インテル® VT) とデスクトップ・ボードの互換性
このページによるとVT（VT-x/i）は“ハイパーバイザがI/OデバイスをゲストOSに一意に割り当てることができる”機能を提供し、VT-dは“ハイパーバイザにパフォーマンス、セキュリティー、柔軟性の向上を実現”を実現するそうです。つまり、VT-xがあればVT-dが無くてもI/Oの割り当ては可能だが、VT-dがあればパフォーマンスが向上する、と読めます。

確かESXiはVT-xの機能が使えない場合は、ソフトウェアエミュレーションによって仮想化を実現しているようですから、I/Oに関してもVT-dが使えない場合は、ソフトウェアエミュレーションによってI/Oの割り当てを行っている、とも想像できます。

それで、改めてVMwareのドキュメントを確認してみました。最新の5.5での記述は次のようになっています。vSphere 5.5 Documentation Center （*1）　これによると条件として、Intel VT-dもしくはAMD IOMMUがBIOSで設定できること、とありますが....。

でも、VT-dの無いチップセットやBIOSで設定項目の無いPCでも“実際に”利用できているし。一方でVT-dサポートのPCでも DirectPath I/O は満足に動かないし。う～ん。

参考のためにKaliでビデオカード出力が成功したハードウェア構成を書いておきます。

ビデオカード

SAPPHIRE HD6450 1G DDR3 PCI-E HDMI/DVI-D/VGA

Mobo

ASRock Q77M vPro （Q77：VT-d有り、BIOS：VT-d設定可）

　　　　　CPU: Intel Core i7 3770 （VT-d機能付き）

ASUS P8H77-M LE （H77：VT-d無し、BIOS：VT-d設定無し）

　　　　　CPU: Intel Core i7 3770 （VT-d機能付き）

iGPは使えるのでしょうか？

PCIカードのGPUは一応は使えるとして、MOBOに搭載のGPU、iGPはDirect Path I/Oで使えるのでしょうか？ちょっと実験してみました。
CPUはCore i7 3770で、チップセットはH77なのでiGPは Intel HD 4000 になります。vShpere Clientの構成画面でもiGPをDirectPath I/Oの対象とすることは可能です。そこでiGPをDirectPath I/Oに指定してESXiを再起動します。すると、上半分が黄色いブート画面の途中で画面がフリーズします。これはiGPがDirectPath I/Oの対象になっているために、DirectPath I/Oの機能がONになった時点でESXiがそれ以上出力できなくなるためと思われてます。ESXiの起動が完了したら、とりあえずKali LinuxのゲストにiGPを割り当てて/etc/xorg.confでiGPを使う様に設定してからゲストを再起動すると、上半分の黄色い画面が消えて真っ黒になります。モニタには“No Signal”のサインが出ています。とうやら、ゲストマシンがiGPを握ったのですが、初期化が上手くできてないようです。なお、VMwareの仮想ビデオの方も真っ黒です。ダルマさんになってしまいました。仕方ないのでsshで入ってログを確かめると、確かに Intelドライバが起動して、途中まで頑張って初期化していのですが、どうも上手くいかずにモニタに出力できないようです。しかし、Xウィンドウは立ち上がっています。xrandrコマンドで調べると、ビデオデバイスとしては認識しているのですが、それに接続されているモニタが見当たらないようです。（実際にはHDMIでモニタにつながっています。）

root@kali:~# xrandr -d :0
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
root@kali:~#

Xorg.0.logを見ると次の様なメッセージが残っていました。

[    15.376] (II) intel(0): Output VGA1 using monitor section Monitor0
[    15.408] (II) intel(0): EDID for output VGA1
[    15.408] (II) intel(0): Output VGA1 disconnected
[    15.408] (WW) intel(0): No outputs definitely connected, trying again...
[    15.408] (II) intel(0): Output VGA1 disconnected
[    15.408] (WW) intel(0): Unable to find connected outputs - setting 1024x768 initial framebuffer

惜しいところまで来ているのですが。

更に実機のVideo BIOSから吸い出したものをESXiのVideo BIOSとして使ってみることも試してみましたが、これもNGでした。この過程で分かったことメモっておきます。ゲストのvmxファイルに次の行を追加することでVideo BIOSを変更できます。

vbios.filename = "ASUS-P8H77-MEL_vbios.rom"

と言った感じです。ところがESXiのログに次のようなメッセージが出力されます。

2013-10-08T11:17:44.881Z| vmx| I120: [msg.loader.biossz3] BIOS ASUS-P8H77-MEL_vbios.rom has unexpected file size 0xe400.

実機から抜き取ったVBIOSのサイズは56KBだったのですが、これは大きすぎる！と怒られます。無理やり32KBでカットするとメッセージは出力されないので、どうもESXiでの外部Video BIOSの読込は32KBまでのようです。

仕方ないので、外部BIOSとしてではなく、ESXiのBOISのvbiosセクションを抜き抱いたvbiosイメージと置き換えてやってみましたが、これも効果なしでした。（もっとも、実機のBIOSと仮想ハードウェアの構成は同じではないので、入れ替えたところで効果ができる可能性は少ないと思ったのですが、まぁ、遊びでやってみました。ちなみに、“vbios.filename”による外部VBIOSの読込ではゲスト自身がブートしなくなりました。ESXiのBIOSの入れ替えではゲストはブートしましたが、VMware仮想ビデオカードしかもたないゲストは、（当たり前ですが）画面が乱れる状態でした。）

参考URL

実機からのVideo BIOSの抜き取り方：VGA support - coreboot
外部VBIOSの指定方法：[LinuxBIOS] LinuxBIOS, VMWare & CMOS
ESXiのBIOSイメージの入れ替え方：Esxi 4.1.0 slic bios modify. | Neo-Blog

ここまで来ると半分、意地ですね。なんか惜しいところまで来ているような気がするのですが。

単体操作のためにはまだ足りません

さて、ESXiマシンのビデオカードにゲストのデスクトップが出力できたとしても、単体で操作するためには、まだ足りません。そう、マウスとキーボードをゲストで使えなければなりません。でないと、画面はESXiマシンのモニタを見ながら、キーボードとマウスの操作は別のマシンのvSphere Clinetから、と間抜けなことになってしまいます。

実践派の私としては、これも試してみました。

ESXiのUSBのゲストへの割り当てに関して、キーボードとマウスは対象外です。USBメモリなどはゲストにPass Throughできるのですが、キーボードとマウスはできません。ESXi起動時のキーボードとマウスとは別にキーボード、マウスを追加してもダメでした。

しかし、USBのルートハブはビデオカードと同様に DirectPath I/O でゲストに割り当てることができます。USBのルートハブをDirectPath I/Oの対象としてESXiを起動すると、（ビデオカードと同様に）キーボード・マウスからESXiを操作することが出来なくなります。しかし（ビデオカードと同様に）ゲストで認識することはできませんでした。
Webで調べると、これは成功例の記事があちこちにあります。（例えば、TinkerTry IT @ home | How to configure ESXi 5.0 for USB 3.0 passthrough to a Windows VM とか）　上手く行っているという例はWindowsゲストが多いようでLinuxゲストの例は見当たりません。もっとも、キーボード、マウスに関してはもう少しHackすれば、何とかなるかも知れませんが。

なお、（先ほどのビデオ出力だけ DirectPath I/O出来ても間抜けなことになるのと同様に）キーボード・マウスだけゲストにDirectPath I/Oできても、これまた間抜けな様な気がします。ビデオ、キーボード、マウスの3点セットでパススルーできないと実用的ではありません。

さらに言えば、パススルーする先はLinuxではなくWindowsである必要がります。何故かVMwareのGUI管理フレームワークはWindowsプラットフォームに限られているからです。

何か進展があれば、またメモっておきますが、まぁ、DirectPath I/Oの件については、この辺りで一旦ヤメとします。

*1:5.1とドキュメントの構成が結構変わっていて、vSphere Clientの項目は“ホスト単体管理”というカテゴリに移されていました。旧来の管理のカテゴリではvSphere Web Clientの記述だけが残っています。vSphere ClientはVMware Serverと同じ運命をたどりそうです。