openSUSEで最強仮想環境をつくろう - ゲーミングから仮想通貨まで - OSC名古屋2017セミナー資料

2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 1/54
openSUSE で最強仮想化環境を作ろう
- ゲーミングから仮想通貨まで -
安藤　達也
日本 openSUSE ユーザ会

お前どこ中誰よ？
● 安藤　達也
– @zgock999,@zgock999@mstdn.maud.io
● openSUSE との出会い
– 2003年ぐらいに自分のPemtium-MノートのWifiを認識してくれ
る唯一のディストリということで落ち着く
– Xenに強かったディストリということもあり、
2012年ぐらいから家の擬似VDIサーバで活躍してもらっている
●
openSUSE12.3～Leap42.2まで随時更新中
●
このへん詳しくはSlideShareの
「Xenとzfsで作る家庭内VDIサーバ」シリーズ参照
– 35000ビューぐらい行ってて驚いた

みなさん
って何かご存知ですか？

正しいのはどれ？
● 1. サーバールームでモフモフできるカメレオン型ガジェット
● 2. 緑色のロゴが目印の謎のAI半導体メーカー
● 3. 昨年、20周年のドイツ生まれの Linux ディストリビュー
ション

正解
● 3. 昨年、20周年のドイツ生まれの Linux ディストリビューション
– S.u.S.E Linux 4.2 で独自のディストリビューションになってから
● Q: RedHat 系ですか？ Debian 系ですか？
A: どちらでもありません！
– RPM じゃないとダメとか deb じゃないとダメとか、
そういう話もよく聞きます（なぜ？
● Q: OpenSUSE ですか？openSUSE ですか？
A: o は小文字です。IPhone ではなく、iPhone なのと同じです

今日の内容
● 今回の発端
● 仮想化技術最後の壁、GPU仮想化
● GPUパススルーとは？
● openSUSEでGPUパススルーなKVM環境を作ろう
● 主要デスクトップGPU別傾向と対策
● 組んでみて良かったこととか
● 展示ブースデモ機の解説
● 質疑応答とか

今回の発端(よくある御家庭内のお話)
● 上の子が中学に上がった
– 嫁「上の子ちゃん、プログラムとか授業でやるんだってねえ？
　　そろそろ上の子ちゃんにもパソコン一台用意したげて」
z「あ、そうだね、んじゃ早速もう一台・・・」
嫁「んな金あるわけないだろが(^”^)」
z「まあないよね、うん。んじゃどうすべ？」
嫁「パパ一杯パソコン持ってるんだから一台上の子行きね？
　　あ、もちろん一番性能いいやつ引渡しね(^^)」
● お仕事端末一台取られますた

複数ワークステーションを使うお仕事
● これまで基本３台のPCを仕事用で使っていた
– zgockの本職は画像処理とかCGとか
●
最近はopenCLを使う機会も増えてきた
– openCVが下層でopenCL呼んでる
– 道楽でゲーム開発も
– 動作検証のため別OS/別GPU環境で作ったプログラムをテストし
たり
– Intel HD onboard/NVIDIA Geforce/AMD RADEONの三種類は
最低でもテスト
● 一台減らされると検証環境的にちょっと困る

そうだ、統合しよう
● いっそ作業環境全部統合して一台にしてしまえ
– ３つのVM一台で動かせばそれはそれでメリットあるやろ
●
(実際にどんなメリット出たかは後述)
● 手っ取り早く統合するならXenかなあ・・・
– 既に家族用のPCはXenで擬似VDI化してる
● 待てよ？最近のカーネルとqemuならKVMでもIntel IGD仮想
化できたよね？
– Kernel 4.8とqemu2.7以降の組み合わせで Intel IGDの仮想化対
応がなされた（Xenより４～５年遅れ）
●
いっちょKVMでやるか！面白そうだしな！

仮想化技術最後の壁、ＧＰＵ
● 最近はGPUの活躍の場が増えてきた
– ゲーミング
– 仮想通貨採掘(openCL/CUDA)
– 画像処理etc.(openCL/CUDA)
– ディープラーニングとかでも使ってるらしい(専門外だけど)
●
謎のAI半導体メーカ、
一体何VIDIAなんだ・・・

仮想化技術最後の壁、ＧＰＵ
● qemu/VMWare/VirtualBox等でさまざまなデバイスの仮想
化が進んだ
– ネットワークやブロックデバイス等は採用技術次第ではネイティ
ブと遜色ないレベルに
● GPUは複雑なデバイスであるため単純なソフトウェアによる
仮想化ではパフォーマンスや機能に限界があった
– 最もパフォーマンスが出るとされているVMWare WorkStation
の仮想VGAでも実GPUには遠く及ばない

ＧＰＵ仮想化のための方法論(1)
● 演算対応の完全仮想GPUの実装
– VMWare VGAとかqemuのvirtio-gpuとか
– これまでのアプローチの発展系で3Dアクセ
ラレーションやGPU演算対応版仮想デバイス
– ゲストからは既存のGPUとは非互換な抽象化
された新設計GPUに見える

– 長所
●
一個のGPUを複数のゲストで共有できる
●
従来の思想を踏襲しているので運用レベルでの
変化は少ない

– 短所
●
環境側で専用ドライバを用意せねばならず、実
装に手間取りがち
– virtio-gpuのwindows driverはまだ未完成
●
今年のgoogle Summer Code対象で今年の終わりぐらいに登場？
●
パフォーマンス的にも苦しい
– virtio-gpuのLinuxドライバで実gpuの10%ぐらい

● 実物理GPUの準仮想化エミュレーションGPU
– IntelのXenGTとかKVMGTとか(intel GVT-g)
– GPUネイティブをバックエンドで呼び出す準仮想化
– ゲストからは実GPUのように見える

– 長所
●
一個のGPUを複数のゲストで共有できる
●
ドライバは実GPUのドライバで良い
●
完全仮想化型よりは高パフォーマンス
– XenGTで実GPUの70%ぐらいらしい

– 短所
●
新しい実装であるためまだ未成熟
– Kernel 4.10で実装されたばかりであり、まだまだ不安定
●
しばらくすると画面が崩れて異常終了当たり前
●
Intel以外の専業GPU屋さんは実装に消極的
●
比較的新しいiGPU(Haswell世代以降）必須
●
しかもSkylake以降はまだ未対応
●
有限なリソース、ホストのVRAMが大量に必要
– VRAMを共有できるわけではないのでゲストの数だけVRAMを分
割することになる
– iGPUが4GB以上のVRAM扱えるようになってからが本番？

● 実GPUのゲストへの直接割り当て
– いわゆるGPUパススルー
– NICやHBA等のPCI/PCIe機器を割り当てる
PCIパススルー技術の応用
– ゲストからは実GPUそのものに見える（当たり前）

長所
●
技術的には結構枯れた技術
– Xenの世界では相当前から実用レベル
– KVMは対応が遅れ気味だったが、ここ２～３年ぐらいで急
速に対応が進んだ
●
ずっと超えられない壁だったIntel iGPUもKernel4.8とqemu2.7か
ら対応
●
パフォーマンスは最も期待できる
– 数%前後のロスぐらい

短所
●
ホスト側に仮想IOのハード支援機構(IOMMU)が必要
– Intelだとcore-i5以上/xeonなら最近のは大概付いてる
●
K付きデスクトップだと付いてないのがあるので注意
– マザーボードも時々対応してないのがある
●
ASRockなら大概大丈夫
– AMD系は最近のなら大概大丈夫
– ノートＰＣだと対応してる方が稀なので注意が必要
●
ゲスト一台につき一個のGPUが
（原則として）必要
– SR-IOV、NVIDIA vGPUとかのゲスト間共有のためのハードウェア支援機構もあるにはある
●
とても個人レベルで買える代物ではない
●
KVMにおいては、まだ未成熟なところがある
– 使いこなそうとすると、まだまだPatched Kernelが必要なシチュエーションが

● 個人レベルでの現実解としては
GPUパススルーが最も現実的
– WS一台に複数GPUを積んで、それぞれをゲストに
– せいぜい集約できて３～４台だが、そもそもGPUが
必要なレベルのパフォーマンス要求するゲストであ
れば、コア数の問題もあってそのくらいが現実的

そういうわけで
GPUパススルーします
openSUSEで！

実は仮想化は結構得意なopenSUSE
● 仮想化ホストとしては老舗なSUSE/openSUSE
– Xen主流の時代から仮想化には力を入れている
– 基本的な設定程度はYastで一発
– 仮想化関係のカーネル調整も上手
● ローリングリリースなTumbleweedがある
– 最低でもKernel4.8以上とqemu2.7以上が必要だが、ロー
リングリリースなTumbleweedならばっちり対応済
● Snapperでシビアな作業も安心して進められる
– カーネル設定やカーネルパッチなど、失敗したらブート不
可になるような作業でも一発で元に戻せる

openSUSE Tumbleweed
● ローリング・リリース
– 週に3回程度新しいバージョンがリリース
● 常に最新バージョンのカーネルやアプリケーション、
ライブラリを使いたい人向け
– アプリケーション開発時に、新しいコンパイラやライブラリでも
動くかをいち早く確認できる

Snapperでいつでも巻き戻し
● Snapperって何？
– btrfsのスナップショット機能を応用したシステム復元ツール
– Windowsの「システム復元」と似たようなものと言えなくもない
が、btrfsのスナップショットを使用するので保存も復元も一瞬
– Yast、zypper等の主要コマンドを実行した時点で自動的にス
ナップショットが作られる
● カーネル弄るようなシビアな作業で真価を発揮
– ふぇぇ・・・設定をしくじってブート不可になったよぉ・・・
●
ブートローダーから「過去のスナップショットで起動」を選んで失
敗する前の状態でブートする
●
「Snapper rollback」とコマンドを叩けばすっかり元通り

ＧＰＵパススルーな
KVM環境の構築

まずはインストールから
● Tumbleweedはネットワークインストール推奨
– ftp.riken.jpが日本で現状唯一のTumbleweedミラー
●
http://ftp.riken.jp/Linux/opensuse/tumbleweed/repo/oss
● UEFIブートは避けた方が良い
– FAT32なEFIパーティションはsnapperでロールバックできない
ので、snapper活用するならrootfsは全面btrfsが良い
– homeの分割はお好みで
● 一旦は普通のデスクトップでインストール
– 最終的にはテキストモードでブートすることになるが、管理ツー
ル等に必要なライブラリを確実に入れる意味で一旦はこう

基本設定はYastで一発
● qemu入れて～libvirt入れて～、daemon有効にして～、ブ
リッジ設定して～
– 他のディストリだったらありがちな光景
「Yast＞仮想化＞ハイパーバイザのインストール」
「KVMサーバ」を選択して実行するだけで
GPU仮想化使わない普通のKVM環境なら
ネットワーク設定込みで一発で終わります

ホストがGPUを掴まないようにする
● ランレベルをテキストモードに変更する
– 「Yast＞サービスマネージャ＞ランレベル」
●
「マルチユーザ」を選択する
● ブートローダーがGPUを使わないようにする
– 「Yast＞ブートローダ」
●
「グラフィカルブート」をOFFに
●
ブートパラメータに「nomodeset」を追加
● Yastいちいち使うの？コマンドラインでええやん？
– Snapperの復元ポイントの記録のためです

IOMMU機能を有効にする
● マザーボードのbiosでIOMMU機能をONにする
– Intelであれば「vt-d」
– AMDであれば「AMD-Vi」
● ブートパラメータでIOMMUをONにする
– 「Yast＞ブートローダ」
●
ブートパラメータに「intel_iommu=on」を追加
– AMDであれば「amd_iommu=on」
● 有効になったか確認する
– 「dmesg | grep DMAR」
●
これでDMAR関連のメッセージがずらずらっと出て、「iommu
enabled」と言っていればOK

管理ドライバをinitramfsへ
● initramfsの組み込み方法はディストリでいろいろ方言がある
– 不慣れな時期、ぐぐった他ディストリの方法を強行してハマるのは通過
儀礼
● /etc/sysconfig/kernelに組み込みたいドライバを列挙する
– vi /etc/sysconfig/kernel
●
INITRD_MODULES=”pci_stub vfio vfio_iommu_type1 vfio_pci
vfio_virqfd kvm kvm_intel”
– AMDの場合はkvm_intelをkvm_amdに
– pci_stubはレガシーな管理ドライバだけど、GPU以外のパスス
ルーではまだ使う時があるのでまあついでに
● 「mkinitrd」を実行
– dracuitやらあれこれ動くのでしばらく待つ

パススルーしたいデバイスIDの指定
● vfioドライバにパススルー対象のデバイスIDを伝える
– lspciで対象デバイスのバス番号を確認
– lspci -nで対象デバイスのIDを確認
– 「/etc/modprobe.d」以下にドライバオプションの記述ファイ
ルを置く
●
vi /etc/modprobe.d/99-mygpu.conf ←ファイル名は自由
– options vfio-pci ids=xxxx:xxxx,yyyy:yyyy,zzzz:zzzz
●
xxxx:xxxxはlspciで調べたID
●
最近のdGPUはHDMI AUDIOと一体になっている場合が
多いのでまとめて対象にしておくこと
●

これで動くと
思うじゃろ？

もうちょっとだけ
続くんじゃ

GPU別
傾向と対策

GPU別傾向まとめ
● ○：特に何も設定せずに動く
● ▲：カーネルパッチとカーネル設定が必要
● △：libvirt XMLの編集もしくはqemuオプションが別途必要
● ×：動かない
Linux
BIOS
Windows
BIOS
Linux
UEFI
Windows
UEFI
Intel HD Graphics ○ ▲ × ×
AMD RADEON × △ ○ ○
NVIDIA Geforce × × △ △

Intel HD Graphicsの場合
● サポート対象はIvy Bridge～Broadwell
– Skylake以降はまだ対応していない
● UEFIブートは対応していない
– qemuがまだ未対応
● windowsゲストはそのままだとドライバ読むとBSOD
– Intelのwindowsドライバが高度なCPU機能呼びまくり
●
KVMが未対応の命令を使おうとする（KVMが例外返す）
●
KVMがデフォで禁止してる割り込みモードを使う
– 未対応命令が来てもKVMが例外を吐かなくするカーネルパッチを当てる
– KVMがunsafeと判断する割り込みを許可する
●
vi /etc/modprobe.conf.d/99-kvm.conf
– options kvm allow_unsafe_assigned_interrupts=1 ignore_msrs=1
halt_poll_ns=0

AMD RADEONの場合(1)
● UEFIではわりとあっさり動くが、特定GPUではシャットダウ
ンに失敗する
– UEFIファームにバグを抱えているチップ世代がある
●
RADEON R9/R7 3xx世代に多い

AMD RADEONの場合(2)
● BIOS起動する場合、qemuに特別なオプションを付与する必要がある
– 対象デバイスにqemuオプションのx-vga=onを付与する必要がある
●
libvirtではデフォルトのnamespaceでは付与できないオプション
●
libvirtのdomainタグにqemuのxmlnsを指定してqemuコマンドラインを
xmlに追記できるようにする
– <domain type='kvm' xmlns:qemu='
http://libvirt.org/schemas/domain/qemu/1.0'’>
●
xml末尾にqemu:commandlineタグでオプション指定する
<qemu:commandline>
<qemu:arg value='-set'/>
<qemu:arg value='device.hostdev0.x-vga=on'/>
</qemu:commandline>
</domain>

NVIDIA Geforceの場合(1)
● BIOS起動では基本的には動かない
– BIOS ROMに仮想環境では起動しないガードがかかっている
●
Quadroを買ってねということらしい
●
BIOS書き換えやチップ抵抗張替えでQuadro化すればワンチャン
● UEFI起動では一見素直に動くがnvidiaドライバはエラーで動かない
– noveauドライバなLinuxで良ければ普通に動く
– UEFI環境ではファームでガードがかけられなくなったらしく
ドライバーでガードをかけるようになったらしい
– エラーコードが43であることから「code 43 hell」と言われる

● BIOS起動では基本的には動かない
– BIOS ROMに仮想環境では起動しないガードがかかっている
●
Quadroを買ってねということらしい
●
BIOS書き換えやチップ抵抗張替えでQuadro化すればワンチャン
● UEFI起動では一見素直に動くがnvidiaドライバはエラーで動かない
– noveauドライバなLinuxで良ければ普通に動く
– UEFI環境ではファームでガードがかけられなくなったらしく
ドライバーでガードをかけるようになったらしい
– エラーコードが43であることから「code 43 hell」と言われる

● Code 43対策でKVMで動いていることをゲストに隠蔽する
– WindowsゲストではKVMであることを隠蔽しても特に問題は出ない
– LinuxゲストではKVMであることを検知してカーネルが最適化処理を行
えなくなるのでパフォーマンスに若干の影響が出る（誤差レベル）
●
qemuの場合、”-kvm=off”を付与する
●
libvirtの場合<feature>...</feature>の間に以下を入れる
<kvm>
<hidden state='on'/>
</kvm>

これで動くと
思うじゃろ？

すまんが
もう一つだけ
あるんじゃ

複数dGPUを動かす場合の注意点
● LGA115x系CPUでdGPUを二つ以上使う場合は制限がある
– 本来、PCIeレーンが16しかないLGA115x系CPUには単純設計で
あればPCIex16なdGPUは一つしか乗らない
– 実際のマザーではCPUの管轄外になる外部チップでPCIeレーンを分割して２つ
以上のdGPUが乗るようになっている
– KVMでは外部チップの制御ができないためPCIeレーンの分割認識ができず、そ
のままでは分割されたPCIeレーン一式を一つのゲストにしか割り当てられない
●
dGPUを二枚以上さしても別々のゲストに当てられない
– 対策としてカーネルパッチが必要
●
Patched Kernelでブートパラメータに以下を与える
pcie_acs_override=downstream
– メモリ空間に同時にマップされた別デバイスを保護無しでゲスト間に共
有させているだけなのでかなり危険。利用は自己責任で

結構苦労したけど
実際組んでみて
よかったこと

よかった探し(1)
● Xenより概してパフォーマンスは良い
– Xenはセキュリティとか安全性/安定性に倒している
– 個人でワークステーション集約ならKVMで十分
– パブリッククラウド的に使わないならという前提
●
ACS Overrideとか知らないゲスト間同士で共有とか危
険すぎる
– ディープにKVM周りのソース追うとパフォーマンスと安全性ではパ
フォーマンスに倒している思想だということが追える
● Xen/KVM/コンテナは適材適所で

● ストレージ的にはかなり幸せになった
– btrfsとかzfsとかのCoW対応ファイルシステムがWindows
環境に対しても（ディスク丸ごとレベルではあるが）使え
るようになったので環境複製とかが一瞬でできるように
なった
– 環境のロールバックも一瞬
– ゲスト間のファイル転送がホスト内で完結するのでLAN大
域を圧迫しなくなった

● 予想以上に電気代は減った
– GPUx1なPC３台とGPUx3なPC1台では結果として200Wほ
どの節約になった
– かつてはほぼ２４時間３台を動かしていたので、結果とし
て月に２０００円以上の節約になった
– だからと言って
小遣いは増えないけど！

展示ブースの
デモ機紹介

展示ブースのデモ機構成
● CPU：Intel Xeon E3 1245v2
– Core i7 3770相当(IvyBridge)
● Memory: 32GB DDR3
● SSD: 128GB
● GPU: x3
– Intel HD 4000P (with openSUSE Tumbleweed)
– AMD RADEON HD7750 (with Windows10)
– NVIDIA Geforce GTX750Ti(with Ubuntu 17.04)
● Power Sup:750w ATX

質疑応答とか

ありがとう
ございました！

おまけ
● Patched Kernel配布とか
– https://build.opensuse.org/project/show/home:zgock:kv
m-vfio
●
デモ機で使ってたPatched Kernelはこちらに
●
patches.vfio.tar.bz2がパッチ群なので他のディストリで
使いたい方はここから抽出を
●
おまけのおまけでこのカーネル用のzfs/spl(0.7.0rc4)も置
いてあります
● ネタ帳
– https://gist.github.com/zgock999/1c991ef2c74e6119d
b01fbc4faf7d25e
●
今後の追記とかもたぶんここに

openSUSEで最強仮想環境をつくろう - ゲーミングから仮想通貨まで - OSC名古屋2017セミナー資料

More Related Content

What's hot

Similar to openSUSEで最強仮想環境をつくろう - ゲーミングから仮想通貨まで - OSC名古屋2017セミナー資料

Recently uploaded

openSUSEで最強仮想環境をつくろう - ゲーミングから仮想通貨まで - OSC名古屋2017セミナー資料