「 2011年05月 」一覧

KVMでデバイスパススルー その2


どうもネットを検索すると、KVMでデバイスパススルーを設定し、
仮想環境(ゲストOS)で録画出来ている、なんていう記事を見かけます。手元の環境では、録画できているけど常用できない、という状態なので、
他の人のうまくいっている環境は常用できるという点に着目して、
真偽を確かめてみたいなと思います。

うまくいく環境とは?

うまくいっている人の多くは、Fedoraを使用している。
CentOSでの報告もあるけど、Fedoraが多い傾向にある。

また、GUIでの設定で終わりという記載はあまりみない。
できた~という人はGUIで設定して終わっているようだが、きちんと記事にしている人は、コマンドラインでKVMのゲストを起動しているようにみえる。

デバイスはPT2を使用している。
他のPT1やPX-W3PEでうまくいっているという話を見ない・・・。
入手性の問題なのだろうか。あるいは、うまく動作するのがこれだけなのか。

調査方針

うまく行く率が高いFedoraをインストールしてみる。
KVMはOSインストール時には入れずに、後から導入する感じで。

デバイスパススルーできるKVMにもうまくいくバージョンがありそうなので。


KVMでデバイスパススルー その1


KVMでデバイスパススルー

Scientific Linux 6を用いて、KVMによる仮想マシンを試してみました。
さすがRHEL6クローンなだけあって、KVM関連のツールが充実していました。

Fedora14のときと比較してGoodだったのは以下の点

  • 物理デバイスのパススルー設定がGUI(仮想マシンマネージャ)から設定できる
  • 初期状態でもWindowsXPインストール時に強制再起動しない

というわけで、仮想マシンを設定してデバイスのパススルー設定までは案外楽に出来ました。
以前は、GUIから設定できずqemu-kvmコマンドの引数設定で行う必要がありました。

今回デバイスパススルーするボードは、PX-W3PEです。
このデバイスは、仮想マシンマネージャから名称が表示されませんでした。
lspciコマンドで、割り当ての番号を確認して、それが一応列挙されていることを確認した上で、GUIから割り当てを行いました。一覧表示されるけど、名称が空欄だったので。

このデバイスの設定の前に、仮想マシンには以下の手順を施してあります。

  • ゲストOSをインストールし、一通りのデバイス認識は完了させている
  • virtioドライバを使用できるようにしている
    • ネットワークと仮想ディスク

virtioを適用していないと、まず確実に受信データをDROPしてしまいました。

これらを行った後で、PX-W3PE関連のインストールを行いました。
試しに使ったのは、EpgDataCap_Bonです。

しかしながらかろうじて動作はするものの、数秒間に1回はDROPしてしまうという状況で、普段問題なく使用できるか、というとそうではなさそうです。

追記(5/29)

どうやらFedora14でも、Physical Host Deviceとしてデバイスパススルーを設定できるらしいです。
特に、ScientificLinuxだからというメリットもそんなになかったみたいですね

安定性だけ、若干優位かな??


Fedora15出た(しかし実験失敗)


Fedora14の環境をインストールしているうちに、Fedora15が出てしまいました。
やりたいことであるSPICEの部分も、仮想マシンマネージャから設定できるようになったとのことで、Fedora15のほうをインストールすることに変更してみました。

・・・

しかしながら、インストールして仮想マシンマネージャから仮想マシンを作ろうとしたら、エラーが発生。
どうもハードディスクか設定ファイルか書き込みに失敗するのか、仮想マシンそのものを作れず。
今のところGUIからはダメそうな感じでした。

ちなみにFedora14の初期状態では仮想マシン作成後、WinXPのインストール時のハードディスクフォーマット時で強制終了してしまう感じに。
ただ、qemu-kvmのアップデートを適用したらこれは無事に正常に進行するようになりました。

ただ、Fedoraの安定性の悪さは気になりますね・・・
仮想マシンを束ねる環境としては不安。

そんな中、見つけてきたのがこれ。
“Scientific Linux”

どうやらCentOSと同様のものらしいです。研究所向き。
調べてみるとRedhatLinux6相当にはなっているみたいだし、
CentOS6が未だに出ていない状況から考えると、こちらのほうも視野に入れて実験してみるのが良さそうです。
少なくとも、Fedoraよりは安心して使えそう(メンテ期間はながそうだし)


Fedora14のインストールで足止め(2)


1TBのディスクだったので1日半ほどかけて、

のコマンドを実行。
その結果、ようやくインストール時にハードディスクを見つけてくれました。
『BIOS RAIDメタデータ』の呪縛から逃れられた感じです。

これでやってみたいことのためにFedora14のインストールを続行できる♪


Fedora14のインストールで足止め


Fedora14のDVD ISOファイルをダウンロードして
いざインストールしようとしたら、ディスクが見つからなくて立ち往生。

“BIOS RAID メタデータが含まれていますが、認識された BIOS RAID セットの一部ではありません。”

とエラーが表示されてしまう。

とりあえず、全パーティション削除したのち、ddコマンドでゼロウメを行った後で、再チャレンジ予定。

これでうまくいかなかったらどうしようか(涙


KVMを触ってみる


CentOS 5.6を入れて、KVMを試してみようとがんばっていましたが、
色々と目的の動きをしてくれなくて苦戦しました。結局のところ、やってみたいことが

  • SPICE(リモートデスクトップ、VNCの代替)
  • デバイスパススルーの確認

ということだったので、割と難易度は高めの物でした。

はまった点 その1

起動時にvt-dをenableにした状態では延々と再起動を繰り返し、
システム起動完了にならなかったこと。

解決するためには、起動時のカーネルパラメータに
intel_iommu=on を追加する必要がありました。
追加するために、一度vt-dをdisableにして起動させて、エディットしました。
grubのメニューでエディットする方法もありだと思います。

その2

“-vga qxl”のパラメータを解釈してくれない。
この時点でCentOS 5.6付属のKVMではダメみたい。

よって、実験的で魅力的な機能を備えているFedora14をチャレンジしてみることにしようかと思います。

また、Fedora14でのこれらの情報は、Software Design5月号で掲載されていましたし、
まずはそれをトレースすることでSPICEまでのチェックは出来そうです。


ESXiから仮想HDDをコンパクトに取り出す


ESXiから仮想マシンを取り出したときの仮想ディスクに対する実験です。
vSphere Clientを使ってのデータストアからの取り出しやVeeam Backupを使ってのコピーでは、仮想ディスクは指定した全容量を占めるようになってしまいます。
これをThinディスク(シンディスク)としてコンパクトにする方法を調べてみました。

まずは自分がやった作業手順を説明し、最後に無駄のない方法としてまとめてみます。

対象仮想マシンの環境

今回対象とするのはコマンドラインしか存在しないシンプルなCentOSがインストールされた状態のものです。
デフォルトでインストールされているので、LVMによるパーティション割り当てが行われています。

また使用状態が長く続いたため、仮想ハードディスクも容量ぎりぎりまで使った形跡有りです。なお現時点では余計なデータは削除されているため使用容量は全体の10%程度に収まっているという状況です。

仮想マシンがWindows環境というものならば、VMware Toolsでディスクのシュリンクが出来るため今回説明するような手順は不要だと思われます。

作業手順

  1. ESXi内にある仮想マシンをvCenter Converterを用いてWindows環境に取り出す
  2. VMware Workstationで取り出した仮想マシンを起動
  3. 起動後、空き領域をゼロで埋める
  4. ゼロで埋めた後、仮想マシンをシャットダウンする
  5. 仮想マシンを再度vCenter Converterを用いて変換する

最後に変換した仮想マシンに含まれる仮想ハードディスクのファイルが見事、使用サイズ分程度に小さくなることを確認できました。

必要なのはおそらく仮想ハードディスクの空き領域をゼロで埋めることです。
これをESXiの中に位置するときに適用しておけば、上記の手順をいくらか省くことが出来そうです。

なお、ゼロ埋めするのには以下のコマンドで行いました。

まとめ

  1. ESXi内にある処理対象の仮想マシンで、空き領域をゼロで埋める
  2. ESXi内の処理対象の仮想マシンをシャットダウンする
  3. 取り出し先(Windows側)で、VMware vCenter Converterを起動し、対象の仮想マシンを変換する
    1. このとき、仮想ハードディスクの種類が”事前割当なし”になっているか確認しておくといいかも。

変換後、仮想ハードディスクが使用容量分程度しかサイズを消費していないことを確認してみてください。

もしうまくいかないようであれば、仕方ないですが一度取り出して、地道にやってみるしかないのかもしれません。

おまけ

ESXiのデフォルトが事前割当有りのシックディスクであり、
そのため単純な取り出しでは全容量喰ってしまうのでは?という意見がありました。


Windows7SP1とVMwareWorkstation7


Windows7 Professional with SP1の環境で、VMware Workstation7を使うようになったら、仮想マシンの電源をONにしたときにエラーメッセージが表示されるようになった。

「仮想マシンがメモリの予約できません。再試行 (R) を選択し問題が解決しない場合は、まず使用していないプログラムを終了して、メモリを解放してください」

十分なメモリもある状況でこのメッセージが表示されるので、不思議に思っていたのですが、そういえばVMware Workstation7のほうがWindows7 SP1に正式対応をしていないことを思い出したので、アップデートを確認。
すると、SP1に対応した物が既に公開されていました。

これをインストールしたところ、今回の問題は解決しました。(ver 7.1.4に更新)

この情報はKnowledgeBaseにも掲載されているようで、既知の問題だったようです。

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1036185

同様の問題が VMwarePlayerのほうでも起こるらしいので、SP1適用済み環境の場合には更新しておくべきですね。


DirectX11とDirectX9比較


DirectX11(D3D11)はDirectX9ハードウェア上でも動きます。
そういう場合に、DirectX11とDirectX9ではどちらを選択すべきだろうか、と思ってちょっと比較をしてみようかと思います。

チェック環境

  • RADEON HD 5450(DX11対応ハード)
  • Geforce9600GT
  • Geforce6800GT

サンプルプログラムとしてBasicHLSL11というSDK付属の物を使います。
これを実行してFPSの計測を行います。

チェックしてみる項目は以下の通り

  • D3D11デバイスでD3D_FEATURE_LEVEL_11_0
  • D3D11デバイスでD3D_FEATURE_LEVEL_10_0
  • D3D11デバイスでD3D_FEATURE_LEVEL_9_3
  • D3D9デバイス

結果

それぞれの場合でFPSを計測すると以下のようになりました。
(解像度は800×600)

条件 FPS値(5450) FPS値(9800GT) FPS値(GF6800)
D3D11+D3D_FEATURE_LEVEL_11_0 1170
D3D11+D3D_FEATURE_LEVEL_10_0 3625
D3D11+D3D_FEATURE_LEVEL_9_3 1220 4183 1604
D3D9 965 1367 1201

D3D9 vs D3D11では、圧倒的にD3D11の方が高速に動作しているようです。
そして貧弱なハードウェアだからか、レベルを落とした方が若干高速でした。
この結果を見ると、DX9とDX11(9_3レベル)を悩むならDX11のほうがよいと言えます。