後日、問題が発覚したのでこちらを参照下さい(2016年8月追記)
Skylake機でLinuxを動かすにはkernel4系を使う必要がある。PX-Q3PEを利用するには必然的にKVMにデバイスパススルーするくらいの方法しかない。kernel4系でもデバイスパススルーが問題なく使えるかどうかを試してみる。前回、CentOS7.2をベースにkernel4.6を導入して無事Skylake機を起動させる事ができた。ただし、2回ほど不可解なネットワーク障害(OSからNICが見えなくなる)があった。いずれも再起動ですぐに直ったが詳細は未調査。ちょうどこの頃にkernel4.7がリリースされたので、試しにインストールしてみたが、残念ながら起動中にエラってしまった。このリリースはネットワーク周りの改善もあるらしいので、また時間のあるときに挑戦してみたい。
さて、まずはデバイスパススルーだが、カーネルパラメータに『intel_iommu=on』の設定を加えて再起動。
vi /etc/default/grub
:
GRUB_CMDLINE_LINUX="intel_iommu=on crashkernel=auto rhgb quiet"
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
virt-installでCentOS6.7の仮想サーバを構築するが、PX-Q3PEとスマートカードリーダーのSCR3310v2.0をパススルーするオプションを加える。この辺もsh67h3で設定した時の繰り返し。
lspci
:
06:00.0 Multimedia video controller: Device 188b:5220 (rev 01)
lsusb
:
Bus 002 Device 003: ID 0bda:0161 Realtek Semiconductor Corp. Mass Storage Device
virt-install \
--name rec1 \
--hvm \
--virt-type kvm \
--ram 2048 \
--vcpus 2 \
--arch x86_64 \
--os-type linux \
--os-variant rhel6 \
--boot hd \
--disk path=/var/lib/libvirt/images/rec1.img,size=20,device=disk,bus=virtio,format=raw \
--network bridge=br0,model=virtio \
--graphics none \
--serial pty \
--console pty \
--host-device 06:00.0 \
--host-device 002.003 \
--location http://home.domain.local/repo/6/os/ \
--extra-args "ks=http://home.domain.local/ks/rec1.cfg console=ttyS0,115200"
新製品 Shuttle SH170R8 新デザイン！アルミ製シャーシ採用 キューブ型ベアボーン
|
問題なく仮想サーバは構築できて、どちらのデバイスもアクセス可能だった。デバイスパススルーは問題なさそうなので、ついでにQSVをパススルーするCentOS7.1を作ってみようとしたが、virt-installの起動中にホストOSごとハングした。。。現時点ではQSVのパススルーは難しそう。どうせIntel Media Server Studioが対応していないので、パススルー出来たところで動かせないんだけどね。QSVがダメだったのでホストOS側でNVENCを動かしてみる。
GD750-2GERTSPを動かすにはまずNVIDIAのドライバが必要だ。これもsh67h3機で作った時と同じ流れだと考えていたのだが、ドライバのインストール時にnouveauドライバ外せと怒られた。sh67h3の時はlsmodで見えてるままインストール出来たんだけど。/etc/modprobe.dに勝手に設定入れてくれるので、インストール・ウィザードが終わったら再起動する。起動後に確認するとやっぱりnouveauドライバは入ったまま。今度はカーネルパラメータで『nouveau.modeset=0』を明示して再起動してみる。
cd /usr/local/src
wget http://jp.download.nvidia.com/XFree86/Linux-x86_64/367.35/NVIDIA-Linux-x86_64-367.35.run
chmod 755 NVIDIA-Linux-x86_64-367.35.run
./NVIDIA-Linux-x86_64-367.35.run
reboot
:
lsmod | grep nouveau
vi /etc/default/grub
:
GRUB_CMDLINE_LINUX="nouveau.modeset=0 intel_iommu=on crashkernel=auto rhgb quiet"
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot
|
新製品 Shuttle SH170R8 新デザイン!アルミ製シャーシ採用 キューブ型ベアボーン by Yahoo! ショッピング |
しかし、これでもnouveauドライバはlsmodで見えてしまう。釈然としないまま、NVIDIA-Linux-x86_64-367.35.runをもう1度実行すると、今度はインストールできてしまった。まあ、いいや。次にffmpegをインストールする。以前にNVENCを追加した3.0系のffmpegをrpmbuildしてある。とりあえずこれをそのままインストールして試すと問題なく動作した。処理時間はちょっと長くなったような気もするが誤差の範囲。Skylake機でも問題なく録画サーバとして使えそうだ。
その後は2回ほど落ちたネットワーク障害も再発する事なく稼動している。とはいえ、気になることはもう幾つかあり、1つは仮想サーバの待機時CPU使用率が高い事。高いとは言ってもtopで見て30%前後なんだけど、通常のKVMではこんなに食わない。絞り込んでいくとUSB機器、つまりSCR3310v2.0のパススルーを外したところでCPUが落ち着いた。USBをパススルーするだけでCPUを食ってしまうようだ。USBに関してはパススルーでなくてUSBデバイスサーバみたいな形で渡した方がコスト低いのかな。言うほど高負荷という訳ではないんだけど、待機電力量にも関わるから抑えられるなら抑えておきたい。
もう1つはrecpt1の録画処理がたまにハングしてしまうこと。発生するのはBSの録画や番組表更新など。ハングしたプロセスが持つデバイスは使えなくなるし、該当プロセスをkillするとOSごとフリーズするし、かなりイマイチ。ここでいうrecpt1はgithubにあったソースからコンパイルしたものなので、とりあえずfoltiaのrecpt1に入れ替えたら安定。両者の違いはhttpdパッチの有無なので、ライブ視聴しない限りはこのままでもいいのかな。やりたくなったら別名のrecpt1を作って、ライブ視聴だけそちらを参照するようにすればいい。地上波であれば問題ないだろうし。
※この方法だと番組表の更新が出来なくなってしまった。BSの問題を何とかしないと。。。
最初に作ったsh67h3機なんて運用に入る前に退役した訳なんだけど、去年くらいから構想し始めて、やっとまともな運用に入れそうｗ 仮想サーバのCentOS6.7にepgrecをインストールして、幾つかテスト用の録画予約を入れた。数ヶ月くらいの試用期間を無事こなせたら本格運用開始かな。エンコードとCMスキップの自動化やクライアント側の準備など、残課題はまだまだあるけど。ま、その前に開発機として2台目を作るのでお楽しみにｗ