KVM一覧

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

PT2で実験中

PX-W3PEで仮想マシン内録画でさんざんな結果でしたが、
PT2ではどうなんだろうとおもってテストしてみました。
今までの環境構築テストで、録画自体はスクランブル解除なしでうまくいっていたというところまで確認は出来ていました。

結果

PT2の場合は、CPU使用率は低く抑えられた。
ピークで20%も使わないくらい。
W録画時にもこのような状況で、パケットのドロップは発生しなかった。

こういう状況なので、この仮想マシンにBCASカードリーダーを接続させ、
スクランブル解除までやらせてみた。
その結果もまた優秀でW録画時かつデコードありで、
CPU使用率は相変わらず低いままであった。

まとめるとPT2のほうが機器として良くできているということじゃないかと思う。
仮想マシンで録画ということを考えると、PT2は使える!ということになると思う。


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

途中報告

確かにFedora14の環境下でKVM(0.13)を使うと、
デバイスパススルーの機能を用いて仮想マシン内で録画を行うことが出来た。

  • PT2
  • PX-W3PE

上記の2ボードで試してみたが、どちらでもひとまず録画が出来ることが確認できた。
すばらしい・・・。

ただ現時点では安定動作出来るかどうかは確認できていない

実験中1 (PX-W3PE)

PX-W3PEのほうが情報が少ないので、ネットに晒してみます。
どうも仮想マシン内で録画の際にCPU使用率が高い。
シングル録画時で30~50%ほど。W録画中では75~80%ほど。

しかもこれはスクランブルのデコードをしない状態でである。

スクランブルのデコードをした場合にはまず確実にドロップが発生する。

一応PX-W3PEのドライバ設定で、レジストリを変更しています。
・自動ゲインコントロール(ブースタ)
・内部ブースターの値は適当に0x0aあたり

このような状況のため、このボードの仮想マシン内録画は
デコードなし、シングル録画限定、
という制限を設けて使うのが精一杯かもしれない。

BonCasLink

別環境に用意したBCasLinkServiceに接続して、デコード処理をやらせる感じにしたらブルースクリーンが出たり、ドロップ多発したり色々発生した。

現時点の状態では、使用しない方が賢明。

W録画

どうにも安定して長時間録画できない。
シングル録画のみの使用に限定した方がいいかも。


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だからというメリットもそんなになかったみたいですね

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


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までのチェックは出来そうです。