Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

4,177 views

Published on

OSC名古屋 2017のopenSUSEユーザ会のセミナーにて使用したスライドです
最後に1ページだけおまけを追記

Published in: Technology
  • Be the first to comment

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

  1. 1. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 1/54 openSUSE で最強仮想化環境を作ろう - ゲーミングから仮想通貨まで - 安藤 達也 日本 openSUSE ユーザ会
  2. 2. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 2/54 お前どこ中誰よ? ● 安藤 達也 – @zgock999,@zgock999@mstdn.maud.io ● openSUSE との出会い – 2003年ぐらいに自分のPemtium-MノートのWifiを認識してくれ る唯一のディストリということで落ち着く – Xenに強かったディストリということもあり、 2012年ぐらいから家の擬似VDIサーバで活躍してもらっている ● openSUSE12.3~Leap42.2まで随時更新中 ● このへん詳しくはSlideShareの 「Xenとzfsで作る家庭内VDIサーバ」シリーズ参照 – 35000ビューぐらい行ってて驚いた
  3. 3. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 3/54 みなさん って何かご存知ですか?
  4. 4. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 4/54 正しいのはどれ? ● 1. サーバールームでモフモフできるカメレオン型ガジェット ● 2. 緑色のロゴが目印の謎のAI半導体メーカー ● 3. 昨年、20周年のドイツ生まれの Linux ディストリビュー ション
  5. 5. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 5/54 正解 ● 3. 昨年、20周年のドイツ生まれの Linux ディストリビューション – S.u.S.E Linux 4.2 で独自のディストリビューションになってから ● Q: RedHat 系ですか? Debian 系ですか? A: どちらでもありません! – RPM じゃないとダメとか deb じゃないとダメとか、 そういう話もよく聞きます(なぜ? ● Q: OpenSUSE ですか?openSUSE ですか? A: o は小文字です。IPhone ではなく、iPhone なのと同じです
  6. 6. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 6/54 今日の内容 ● 今回の発端 ● 仮想化技術最後の壁、GPU仮想化 ● GPUパススルーとは? ● openSUSEでGPUパススルーなKVM環境を作ろう ● 主要デスクトップGPU別傾向と対策 ● 組んでみて良かったこととか ● 展示ブースデモ機の解説 ● 質疑応答とか
  7. 7. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 7/54 今回の発端(よくある御家庭内のお話) ● 上の子が中学に上がった – 嫁「上の子ちゃん、プログラムとか授業でやるんだってねえ?   そろそろ上の子ちゃんにもパソコン一台用意したげて」 z「あ、そうだね、んじゃ早速もう一台・・・」 嫁「んな金あるわけないだろが(^”^)」 z「まあないよね、うん。んじゃどうすべ?」 嫁「パパ一杯パソコン持ってるんだから一台上の子行きね?   あ、もちろん一番性能いいやつ引渡しね(^^)」 ● お仕事端末一台取られますた
  8. 8. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 8/54 複数ワークステーションを使うお仕事 ● これまで基本3台のPCを仕事用で使っていた – zgockの本職は画像処理とかCGとか ● 最近はopenCLを使う機会も増えてきた – openCVが下層でopenCL呼んでる – 道楽でゲーム開発も – 動作検証のため別OS/別GPU環境で作ったプログラムをテストし たり – Intel HD onboard/NVIDIA Geforce/AMD RADEONの三種類は 最低でもテスト ● 一台減らされると検証環境的にちょっと困る
  9. 9. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 9/54 そうだ、統合しよう ● いっそ作業環境全部統合して一台にしてしまえ – 3つのVM一台で動かせばそれはそれでメリットあるやろ ● (実際にどんなメリット出たかは後述) ● 手っ取り早く統合するならXenかなあ・・・ – 既に家族用のPCはXenで擬似VDI化してる ● 待てよ?最近のカーネルとqemuならKVMでもIntel IGD仮想 化できたよね? – Kernel 4.8とqemu2.7以降の組み合わせで Intel IGDの仮想化対 応がなされた(Xenより4~5年遅れ) ● いっちょKVMでやるか!面白そうだしな!
  10. 10. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 10/54 仮想化技術最後の壁、GPU ● 最近はGPUの活躍の場が増えてきた – ゲーミング – 仮想通貨採掘(openCL/CUDA) – 画像処理etc.(openCL/CUDA) – ディープラーニングとかでも使ってるらしい(専門外だけど) ● 謎のAI半導体メーカ、 一体何VIDIAなんだ・・・
  11. 11. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 11/54 仮想化技術最後の壁、GPU ● qemu/VMWare/VirtualBox等でさまざまなデバイスの仮想 化が進んだ – ネットワークやブロックデバイス等は採用技術次第ではネイティ ブと遜色ないレベルに ● GPUは複雑なデバイスであるため単純なソフトウェアによる 仮想化ではパフォーマンスや機能に限界があった – 最もパフォーマンスが出るとされているVMWare WorkStation の仮想VGAでも実GPUには遠く及ばない
  12. 12. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 12/54 GPU仮想化のための方法論(1) ● 演算対応の完全仮想GPUの実装 – VMWare VGAとかqemuのvirtio-gpuとか – これまでのアプローチの発展系で3Dアクセ ラレーションやGPU演算対応版仮想デバイス – ゲストからは既存のGPUとは非互換な抽象化 された新設計GPUに見える
  13. 13. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 13/54 GPU仮想化のための方法論(1) ● 演算対応の完全仮想GPUの実装 – 長所 ● 一個のGPUを複数のゲストで共有できる ● 従来の思想を踏襲しているので運用レベルでの 変化は少ない
  14. 14. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 14/54 GPU仮想化のための方法論(1) ● 演算対応の完全仮想GPUの実装 – 短所 ● 環境側で専用ドライバを用意せねばならず、実 装に手間取りがち – virtio-gpuのwindows driverはまだ未完成 ● 今年のgoogle Summer Code対象で今年の終わりぐらいに登場? ● パフォーマンス的にも苦しい – virtio-gpuのLinuxドライバで実gpuの10%ぐらい
  15. 15. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 15/54 GPU仮想化のための方法論(2) ● 実物理GPUの準仮想化エミュレーションGPU – IntelのXenGTとかKVMGTとか(intel GVT-g) – GPUネイティブをバックエンドで呼び出す準仮想化 – ゲストからは実GPUのように見える
  16. 16. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 16/54 GPU仮想化のための方法論(2) ● 実物理GPUの準仮想化エミュレーションGPU – 長所 ● 一個のGPUを複数のゲストで共有できる ● ドライバは実GPUのドライバで良い ● 完全仮想化型よりは高パフォーマンス – XenGTで実GPUの70%ぐらいらしい
  17. 17. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 17/54 GPU仮想化のための方法論(2) ● 実物理GPUの準仮想化エミュレーションGPU – 短所 ● 新しい実装であるためまだ未成熟 – Kernel 4.10で実装されたばかりであり、まだまだ不安定 ● しばらくすると画面が崩れて異常終了当たり前 ● Intel以外の専業GPU屋さんは実装に消極的 ● 比較的新しいiGPU(Haswell世代以降)必須 ● しかもSkylake以降はまだ未対応 ● 有限なリソース、ホストのVRAMが大量に必要 – VRAMを共有できるわけではないのでゲストの数だけVRAMを分 割することになる – iGPUが4GB以上のVRAM扱えるようになってからが本番?
  18. 18. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 18/54 GPU仮想化のための方法論(3) ● 実GPUのゲストへの直接割り当て – いわゆるGPUパススルー – NICやHBA等のPCI/PCIe機器を割り当てる PCIパススルー技術の応用 – ゲストからは実GPUそのものに見える(当たり前)
  19. 19. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 19/54 GPU仮想化のための方法論(3) ● 実GPUのゲストへの直接割り当て 長所 ● 技術的には結構枯れた技術 – Xenの世界では相当前から実用レベル – KVMは対応が遅れ気味だったが、ここ2~3年ぐらいで急 速に対応が進んだ ● ずっと超えられない壁だったIntel iGPUもKernel4.8とqemu2.7か ら対応 ● パフォーマンスは最も期待できる – 数%前後のロスぐらい
  20. 20. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 20/54 GPU仮想化のための方法論(3) ● 実GPUのゲストへの直接割り当て 短所 ● ホスト側に仮想IOのハード支援機構(IOMMU)が必要 – Intelだとcore-i5以上/xeonなら最近のは大概付いてる ● K付きデスクトップだと付いてないのがあるので注意 – マザーボードも時々対応してないのがある ● ASRockなら大概大丈夫 – AMD系は最近のなら大概大丈夫 – ノートPCだと対応してる方が稀なので注意が必要 ● ゲスト一台につき一個のGPUが (原則として)必要 – SR-IOV、NVIDIA vGPUとかのゲスト間共有のためのハードウェア支援機構もあるにはある ● とても個人レベルで買える代物ではない ● KVMにおいては、まだ未成熟なところがある – 使いこなそうとすると、まだまだPatched Kernelが必要なシチュエーションが
  21. 21. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 21/54 ● 個人レベルでの現実解としては GPUパススルーが最も現実的 – WS一台に複数GPUを積んで、それぞれをゲストに – せいぜい集約できて3~4台だが、そもそもGPUが 必要なレベルのパフォーマンス要求するゲストであ れば、コア数の問題もあってそのくらいが現実的
  22. 22. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 22/54 そういうわけで GPUパススルーします openSUSEで!
  23. 23. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 23/54 実は仮想化は結構得意なopenSUSE ● 仮想化ホストとしては老舗なSUSE/openSUSE – Xen主流の時代から仮想化には力を入れている – 基本的な設定程度はYastで一発 – 仮想化関係のカーネル調整も上手 ● ローリングリリースなTumbleweedがある – 最低でもKernel4.8以上とqemu2.7以上が必要だが、ロー リングリリースなTumbleweedならばっちり対応済 ● Snapperでシビアな作業も安心して進められる – カーネル設定やカーネルパッチなど、失敗したらブート不 可になるような作業でも一発で元に戻せる
  24. 24. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 24/54 openSUSE Tumbleweed ● ローリング・リリース – 週に3回程度新しいバージョンがリリース ● 常に最新バージョンのカーネルやアプリケーション、 ライブラリを使いたい人向け – アプリケーション開発時に、新しいコンパイラやライブラリでも 動くかをいち早く確認できる
  25. 25. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 25/54 Snapperでいつでも巻き戻し ● Snapperって何? – btrfsのスナップショット機能を応用したシステム復元ツール – Windowsの「システム復元」と似たようなものと言えなくもない が、btrfsのスナップショットを使用するので保存も復元も一瞬 – Yast、zypper等の主要コマンドを実行した時点で自動的にス ナップショットが作られる ● カーネル弄るようなシビアな作業で真価を発揮 – ふぇぇ・・・設定をしくじってブート不可になったよぉ・・・ ● ブートローダーから「過去のスナップショットで起動」を選んで失 敗する前の状態でブートする ● 「Snapper rollback」とコマンドを叩けばすっかり元通り
  26. 26. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 26/54 GPUパススルーな KVM環境の構築
  27. 27. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 27/54 まずはインストールから ● Tumbleweedはネットワークインストール推奨 – ftp.riken.jpが日本で現状唯一のTumbleweedミラー ● http://ftp.riken.jp/Linux/opensuse/tumbleweed/repo/oss ● UEFIブートは避けた方が良い – FAT32なEFIパーティションはsnapperでロールバックできない ので、snapper活用するならrootfsは全面btrfsが良い – homeの分割はお好みで ● 一旦は普通のデスクトップでインストール – 最終的にはテキストモードでブートすることになるが、管理ツー ル等に必要なライブラリを確実に入れる意味で一旦はこう
  28. 28. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 28/54 基本設定はYastで一発 ● qemu入れて~libvirt入れて~、daemon有効にして~、ブ リッジ設定して~ – 他のディストリだったらありがちな光景 「Yast>仮想化>ハイパーバイザのインストール」 「KVMサーバ」を選択して実行するだけで GPU仮想化使わない普通のKVM環境なら ネットワーク設定込みで一発で終わります
  29. 29. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 29/54 ホストがGPUを掴まないようにする ● ランレベルをテキストモードに変更する – 「Yast>サービスマネージャ>ランレベル」 ● 「マルチユーザ」を選択する ● ブートローダーがGPUを使わないようにする – 「Yast>ブートローダ」 ● 「グラフィカルブート」をOFFに ● ブートパラメータに「nomodeset」を追加 ● Yastいちいち使うの?コマンドラインでええやん? – Snapperの復元ポイントの記録のためです
  30. 30. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 30/54 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
  31. 31. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 31/54 管理ドライバを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やらあれこれ動くのでしばらく待つ
  32. 32. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 32/54 パススルーしたいデバイス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と一体になっている場合が 多いのでまとめて対象にしておくこと ●
  33. 33. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 33/54 これで動くと 思うじゃろ?
  34. 34. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 34/54 もうちょっとだけ 続くんじゃ
  35. 35. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 35/54 GPU別 傾向と対策
  36. 36. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 36/54 GPU別傾向まとめ ● ○:特に何も設定せずに動く ● ▲:カーネルパッチとカーネル設定が必要 ● △:libvirt XMLの編集もしくはqemuオプションが別途必要 ● ×:動かない Linux BIOS Windows BIOS Linux UEFI Windows UEFI Intel HD Graphics ○ ▲ × × AMD RADEON × △ ○ ○ NVIDIA Geforce × × △ △
  37. 37. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 37/54 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
  38. 38. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 38/54 AMD RADEONの場合(1) ● UEFIではわりとあっさり動くが、特定GPUではシャットダウ ンに失敗する – UEFIファームにバグを抱えているチップ世代がある ● RADEON R9/R7 3xx世代に多い
  39. 39. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 39/54 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>
  40. 40. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 40/54 NVIDIA Geforceの場合(1) ● BIOS起動では基本的には動かない – BIOS ROMに仮想環境では起動しないガードがかかっている ● Quadroを買ってねということらしい ● BIOS書き換えやチップ抵抗張替えでQuadro化すればワンチャン ● UEFI起動では一見素直に動くがnvidiaドライバはエラーで動かない – noveauドライバなLinuxで良ければ普通に動く – UEFI環境ではファームでガードがかけられなくなったらしく ドライバーでガードをかけるようになったらしい – エラーコードが43であることから「code 43 hell」と言われる
  41. 41. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 41/54 NVIDIA Geforceの場合(2) ● BIOS起動では基本的には動かない – BIOS ROMに仮想環境では起動しないガードがかかっている ● Quadroを買ってねということらしい ● BIOS書き換えやチップ抵抗張替えでQuadro化すればワンチャン ● UEFI起動では一見素直に動くがnvidiaドライバはエラーで動かない – noveauドライバなLinuxで良ければ普通に動く – UEFI環境ではファームでガードがかけられなくなったらしく ドライバーでガードをかけるようになったらしい – エラーコードが43であることから「code 43 hell」と言われる
  42. 42. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 42/54 NVIDIA Geforceの場合(3) ● Code 43対策でKVMで動いていることをゲストに隠蔽する – WindowsゲストではKVMであることを隠蔽しても特に問題は出ない – LinuxゲストではKVMであることを検知してカーネルが最適化処理を行 えなくなるのでパフォーマンスに若干の影響が出る(誤差レベル) ● qemuの場合、”-kvm=off”を付与する ● libvirtの場合<feature>...</feature>の間に以下を入れる <kvm> <hidden state='on'/> </kvm>
  43. 43. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 43/54 これで動くと 思うじゃろ?
  44. 44. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 44/54 すまんが もう一つだけ あるんじゃ
  45. 45. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 45/54 複数dGPUを動かす場合の注意点 ● LGA115x系CPUでdGPUを二つ以上使う場合は制限がある – 本来、PCIeレーンが16しかないLGA115x系CPUには単純設計で あればPCIex16なdGPUは一つしか乗らない – 実際のマザーではCPUの管轄外になる外部チップでPCIeレーンを分割して2つ 以上のdGPUが乗るようになっている – KVMでは外部チップの制御ができないためPCIeレーンの分割認識ができず、そ のままでは分割されたPCIeレーン一式を一つのゲストにしか割り当てられない ● dGPUを二枚以上さしても別々のゲストに当てられない – 対策としてカーネルパッチが必要 ● Patched Kernelでブートパラメータに以下を与える pcie_acs_override=downstream – メモリ空間に同時にマップされた別デバイスを保護無しでゲスト間に共 有させているだけなのでかなり危険。利用は自己責任で
  46. 46. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 46/54 結構苦労したけど 実際組んでみて よかったこと
  47. 47. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 47/54 よかった探し(1) ● Xenより概してパフォーマンスは良い – Xenはセキュリティとか安全性/安定性に倒している – 個人でワークステーション集約ならKVMで十分 – パブリッククラウド的に使わないならという前提 ● ACS Overrideとか知らないゲスト間同士で共有とか危 険すぎる – ディープにKVM周りのソース追うとパフォーマンスと安全性ではパ フォーマンスに倒している思想だということが追える ● Xen/KVM/コンテナは適材適所で
  48. 48. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 48/54 よかった探し(2) ● ストレージ的にはかなり幸せになった – btrfsとかzfsとかのCoW対応ファイルシステムがWindows 環境に対しても(ディスク丸ごとレベルではあるが)使え るようになったので環境複製とかが一瞬でできるように なった – 環境のロールバックも一瞬 – ゲスト間のファイル転送がホスト内で完結するのでLAN大 域を圧迫しなくなった
  49. 49. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 49/54 よかった探し(3) ● 予想以上に電気代は減った – GPUx1なPC3台とGPUx3なPC1台では結果として200Wほ どの節約になった – かつてはほぼ24時間3台を動かしていたので、結果とし て月に2000円以上の節約になった – だからと言って 小遣いは増えないけど!
  50. 50. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 50/54 展示ブースの デモ機紹介
  51. 51. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 51/54 展示ブースのデモ機構成 ● 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
  52. 52. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 52/54 質疑応答とか
  53. 53. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 53/54 ありがとう ございました!
  54. 54. 2017/05/27openSUSEで最強仮想環境を作ろう #oscnagoya 54/54 おまけ ● 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 ● 今後の追記とかもたぶんここに

×