Proxmox VEでIntel i915 SR-IOV vGPUを構成する完全ガイド：第11〜14世代iGPUを複数VMで共有 - ITFROMZERO - Share tobe shared! Proxmox VE 8.xでIntel i915 SR-IOV vGPUを構成する詳細ガイド。第11〜14世代Intel iGPUを複数のPlex、Jellyfin、Windows VMに共有し、Code 43エラーを完全に排除してハードウェア性能を最大限に引き出すソリューション。

Table of Contents

クイックスタート：5分で完了するi915 SR-IOVのクイックセットアップ

従来のPCIeパススルーには致命的な弱点があります。それは、1つの物理デバイスを1台の仮想マシン（VM）にしか割り当てられない点です。Windows VMがUHD 770 iGPUを占有してしまうと、隣のJellyfinコンテナは即座にハードウェアアクセラレーションを失い、4Kトランスコード時にCPUボトルネックが発生します。

SR-IOV（Single Root I/O Virtualization）技術とDKMSモジュールを組み合わせることで、この問題を根本から解決できます。すべてのセットアップ手順は、Proxmoxホスト（PVE 8.x、Kernel 6.5または6.8）のシェル上で直接実行します。

# 1. カーネルヘッダーとビルドツールのインストール
apt update && apt install -y git build-essential pve-headers-$(uname -r) dkms sysfsutils

# 2. i915 SR-IOV DKMSドライバリポジトリのクローン
cd /usr/src
git clone https://github.com/strongtz/i915-sriov-dkms.git
cd i915-sriov-dkms

# 3. システムへのモジュール登録とビルド
dkms add .
dkms install -m i915-sriov-dkms -v $(cat VERSION)

# 4. ビルド後のモジュール状態を確認
dkms status

GRUBを更新してIOMMUを有効化し、i915ドライバがVirtual Function（VF）を生成できるようにします。

# GRUBにIOMMUパラメータ、GuCファームウェア、最大7つのVF設定を追加
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="[^"]*/& intel_iommu=on iommu=pt i915.enable_guc=3 i915.max_vfs=7/' /etc/default/grub
update-grub

# システム起動時に自動生成するVF数を定義
echo "devices/pci0000:00/0000:00:02.0/sriov_numvfs = 7" >> /etc/sysfs.conf

# Proxmoxホストを再起動
reboot

サーバー再起動後、すぐに結果を確認します。

lspci | grep -i display
# 正常な出力では、00:02.0（Physical Function）に加えて00:02.1から00:02.7までの7つの仮想デバイス（Virtual Function）が表示されます

技術的な背景：廃止されたGVT-gとSR-IOVへの移行

Skylake（第6世代）からComet Lake（第10世代）まで、IntelはLinuxカーネル内でGVT-gをネイティブサポートしていました。この技術により、Mediated Deviceメカニズムを介した非常にスムーズなvGPU共有が可能でした。しかし、Tiger Lake（第11世代）以降、Alder Lake（第12世代）やRaptor Lake（第13/14世代）などの新アーキテクチャでは、IntelはGVT-gを完全に廃止しました。

その代わりに、Intelはコンシューマー向けiGPUのハードウェア層にSR-IOVを導入しました。このメカニズムはシリコンレベルで直接動作し、以下の2つの独立したコンポーネントで構成されます。

Physical Function（PF）： バスアドレス 00:02.0 に固定されます。PFは物理ハードウェア全体の管理権限を保持し、クロック、電圧の制御およびVRAMの割り当てを担います。
Virtual Function（VF）： 仮想PCIeデバイス群（00:02.1 から 00:02.7 まで）です。各VFは独立したPCIe構成空間を保持します。QuickSyncエンジン（H.264、HEVC、AV1のデコード/エンコード）は、GuCハードウェアスケジューラを介してリアルタイムにタイムスライス共有されます。

Linuxカーネル標準のIntel公式ドライバは、コンシューマー向けCPUでのVF生成機能を制限しています。オープンソースプロジェクトである i915-sriov-dkms はこの障壁を解除し、Core i5-13500などの一般的なCPUでも、複数の仮想マシンにまたがって5ストリームの4K HDRトランスコードを同時に快適に処理できるようにします。

VMへのVF割り当てとWindowsでのCode 43エラー完全回避手順

仮想マシンに仮想デバイスを正常に認識させるには、Proxmox側でPCIeフラグを正確に設定する必要があります。

1. Plex、Jellyfin、Docker用Linux VMの構成

VMの設定ファイル（例：VM 101の場合は /etc/pve/qemu-server/101.conf）を開き、VFデバイスを追加します。

# 最初のVirtual FunctionをVMに割り当て
hostpci0: 0000:00:02.1,pcie=1

Ubuntu/Debian VMを起動し、グラフィックスドライバの検証ツールをインストールします。

apt install -y vainfo intel-media-va-driver-non-free
vainfo --display drm --device /dev/dri/renderD128

コマンド実行結果として、H264やHEVC Main10形式に対してVAEntrypointVLDおよびVAEntrypointEncSliceをサポートするプロファイル一覧が出力されれば、ハードウェアアクセラレーションは正常に動作しています。

2. Windows 10 / Windows 11仮想マシンでのCode 43エラー回避

Windows環境向けのIntelグラフィックスドライバは、デフォルトでハイパーバイザのシグネチャをスキャンします。KVM仮想化環境が検出されるとドライバは動作を停止し、デバイスマネージャーにCode 43エラーが表示されます。

これを回避するには、Windows VMの設定ファイル（例：/etc/pve/qemu-server/102.conf）を開き、以下のパラメータテンプレートを適用します。

bios: ovmf
machine: q35
cpu: host,hidden=1,flags=+pcid
hostpci0: 0000:00:02.2,pcie=1,x-vga=1
vga: none

hidden=1 フラグによってCPUIDテーブルからKVMの識別情報が隠蔽されます。これによりゲストOSはグラフィックスカードをベアメタル環境と同様に認識します。あとは公式のIntel Graphics DCHドライバをダウンロードして通常通りインストールするだけです。

運用ノウハウと実践的なトラブルシューティング

システムの長期的な安定稼働を維持するための重要な技術的注意点を以下にまとめます。

カーネル更新後のトラブル： Proxmoxのカーネルがアップデートされるたびに（例：6.8.4から6.8.8への移行時など）、ヘッダーパッケージが不足しているとDKMSが新しいモジュールをビルドできない場合があります。apt dist-upgrade を実行した後は、必ず dkms status で確認してください。モジュールにエラーが出ている場合は、再起動前に直ちに dkms autoinstall を実行します。
GuC/HuCファームウェア読み込みの確認： GuCファームウェアがロードされていない場合、システムは各VFへのリソース割り当てを拒否します。確認するには以下のコマンドを実行します。
```
dmesg | grep -i guc
```
システムログに GuC firmware validated の行が出力されていれば、ハードウェアスケジューラが正常に準備完了しています。
用途に応じたVRAM最適化： i915ドライバは、max_vfs の値に基づいてビデオメモリを均等に分割します。2台のVMでのみ使用する場合は、パラメータを i915.max_vfs=2 に変更してください。これにより、各VMで利用可能なフレームバッファ容量とVRAMが2倍に増加します。
SSH経由のリカバリ経路を確保： マザーボードのHDMIポートに直接接続されたディスプレイを見ながらネットワーク設定やPCIバス構成を変更するのは避けてください。ドライバロード時に映像出力ポートが無効化された場合でも迅速に対処できるよう、必ず独立したSSHセッション経由で操作を行ってください。