統合GPUをVMとホストコンテナ間で共有できますか？

場合によっては可能です。完全なPCIパススルーでは、VMに統合GPU全体が割り当てられるため、通常はホスト上のコンテナがアクセスできなくなります。共有には、mediated device、特定の旧世代プラットフォームでのIntel GVT-g、または対応する新しいプラットフォームでのSR-IOV仮想機能に対するハードウェアとドライバーのサポートが必要です。

コンテナからのアクセスは別のレイヤーです。コンテナは通常、ホストのカーネルを共有し、`/dev/dri/renderD128`などのレンダーデバイスを使用します。VMには、そのホストデバイスノードではなく、仮想化されたGPU機能またはmediated deviceが必要です。この違いによって、安全な構成、検証方法、ロールバックの基準点が決まります。

プラットフォームがサポートする仮想化モードを特定する

まず、正確なCPU世代、iGPUのPCI ID、ファームウェア、ホストカーネル、ドライバーを確認します。あるIntel世代向けのガイドが別の世代にも適用できるとは限らず、共有方法によっては廃止されていたり、ツリー外モジュールが必要だったりします。

完全なパススルーのみがサポートされている場合は、アクセラレーションの利用先をVMまたはホストのどちらか一方に決めます。ホストドライバーのバインドを解除した後も、ホスト上のコンテナがQuick Syncを使い続けられるとは考えないでください。

SR-IOVまたはmediated deviceがサポートされている場合は、物理機能をホストに保持し、仮想機能またはmdevをVMに割り当てます。本番環境で利用可能と判断する前に、リセットとドライバーの動作を確認してください。

機能とワークロードのシグナルを確認する

ホストが引き続きレンダーノードを公開していることと、VMが割り当てられた仮想GPUを認識していることを確認します。デバイス一覧だけに頼らず、両方の環境でハードウェアデコードまたはエンコードを実行してください。

同時にトランスコードを実行している間、GPUエンジンの使用率、エラー、メモリ負荷、カーネルログを監視します。共有可能な容量があっても、性能やコーデックのサポートが予測可能になるとは限りません。

以下の表を使用して、安全な運用モデルを選択してください。

最小権限とアップグレード管理を設定する

ホスト上のコンテナには、広範な特権アクセスではなく、レンダーデバイスと必要なグループ権限だけを付与します。VMには仮想化された機能に対応するドライバーをインストールし、メンテナンス用にソフトウェアレンダリングへのフォールバックを用意します。

次回のアップデートがラボテストに合格するまで、動作しているカーネルとドライバーの組み合わせを固定します。実験的なSR-IOVモジュールは、カーネルやファームウェアのアップデート後に動作しなくなる可能性があるため、削除と復旧の手順を文書化してください。

ZimaSpaceのZimaCube GPU拡張の概要では、ハードウェアについて説明しています。

独立したホームラボ向けGPU共有ガイドでは、完全なパススルー、mediated device、SR-IOVについて解説しています。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

再起動後と同時負荷時に再テストする

ホストをコールドブートし、最初にコンテナ、次にVMを起動します。その後、逆の順序でも繰り返します。どちらの経路でも、手動でドライバーを再バインドせずに復旧できる必要があります。

実際の同時ワークロードを十分な時間実行し、サーマルスロットリングやリセット障害を検出します。その後、ホストを再起動せずにVMを再起動し、コンテナがアクセラレーションを維持していることを確認します。

対象プラットフォームが共有モードを正確にサポートし、同時負荷テストと再起動テストに耐えられる場合にのみ進めてください。ホストのレンダーノードが失われる、VMをリセットできない、安全に固定できない未保守のドライバーに依存している、といった場合は中止してください。