

PCパーツ・ガジェット専門
自作PCパーツやガジェットの最新情報を発信中。実測データに基づいた公平なランキングをお届けします。
GPUパススルー(VFIO)は、物理GPUを仮想マシンに直接割り当て、ベアメタル環境とほぼ同等のネイティブなグラフィックス性能を得るための技術です。IOMMU対応CPU(Intel VT-dまたはAMD-Vi)と2枚以上のGPUを準備し、Proxmox VEやlibvirt/QEMU上で設定することで、ホストOSの負荷を最小限に抑えながら、ゲーミングVMやGPU計算ノードを構築できます。2026年現在、PCIe 5.0対応GPUの普及により、帯域幅のボトルネックは解消され、パススルー経由でも4K 144Hzや8K映像のリアルタイム処理が可能になっています。
本ガイドでは、IOMMUグループの確認からNVIDIA Code 43エラーの回避、Looking Glassによる低遅延画面共有まで、実践的な設定手順を網羅的に解説します。仮想化によるオーバーヘッドを5%未満に抑えるためのCPU PinningやHugepages最適化、AMD GPUのリセットバグ対策といった上級者向けのノウハウも含まれており、単なる手順書ではなく、安定稼働させるための設計思想も提示します。GPUパススルーの導入を検討しているITエンジニア、HomeLab愛好家、あるいはゲーミングVM構築を目指すユーザーは、この記事で必要な技術的知識と具体的なコマンドライン操作を習得できます。
GPUパススルー(VFIO)とは、ホストOSが物理的に保持しているGPUデバイスを、仮想マシン(VM)に「直接割り当て」て、ベアメタル環境と同等のグラフィックス性能を発揮させる技術です。この仕組みの核心は、IOMMU(Input-Output Memory Management Unit)によるメモリ管理と、VFIO(Virtual Function I/O)ドライバによるデバイスロックにあります。従来の仮想化ではGPUの演算資源を時間分割して共有していましたが、VFIOではPCIeバスのデバイスIDごとを仮想マシンに独占させるため、PCIeのオーバーヘッドがほぼゼロに近く、ネイティブなフレームレートが実現します。
この技術を成功させるための絶対条件は、CPUとマザーボードがIOMMUに対応していることです。Intelプロセッサーの場合、VT-d(Virtualization Technology for Directed I/O)機能、AMDプロセッサーの場合、AMD-Vi(IOMMU)機能がBIOS内で有効である必要があります。さらに重要なのが「IOMMUグループ」の概念です。IOMMUは特定のデバイスグループに対してのみ独立した割り当てを許可するため、PCIeスロット、M.2 NVMe SSD、ネットワークコントローラ、USBコントローラなどが同じIOMMUグループに属している場合、それら全てのデバイスを同時にVMに割り当てることができません。もしGPUと同じグループにUSBコントローラが含まれており、そのUSBコントローラをVMで使いたい場合、グループ内の他のデバイス(GPU)をVMに渡すとUSBもVM側で認識されてしまい、ホスト側のキーボードやマウスが効かなくなるという致命的な問題が発生します。
したがって、初期設定の第一歩は、システム内のIOMMUグループ構造を完全に把握することです。Linuxカーネルは起動時に各PCIeデバイスのIOMMUグループを割り当て、/sys/kernel/iommu_groups/ 配下にその情報を出力します。以下のコマンドで、各グループに属するデバイスの詳細を確認できます。
find /sys/kernel/iommu_groups/ -type l | grep -o '.*devices/.*' | sort -V
この出力結果を注意深く解析し、GPUを単独で、あるいはVMで必要ないデバイス(例:Wi-Fiカード、不要なオーディオコーデック)のみを含むグループに配置されているかを確認します。理想的な構成は、GPUが独立したIOMMUグループにあり、かつそのグループ内のデバイスがVMに渡してもホストの運用に影響を与えないものです。例えば、AMD Ryzen 7000シリーズやIntel第13世代Core以降のプラットフォームでは、PCIe 5.0対応のチップセット設計によりIOMMUグループの分割がより細かくなっている傾向がありますが、マザーボードのレイアウト次第では依然としてグループ分割が不十分なケースがあります。
IOMMUグループの確認は、後々のトラブルシューティングにおいて最も重要なステップです。もしGPUとUSBコントローラが同一グループにある場合、USBパススルーを諦めるか、PCIeスイッチ付きの拡張カードを使用してIOMMUグループを人為的に分割するなどのハックが必要になります。このように、GPUパススルーは単にドライバーをインストールするだけでなく、ハードウェアの物理的な接続構造とOSの仮想化エンジンの相互作用を深く理解した上での設定作業となります。
GPUパススルーを有効化するには、ホストOSのカーネルパラメータ変更と、仮想マシン管理ソフトウェア(Proxmox VEまたはlibvirt/QEMU)側の設定が不可欠です。ここでは、最も人気のある2つの環境における具体的な設定手順と、必要なハードウェア要件を解説します。
まず、共通する前提条件として、ホスト用とゲスト用で2枚以上のGPUが必要です。ホスト側には、安価な統合GPU(Intel UHD Graphics 770など)または低電力のPCIe GPU(NVIDIA GT 1030など)を1枚差し、ゲスト側に高性能なdGPU(NVIDIA GeForce RTX 4070 Ti SuperやAMD Radeon RX 7900 XTXなど)を1枚差す構成が標準的です。ホスト用GPUがない場合、Single GPUパススルーという手法を用いますが、これはVM起動時にGPUを切り替えるため、VM外での操作が不可能になり、運用が複雑になります。
Proxmox VE 8.x での設定手順
Proxmox VEはDebianベースの仮想化プラットフォームです。設定は以下の順で行います。
/etc/default/grub を編集し、GRUB_CMDLINE_LINUX_DEFAULT に以下のパラメータを追加します。
intel_iommu=on iommu=pt vfio-pci.ids=10de:2704,10de:1aef amd_iommu=on
vfio-pci.ids には、パススルーするGPUのベンダーID(10deはNVIDIA、1022はAMD)とデバイスIDをカンマ区切りで指定します。例:NVIDIA RTX 4070 Ti Superなら 10de:2704,10de:1aef。update-grub と update-initramfs -u を実行して変更を反映させ、システムを再起動します。lspci -nn | grep -i vga でGPUのIDを確認し、vfio-pci ドライバに強制的にバインドします。これにより、ホスト側の NouveauやNVIDIAドライバーがGPUを制御できなくなります。libvirt/QEMU での設定手順
libvirtを使用する場合、XML定義ファイルを直接編集するか、virsh コマンドを用いて設定します。
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
</source>
<rom file='/path/to/vbios.rom'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</hostdev>
<source> タグのアドレスは、lspci で確認したバス・スロット・ファンクション番号を指定します。また、NVIDIA GPUを使用する場合、<address> の slot はVMのPCIスロットとして認識される番号であり、既存のデバイスと重複しない必要があります。
対応マザーボードの選定基準
| マザーボードカテゴリ | IOMMUグループ分割の傾向 | GPUパススルー適性 | 推奨モデル例 |
|---|---|---|---|
| 高級ゲーミング(Z790/X670) | 比較的良好。USB/HDMIコントローラが分離されやすい | 高 | ASUS ROG Maximus Z790 Hero, MSI X670E Tomahawk |
| ミドルレンジ(B650/B760) | 要確認。USBコントローラがGPUと同一グループになりがち | 中〜高 | ASUS TUF GAMING B650-PLUS, Gigabyte B760M AORUS ELITE |
| エントリー/統合(H610/A620) | 分割が粗く、トラブル発生率が高い | 低〜中 | ASUS PRIME H610M-K, MSI A620M-E |
| サーバー/ワークステーション | IOMMUグループが細かく分割されている | 非常に高 | ASUS ProArt W790-CREATOR, Supermicro X13SWA-F |
高級ゲーミングマザーボードやワークステーション向けマザーボードは、IOMMUグループの分割が洗練されており、GPUとUSBコントローラを分離しやすいため、初心者でも設定が成功しやすい傾向にあります。一方、エントリーチップセットでは、PCIeスロットの物理的な配置とチップセット内部のバス構造により、GPUがUSB 3.0コントローラと同一グループに属するケースが多々あります。この場合、USBパススルーを諦めるか、PCIeスイッチ(例:ASM1184チップ搭載カード)を使用してIOMMUグループを分割する必要があります。
GPUパススルーで最も頻繁に遭遇する障害は、GPUベンダー固有の保護メカニズムやハードウェアの仕様によるものです。特にNVIDIA製GPUの「Code 43」エラーと、AMD製GPUの「リセットバグ」は、設定を正しく行っても発生する厄介な問題です。
NVIDIA Code 43エラーの回避手順
NVIDIAのドライバーは、VMが仮想環境上で動作していることを検知すると、インストールを中断したり、ディスプレイ出力を止めるなどの保護措置(Code 43エラー)を発動します。これはライセンス保護の仕組みですが、VFIO環境ではこれを回避する必要があります。
回避策として主流なのは、qemu-guest-agent やXML設定により、VMが仮想化環境であることを隠蔽する方法です。具体的には、VMのXML定義に以下の修正を加えます。
vendor_idの隠蔽:
<cpu> セクションに vendor 属性を追加し、ホストCPUベンダーのID(Intelなら GenuineIntel、AMDなら AuthenticAMD)を強制的に設定します。これにより、VM内のNVIDIAドライバーが「これは物理マシンだ」と誤認します。
hypervisorフラグの無効化:
<cpu> セクション内で <feature policy='disable' name='hypervisor'/> を追加します。通常、VMはCPUID命令でhypervisorフラグがセットされていることを検知しますが、これを無効にすることで、NVIDIAドライバーが「物理マシン」として認識するようになります。
VBIOSの適切な設定: GPUのROMバッチ(VBIOS)を正しくマウントしているか確認します。特に、VBIOSのサイズやフォーマットが正しくない場合、ドライバーの初期化段階でエラーが発生し、結果としてCode 43と同様の症状を引き起こすことがあります。VBIOSはGPUの製造元から公式に公開されている場合もありますが、ない場合は別のVMから抽出する必要があります。
ドライバーの更新: NVIDIAは定期的に仮想環境検知の手法を更新しています。最新のドライバー(2026年時点では r570 シリーズ以降)を使用し、設定の変更を反映させることが重要です。
AMD GPUのリセットバグ対策
AMD GPUには、「リセットバグ(Reset Bug)」と呼ばれる問題があります。これは、PCIeリセット(スロットの電源断と再接続)をVMが行った際、GPUが正しく初期化されず、ホスト側でもVM側でも認識しなくなる現象です。AMD Radeon RX 6000シリーズ(RDNA2)やRX 7000シリーズ(RDNA3)の一部で発生が報告されています。
対策として以下の方法があります。
VFIOのバインド解除と再バインド: VMをシャットダウンした際、VMがGPUを解放した後に、カーネルモジュールのアンロードと再ロードを行うスクリプトを実行します。
# /etc/systemd/system/vfio-reset.service
[Unit]
Description=Reset VFIO devices after VM shutdown
After=shutdown.target
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'modprobe -r vfio-pci; modprobe vfio-pci'
PCIeリセットの回避:
VMの設定で、PCIデバイスへのリセットを抑制するオプションを探します。libvirt/QEMUの場合、<hostdev> タグ内に reset='on' または reset='off' の属性がありますが、ハードウェア依存性が強いため、効果はGPUとマザーボードの組み合わせによります。
VBIOSの修正: 一部のAMD GPUでは、VBIOSの一部を修正することでリセットバグを回避できる場合があります。ただし、これは上級者向けであり、VBIOSのバックアップを必ず取ってから行ってください。
カーネルパラメータの調整:
amd_iommu=on だけでなく、amd_iommu=fullflush や iommu=pt などのパラメータを追加し、IOMMUのパフォーマンスと安定性を調整します。
これらの対策は、GPUパススルーの安定稼働にとって不可欠です。特にNVIDIAユーザーはCode 43対策を、AMDユーザーはリセットバグ対策を、それぞれのGPUモデルに応じて適切に適用する必要があります。
GPUパススルーで得た高性能を最大限に引き出すには、CPUとメモリの最適化、そして低遅延な入出力環境の構築が不可欠です。単にGPUを割り当てるだけでなく、システム全体の構成をゲーミング向けにチューニングすることで、ベアメタルとほぼ同等の体験が可能になります。
CPU PinningとHugepagesの活用
GPUの演算負荷が高いため、VMのCPUリソースを固定(CPU Pinning)し、ホストOSの他のプロセスと干渉させないことが重要です。
CPU Pinning:
VMのXML定義で <vcpu> の cpuset 属性を使用し、特定の物理コアにVMのvCPUを固定します。例えば、AMD Ryzen 9 9950Xの場合、コア0-7をホスト用、コア8-15をVM用に割り当てるなどします。これにより、VMの処理が他のコアにスレッドを移動するオーバーヘッドがなくなり、フレームタイムの安定性が向上します。
Hugepages(巨大ページ):
メモリ管理ユニット(MMU)のオーバーヘッドを減らすため、4KBのページではなく2MBまたは1GBの巨大ページを使用します。Linuxホストで hugepages を有効化し、VMのXML定義で <memoryBacking> タグ内に <hugepages/> を追加します。これにより、GPUとVM間のメモリ転送効率が向上し、特に大容量テクスチャを扱うゲームで性能差が発現します。
Looking Glassによる低遅延画面共有
GPUパススルーの最大の課題は、VM内のGPU出力をホストOSのモニターに表示する方法です。従来のRDPやVNCは遅延が大きく、ゲーミングには適しません。ここで活躍するのが「Looking Glass」です。
Looking Glassは、VM内のGPUメモリを直接読み取り、ホストOSのOpenGL/Vulkanアプリケーションで描画する技術です。ネットワーク経由ではなく、共有メモリ(shm)を用いるため、遅延は1〜2ms程度に抑えられ、ベアメタルと見分けがつかないほどスムーズです。
設定手順は以下の通りです。
ホスト側のインストール: LinuxホストにLooking Glassのホスト側コンポーネントをインストールします。
sudo apt install looking-glass-host
VM側のインストール: VM内のゲストOS(Windows/Linux)にLooking Glassのゲスト側クライアントをインストールします。
VM設定の変更:
VMのXML定義で、共有メモリデバイス(/dev/shm/looking-glass)をVMにマウントします。
<filesystem type='mount' accessmode='passthrough'>
<source dir='/dev/shm/looking-glass'/>
<target dir='looking-glass'/>
</filesystem>
Looking Glassの起動: VM内でLooking Glassクライアントを起動し、ホストのLooking Glassホストに接続します。これで、VMのディスプレイ出力がホストモニターにリアルタイムで表示されます。
オーディオパススルーとUSBパススルー
音声と入力はゲーミング体験の重要な要素です。
オーディオ: GPUのHDMIオーディオをVMに割り当てる場合、NVIDIA RTX 30/40シリーズやAMD RX 6000/7000シリーズのHDMIオーディオコントローラをPCIデバイスとして割り当てます。ただし、ホスト側のサウンドドライバー(PulseAudio/PipeWire)がGPUのオーディオデバイスを使用している場合、競合が発生します。解決策として、ホスト側のオーディオ出力を別のデバイス(例:Realtekオーディオコーデック)に固定し、GPUのHDMIオーディオをVM専用にします。また、USBオーディオインターフェース(例:Focusrite Scarlett 2i2)をUSBパススルーでVMに割り当てる方法もあります。
USBパススルー: キーボードとマウスをUSBコントローラごとVMに割り当てます。ただし、前述のIOMMUグループの問題に注意が必要です。GPUと同じIOMMUグループにあるUSBコントローラをVMに割り当てると、ホストのキーボードやマウスが使えなくなります。解決策として、USBコントローラを個別に指定するのではなく、特定のUSBデバイス(キーボード、マウス)を直接割り当てる「USBデバイスパススルー」を使用します。これにより、他のUSBデバイス(例:Webカメラ、マイク)はホスト側に残しつつ、キーボードとマウスのみをVMに渡すことができます。
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x046d'/>
<product id='0xc52b'/>
</source>
</hostdev>
このように、ハードウェアの特性を理解し、適切な最適化を施すことで、GPUパススルーはベアメタルに迫るパフォーマンスと使いやすさを実現します。
GPUパススルー環境を構築する際、単にGPUを購入するだけでなく、CPU、マザーボード、メモリ、電源といった周辺機器の互換性と性能バランスが全体の安定性とパフォーマンスを決定します。2026年時点で主流となっている構成は、Intel第14世代CoreシリーズやRyzen 9000シリーズといった最新世代のIOMMU対応CPUと、PCIe 5.0対応マザーボードの組み合わせです。本セクションでは、具体的な製品例を用いて、価格帯、スペック、用途、判断基準の4軸で主要な構成要素を比較します。これにより、予算と目的に応じた最適なコンポーネントの選択が可能になります。
GPUパススルーにおいて、ゲストOSとして動作する仮想マシンの用途(ゲーミング、3Dレンダリング、AI推論)によって、推奨されるGPUアーキテクチャと価格帯は大きく異なります。AMD Radeon RX 7000シリーズはOpenCLやVulkanのネイティブなサポートが厚く、VFIOとの親和性が高い一方で、NVIDIA GeForce RTX 40シリーズはCUDAエコシステムの利用者にとって不可欠です。以下の表は、代表的なGPUモデルを比較したものです。
| GPUモデル | アーキテクチャ | VRAM容量 | TDP (W) | 価格帯 (円) | 主な用途 | 判断基準 |
|---|---|---|---|---|---|---|
| NVIDIA RTX 4090 | Ada Lovelace | 24GB GDDR6X | 450W | 180,000〜250,000 | 高負荷ゲーミング、AI学習 | CUDA必須、最高パフォーマンス |
| AMD RX 7900 XTX | RDNA 3 | 24GB GDDR6 | 355W | 90,000〜130,000 | 高解像度ゲーミング、Vulkan | コスパ重視、VFIO親和性 |
| NVIDIA RTX 4070 Ti Super | Ada Lovelace | 16GB GDDR6X | 285W | 80,000〜110,000 | 1440pゲーミング、動画編集 | 16GB VRAMのバランス |
| AMD RX 7800 XT | RDNA 3 | 16GB GDDR6 | 263W | 50,000〜70,000 | 1080p/1440pゲーミング | 低価格帯での高VRAM |
GPUパススルーの要となるIOMMU(IO Memory Management Unit)の動作安定性は、CPUとマザーボードの組み合わせに依存します。Intel VT-dとAMD-Vi(AMD IOMMU)は、それぞれ異なる実装を持っており、特にIOMMUグループの分割状況がPCIデバイス割り当ての自由度を左右します。2026年現在、Intel Core i9/i7とRyzen 9/7のハイエンドモデルは、より大きなIOMMUグループを形成する傾向があり、複数GPUを搭載する場合に有利です。
| CPUモデル | IOMMU技術 | チップセット | IOMMUグループ数 (概数) | 推奨マザーボード | 判断基準 |
|---|---|---|---|---|---|
| Intel Core i9-14900K | VT-d | Z790 | 小〜中 | ASUS ROG Maximus Z790 | PCIe 5.0対応、多数のUSBポート |
| Intel Core i7-14700K | VT-d | Z790 | 中 | MSI MPG Z790 Carbon | コストパフォーマンス、安定性 |
| AMD Ryzen 9 9950X | AMD-Vi | X870 | 大 | ASUS ProArt X870-CREATOR | 多数のPCIeスロット、信頼性 |
| AMD Ryzen 7 9800X3D | AMD-Vi | X870 | 中 | Gigabyte X870 AORUS Elite | ゲーミング特化、キャッシュメモリ |
GPUパススルー環境では、ゲストOSのメモリ管理効率を向上させるため、Linuxホスト側でHugePages(巨大ページ)の利用が推奨されます。これにより、TLB(Translation Lookaside Buffer)のミスヒットが減り、メモリアクセスのオーバーヘッドが低下します。また、VMに割り当てるメモリ容量と、ホストOSが確保するHugePagesのサイズ(通常2MBまたは1GB)の設定が、パフォーマンスに直結します。以下の表は、メモリ容量と設定方法の比較です。
| メモリ構成 | RAM容量 | HugePagesサイズ | VMメモリ割り当て | 適した用途 | 判断基準 |
|---|---|---|---|---|---|
| 標準構成 | 32GB DDR5 | 2MB | 8GB | 軽量VM、テスト環境 | 低コスト、手軽な設定 |
| 最適化構成 | 64GB DDR5 | 2MB | 16GB | 一般的なゲーミングVM | バランスの取れた性能 |
| 高性能構成 | 128GB DDR5 | 1GB | 32GB | 高負荷レンダリング、AI | TLB効率最大化、大規模データ処理 |
| エンタープライズ | 256GB DDR5 ECC | 1GB | 64GB以上 | 複数VM並列実行、プロ用 | エラー訂正、安定性、拡張性 |
GPUパススルーでは、GPUがVM内でフル稼働するため、ベアメタル時と同様、あるいはそれ以上に安定した電源供給と冷却が必要です。特に、GPUのPCIeスロットからの給電(最大75W)に加えて、8ピンコネクタによる追加給電が必要となります。高消費電力なGPU(例:RTX 4090)を搭載する場合、電源ユニットの定格出力と、CPU/GPUの瞬時消費電力(Transient Spike)への耐性が重要です。
| 電源ユニット | 定格出力 (W) | 規格 | GPU対応能力 | 適したGPU構成 | 判断基準 |
|---|---|---|---|---|---|
| Corsair RM850x | 850W | 80 PLUS Gold | RTX 4070 Ti Superまで | シングルGPU構成 | コスパ、静音性、信頼性 |
| Seasonic PRIME TX-1000 | 1000W | 80 PLUS Titanium | RTX 4090まで | 高消費電力GPU | 最高効率、長寿命、静寂性 |
| be quiet! Dark Power 13 1200 | 1200W | 80 PLUS Titanium | 複数GPU/過負荷 | 複数GPU、将来拡張 | 余剰電力、プロ向け信頼性 |
| Fractal Design Ion Gold 850 | 850W | 80 PLUS Gold | RX 7900 XTXまで | AMD GPU構成 | 静音設計、日本国内サポート |
GPUパススルー環境の構築には、ハードウェアの入手可能性とアフターサポートも重要な要素です。特に、BIOSアップデートによるIOMMUグループの修正や、ドライバーの最新化が必要となる場面では、国内でのサポート体制が役立ちます。また、中古市場での価格変動も大きく、時期による購入戦略の違いを理解しておく必要があります。
| 購入チャネル | 価格傾向 | 保証期間 | サポート体制 | 適した購入者 | 判断基準 |
|---|---|---|---|---|---|
| 新品(家電量販店) | 標準〜高価 | 1年 | 迅速、窓口対応 | 初心者、時間重視 | 安心感、即納性 |
| 新品(オンライン専門) | 標準 | 1年 | メール/電話 | 価格比較派 | 品揃え、価格競争力 |
| 中古(フリマアプリ) | 低価格〜中 | なし〜3ヶ月 | 自己責任 | 上級者、コスト重視 | 低価格、リスク許容度 |
| B2B企業向け | 契約価格 | 3年〜 | 専用サポート | 法人、長期利用 | 安定供給、保守契約 |
これらの比較表を参照し、自身の使用環境(Proxmox VEかlibvirtか、メインGPUかサブGPUか、予算はどれくらいか)に合わせてコンポーネントを選択することが、失敗のないGPUパススルー環境構築の第一歩となります。特に、IOMMUグループの確認は購入前に必須であり、マザーボードのレビューやCPUベンチマーク情報で事前に確認しておきましょう。
GPUパススルーを実行するには、IOMMU(Intel VT-dまたはAMD-Vi)に対応したCPUとマザーボード、そして2枚以上のGPUが必要です。ホスト用としてIntel Core i5-14600KやAMD Ryzen 7 7800X3DなどのiGPU付きCPU、ゲスト用にはNVIDIA GeForce RTX 4060やAMD Radeon RX 7800 XTといった専用GPU1枚があれば構築可能です。メモリは64GB以上を推奨し、ストレージはPCIe 4.0対応のNVMe SSD(例:Samsung 990 PRO)を使用することで、仮想マシン内のGPU通信のボトルネックを最小限に抑えられます。
技術的な習得コストを抑えるならProxmox VE、柔軟なカスタマイズを求めるならUbuntu libvirtが適しています。Proxmox VEはWeb GUIでIOMMUグループ確認やVFIOバインド設定が直感的に行えるため、CLI操作に不慣れな方でも比較的容易に構築できます。一方、Ubuntu libvirtはvirshコマンドやXMLファイル編集が必要ですが、Debian系パッケージ管理との親和性が高く、特定のドライバアップデートやカスタムカーネルビルドが必要な上級者向けです。まずはProxmox VEで基本を学び、必要に応じてlibvirtへ移行するのが効率的です。
NVIDIAドライバーが仮想環境を検知してインストールを拒否するCode 43エラーは、GPUのベンダーIDやhypervisorフラグを隠蔽することで回避可能です。Proxmox VEでは、VM設定の「オプション」→「qemuサーバーのプロパティ」でhypervisorフラグを削除するか、vendor_idを空文字列に設定します。libvirt環境では、VMのXML定義に<vendor_id state='on' value='xxxxxxxxxxxx'/>を追加して偽造値を設定します。これにより、NVIDIAドライバーはホスト上の物理GPUとして認識し、正常に動作します。ただし、ドライバーアップデート後に再設定が必要な場合があるため注意が必要です。
GPUパススルー(VFIO)におけるパフォーマンス損失は、適切に設定された環境では5%未満、一般的には95%以上のベアメタル比が達成可能です。PCIeバス経由の通信オーバーヘッドは微小であり、CPUコアのピン留め(Pinning)やHugePagesの有効化により、さらに1〜2%の改善が見込めます。主要なベンチマーク結果では、NVIDIA GeForce RTX 4090を使用した場合、3DMark Time Spyスコアがベアメタルとほぼ同等となり、ゲーム内のフレームレート変動も最小限に収まります。ただし、ホストOSのリソース競合を防ぐため、CPUとメモリの割り当てには十分な余裕を持たせることが重要です。
物理的にGPUが1枚しかない場合でも、「Single GPUパススルー」技術を用いれば仮想マシンにGPUを割り当てることが可能です。これは、仮想マシン起動時にGPUをホストから切り離し、VMにアタッチし、VM終了時に再びホストに戻すという動的な切り替えを行います。KVMのvfio-pciドライバーとqemu-system-x86_64のコマンドラインオプション、またはlibvirtのXML設定で<hostdev mode='subsystem' type='pci' managed='yes'>を指定します。ただし、VMのシャットダウン処理が失敗するとホストがフリーズするリスクがあり、バックアップと慎重な運用が必須です。
コストパフォーマンスと設定の容易さを重視するならAMD GPU、高品質なレンダリングやNVIDIA専用ソフトの安定性を求めるならNVIDIA GPUが適しています。AMD Radeon RXシリーズは、VFIO環境でのリセットバグ対策が比較的単純で、オープンソースのamdgpuドライバーがホスト側でも利用しやすいため、初期設定が楽です。一方、NVIDIA GPUはCode 43回避の一手間が必要ですが、CUDA利用やDLSSなどの独自機能を利用できる利点があります。2026年時点で両社ともIOMMUグループの分離性が向上しており、互いに大きな格差はなくなりましたが、NVIDIAの専門ドライバーの安定性は依然として優れています。
ホストOSの画面出力を低遅延でゲストVMに映し出す「Looking Glass」は、GPUが1枚しかない場合や、VM内の操作をホストのモニターで確認したい場合に極めて有用です。PCIeの共有メモリ(Shared Memory)を用いるため、ネットワーク経由のVNCやRDPよりもフレームレートが高く、遅延は1ms未満に抑えられます。例えば、[AMD [Radeon RX 7900 XT](/glossary/radeon-rx-7900-xtx)](/glossary/radeon-rx-7900-xt)XとIntel Core i9-14900Kの組み合わせでは、240Hzモニターでも滑らかな動作が可能です。ただし、VM側でvfio-pciバインドされたGPUが出力を担当している必要があるため、VMのシャットダウン時にGPUが正しくホストに戻らないと、Looking Glass側でも画面がフリーズします。
USBキーボードやマウスをVMに直接接続するには、USBコントローラーのパススルーまたはevdevドライバの使用が有効です。ハードウェアのPID/VIDを確認し、libvirtのXMLで<hostdev mode='subsystem' type='usb'>として指定するか、Proxmox VEのUIから「USBデバイス」を追加します。ただし、VM起動中にホスト側でUSBデバイスが占有されると競合するため、VM起動前にUSBコントローラーを物理的に切り替えるスイッチの導入や、VM終了時に確実にVM側からUSBを解放するスクリプトの設定が推奨されます。Bluetoothドングルは共有しにくいため、USB接続の有線デバイスを使用するのが確実です。
GPUに内蔵されたHDMI/[DisplayPortオーディオをVMに渡すには、GPUのオーディオ機能(HDAコントローラー)を別々のPCIeデバイスとして認識させ、VMにアタッチする必要があります。NVIDIA RTXシリーズやAMD Radeon RXシリーズは、GPU本体とHDAオーディオが異なるIOMMUグループに属していることが多く、これらを個別にVMに割り当てます。音質面では、VM内のオーディオドライバーがホストのPulseAudioやPipeWireと連携する方式(例:Windows側で「PulseAudio for Windows」を使用)と、直接ASIOドライバー経由でホストのオーディオレイヤーにアクセスする方式があります。低遅延を求めるなら、後者のASIO連携設定が推奨されます。
クラウドゲーミングやブラウザベースの3Dレンダリングの普及により、一部での需要は低下しますが、ローカル環境での完全な制御と低遅延を求める層には、GPUパススルーの需要は2026年以降も持続すると予想されます。特に、AI推論、3Dモデリング、専門的な動画編集など、GPUリソースを独占的に必要とするワークロードでは、仮想化オーバーヘッドのないVFIO環境が不可欠です。また、VMwareやHyper-Vなどの商用仮想化ソフトウェアでもGPUパッシブまたはパッシングのサポートが強化されており、企業環境での採用も増えています。技術的には、SR-IOVなどのより高度な仮想化技術との統合が進むことで、より効率的なリソース共有が可能になるでしょう。
GPUパススルー(VFIO)は、ホストのGPUを仮想マシンに直接割り当てることで、ベアメタル環境と同等のネイティブに近いゲームパフォーマンスを実現する技術です。2026年現在、Intel VT-dおよびAMD-Viに対応した最新のCPUとマザーボードを使用すれば、設定は以前より格段に容易になっています。本ガイドで解説した手順を踏むことで、Proxmox VEやlibvirt環境においても高品質なゲーミングVMを構築可能です。
記事の主要なポイントを下記に整理します。
GPUパススルーの構築は、初期設定に手間がかかりますが、一度確立すれば、仮想化の恩恵を受けながら最高のゲーム性能を享受できます。まずはIOMMUグループの確認から始め、小規模なテスト環境で手順を確立することをお勧めします。仮想化プラットフォームの設定ファイルやドキュメントを参照し、自身の環境に合わせて慎重に調整を進めてください。


