録画サーバ構築 Skylake+CentOS 検証編

後日、問題が発覚したのでこちらを参照下さい(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"

問題なく仮想サーバは構築できて、どちらのデバイスもアクセス可能だった。デバイスパススルーは問題なさそうなので、ついでに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 新デザイン!アルミ製シャーシ採用 キューブ型ベアボーン
価格 : 35,620円(税込、送料無料)
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機なんて運用に入る前に退役した訳なんだけど、去年くらいから構想し始めて、やっとまともな運用に入れそうw 仮想サーバのCentOS6.7にepgrecをインストールして、幾つかテスト用の録画予約を入れた。数ヶ月くらいの試用期間を無事こなせたら本格運用開始かな。エンコードとCMスキップの自動化やクライアント側の準備など、残課題はまだまだあるけど。ま、その前に開発機として2台目を作るのでお楽しみにw

後日、問題が発覚したのでこちらを参照下さい(2016年8月追記)

コメントを残す

メールアドレスが公開されることはありません。

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)