ProxmoxでGPUパススルーを設定するときに詰まった話

前置き

この記事はQiita Advent Calendar 2025 / ひとりアドベントカレンダー 分野における ふぐおの配信関係多めひとり Advent Calendar 2025 の16日目記事となります。

はじめに

こんにちは! プログラミング配信をしているふぐおです。
最近、家のサーバー(ノートPC)にProxmox VEを導入し、GPUパススルーを試みました。
このとき、結構色々なところで詰まったので、紹介します。

今回の環境と構成

項目	内容
CPU	Intel Core i5-8265u
GPU	Intel UHD Graphics 620
ホストOS	Proxmox VE 9.1.2
ゲストOS	Ubuntu 25.10

GPUパススルーと仮想GPU

ProxmoxでゲストOSにGPUを利用させるには、2つの方法があります。
GPUパススルーと仮想GPUです。
両者は以下のような違いがあります。

• GPUパススルー: ホストOSがGPUを手放し、ゲストOSにハードウェアそのものを渡す方法
• 仮想GPU: ホストOSがGPUを握り続け、ゲストOSからの命令をホストOSが受け取り、ホストOSがGPUに処理させる方法

GPUパススルーを利用したい場合は、ホストOSがGPUを手放す設定があるため、両者の設定を共存させることはできません。

手順

1. GRUBの設定を変更し、IOMMUを有効化する
2. モジュールの追加
3. ホストOSがGPUを握らないようにする
4. ゲストOSを入れる
5. RDPを有効にする
6. GPUをゲストOSに割り当てる

軽く手順の説明

詳細な説明は様々なところに転がっているので、そちらを参考にしてください。
ポイントを抑えて紹介します。

GRUBの設定

ホストOSのGRUBの設定を変更し、IOMMUを有効化します。
サイトによって様々な引数が紹介されていますが、私は以下の設定で動作しました。

~~
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt video=efifb:off"
~~

grubの設定を変更したら、update-grubを実行し、再起動します。

モジュールの追加

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

ホストOSがGPUを握らないようにする

/etc/modprobe.d/blacklist.conf

blacklist i915
blacklist snd_hda_intel
blacklist snd_hda_codec_hdmi
blacklist xhci_hcd

update-initramfs -uでinitramfsを更新し、再起動します。

ゲストOSのインストール

システム

BIOS/UEFIの箇所でOVMF(UEFI)を選択します。(必須だと思われる)
認証されてないと出ると面倒なので、pre-enrolled keysのチェックを外しています。
シャットダウンがホストOS側でできるようになるので、Qemu エージェントもチェックを入れておくのがおすすめです。

ディスク

パス/デバイスはSATAを選択。
キャッシュはWrite Throughを選択しています。
中止（Discard）にもチェックを入れます。

CPU

GPUパススルーをする場合、ホストを選択する必要があります。

メモリ

Ballooningは無効にしておくと良いらしいです。

ネットワーク

デフォルトのままです。

その後のインストール作業

普通のインストールと同様です。

RDPを有効にする

Ubuntuのインストールが終わったら、一応レンダリングがどのようになっているかを確認しましょう。

設定->システム->このシステムについて->システムの詳細で確認できます。

現在はSoftware Renderingとなっていると思います。
CPUがホストのCPUと同じになっていることも確認しておきましょう。

次にRDPを有効にします。
こちらも同じ設定->システム->Remote Desktopから有効にできます。
ただ今回は、このあとVNCからの操作がまったくできなくなるので、Remote Loginの方を有効にしておきましょう。
Remote Sharingの方が有効になっているとポートがずれるので注意。

GPUをゲストOSに割り当てる

ゲストOSをシャットダウンし、ProxmoxのWebUIからGPUを割り当てます。

このとき、全機能とプライマリGPUにチェックを入れるのを忘れずに。

同時に、ディスプレイもnoneに変更しておきます。

ゲストOSを起動して確認

ゲストOSを起動すると、GPUパススルーが動くといつものコンソールからは接続できません。
逆に接続できてしまった場合は、GPUパススルーがうまく動いていない可能性があります。
RDPクライアントから接続しましょう。

今度はレンダリングにGPUが使われていることが確認できます。

だめだった場合

原因がホスト側かゲスト側かを切り分ける

まずlspciコマンドでGPUが認識されているかを確認します。

lspci

もし、GPUが表示されていない場合は、ホスト側の設定に問題があります。

ゲストOS側のドライバの問題

ドライバーが割り当てられているか確認します。

lspci -k

01:00.0 VGA compatible controller: Intel Corporation WhiskeyLake-U GT2 [UHD Graphics 620] (rev 02)
	Subsystem: Matsushita Electric Industrial Co., Ltd. Device 8354
	Kernel driver in use: i915
	Kernel modules: i915

Kernel driver in use: i915 のように、in use の行が表示されていない場合は、ドライバが割り当てられていない可能性があります。

カーネルのエラーの確認

GPUの初期化時にエラーが出ている可能性があります。

sudo dmesg | grep i915

なにかエラーメッセージが出ていないかを確認しましょう。

デバイスファイルの権限問題

私が引っかかった問題はここです。
デバイスファイルにユーザーがアクセスできなくなっていました。
症状としては、
vainfo --display drm --device /dev/dri/renderD128といったようなコマンドを打つと、開くのに失敗し、sudoをつけると正常に開けるといった感じです。

この場合以下のコマンドで修正できます。

# ユーザーを render グループに追加
sudo usermod -aG render $USER

# （念の為 video グループにも追加）
sudo usermod -aG video $USER

ログアウトすると設定が反映されます。

まとめ

まずはゲストOS側で症状を確認し、その後ホストOS側の設定を見直すと良いとわかりました。