GPU パススルー(VFIO)完全ガイド2026｜Proxmox・libvirt仮想マシンでゲーミング

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パススルーの基本原理とIOMMUグループの理解

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の仮想化エンジンの相互作用を深く理解した上での設定作業となります。

Proxmox VEとlibvirtでの設定手順とハードウェア要件

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ベースの仮想化プラットフォームです。設定は以下の順で行います。

1. BIOS設定: UEFIモードを有効にし、VT-d（Intel）または SVM Mode/AMD-Vi（AMD）を有効にします。また、CSM（Compatibility Support Module）を無効にし、UEFI-onlyモードにすることをお勧めします。
2. GRUBパラメータの編集: /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。
3. 初期ramdiskの更新: update-grub と update-initramfs -u を実行して変更を反映させ、システムを再起動します。
4. VFIOドライバのバインド: 再起動後、lspci -nn | grep -i vga でGPUのIDを確認し、vfio-pci ドライバに強制的にバインドします。これにより、ホスト側の NouveauやNVIDIAドライバーがGPUを制御できなくなります。
5. Proxmox Web UIでの設定: VMの「ハードウェア」タブで「PCIデバイス」を追加し、対象のGPUを選択します。さらに、「オプション」タブで「QEMU ゲーミング エンジン」を有効にし、「ROMバッチ」にGPUのVBIOSファイル（.rom）をマウントします。VBIOSはGPUの初期化に必要なファームウェアで、これが欠如するとVMが起動しないか、エラーを引き起こします。

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とUSBコントローラを分離しやすいため、初心者でも設定が成功しやすい傾向にあります。一方、エントリーチップセットでは、PCIeスロットの物理的な配置とチップセット内部のバス構造により、GPUがUSB 3.0コントローラと同一グループに属するケースが多々あります。この場合、USBパススルーを諦めるか、PCIeスイッチ（例：ASM1184チップ搭載カード）を使用してIOMMUグループを分割する必要があります。

NVIDIA Code 43回避とAMDリセットバグ対策

GPUパススルーで最も頻繁に遭遇する障害は、GPUベンダー固有の保護メカニズムやハードウェアの仕様によるものです。特にNVIDIA製GPUの「Code 43」エラーと、AMD製GPUの「リセットバグ」は、設定を正しく行っても発生する厄介な問題です。

NVIDIA Code 43エラーの回避手順

NVIDIAのドライバーは、VMが仮想環境上で動作していることを検知すると、インストールを中断したり、ディスプレイ出力を止めるなどの保護措置（Code 43エラー）を発動します。これはライセンス保護の仕組みですが、VFIO環境ではこれを回避する必要があります。

回避策として主流なのは、qemu-guest-agent やXML設定により、VMが仮想化環境であることを隠蔽する方法です。具体的には、VMのXML定義に以下の修正を加えます。

1. vendor_idの隠蔽: <cpu> セクションに vendor 属性を追加し、ホストCPUベンダーのID（Intelなら GenuineIntel、AMDなら AuthenticAMD）を強制的に設定します。これにより、VM内のNVIDIAドライバーが「これは物理マシンだ」と誤認します。

2. hypervisorフラグの無効化: <cpu> セクション内で <feature policy='disable' name='hypervisor'/> を追加します。通常、VMはCPUID命令でhypervisorフラグがセットされていることを検知しますが、これを無効にすることで、NVIDIAドライバーが「物理マシン」として認識するようになります。

3. VBIOSの適切な設定: GPUのROMバッチ（VBIOS）を正しくマウントしているか確認します。特に、VBIOSのサイズやフォーマットが正しくない場合、ドライバーの初期化段階でエラーが発生し、結果としてCode 43と同様の症状を引き起こすことがあります。VBIOSはGPUの製造元から公式に公開されている場合もありますが、ない場合は別のVMから抽出する必要があります。

4. ドライバーの更新: NVIDIAは定期的に仮想環境検知の手法を更新しています。最新のドライバー（2026年時点では r570 シリーズ以降）を使用し、設定の変更を反映させることが重要です。

AMD GPUのリセットバグ対策

AMD GPUには、「リセットバグ（Reset Bug）」と呼ばれる問題があります。これは、PCIeリセット（スロットの電源断と再接続）をVMが行った際、GPUが正しく初期化されず、ホスト側でもVM側でも認識しなくなる現象です。AMD Radeon RX 6000シリーズ（RDNA2）やRX 7000シリーズ（RDNA3）の一部で発生が報告されています。

対策として以下の方法があります。

1. 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'
   

2. PCIeリセットの回避: VMの設定で、PCIデバイスへのリセットを抑制するオプションを探します。libvirt/QEMUの場合、<hostdev> タグ内に reset='on' または reset='off' の属性がありますが、ハードウェア依存性が強いため、効果はGPUとマザーボードの組み合わせによります。

3. VBIOSの修正: 一部のAMD GPUでは、VBIOSの一部を修正することでリセットバグを回避できる場合があります。ただし、これは上級者向けであり、VBIOSのバックアップを必ず取ってから行ってください。

4. カーネルパラメータの調整: amd_iommu=on だけでなく、amd_iommu=fullflush や iommu=pt などのパラメータを追加し、IOMMUのパフォーマンスと安定性を調整します。

これらの対策は、GPUパススルーの安定稼働にとって不可欠です。特にNVIDIAユーザーはCode 43対策を、AMDユーザーはリセットバグ対策を、それぞれのGPUモデルに応じて適切に適用する必要があります。

パフォーマンス最適化とLooking Glassによる運用

GPUパススルーで得た高性能を最大限に引き出すには、CPUとメモリの最適化、そして低遅延な入出力環境の構築が不可欠です。単にGPUを割り当てるだけでなく、システム全体の構成をゲーミング向けにチューニングすることで、ベアメタルとほぼ同等の体験が可能になります。

CPU PinningとHugepagesの活用

GPUの演算負荷が高いため、VMのCPUリソースを固定（CPU Pinning）し、ホストOSの他のプロセスと干渉させないことが重要です。

1. CPU Pinning: VMのXML定義で <vcpu> の cpuset 属性を使用し、特定の物理コアにVMのvCPUを固定します。例えば、AMD Ryzen 9 9950Xの場合、コア0-7をホスト用、コア8-15をVM用に割り当てるなどします。これにより、VMの処理が他のコアにスレッドを移動するオーバーヘッドがなくなり、フレームタイムの安定性が向上します。

2. 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程度に抑えられ、ベアメタルと見分けがつかないほどスムーズです。

設定手順は以下の通りです。

1. ホスト側のインストール: LinuxホストにLooking Glassのホスト側コンポーネントをインストールします。

   sudo apt install looking-glass-host
   

2. VM側のインストール: VM内のゲストOS（Windows/Linux）にLooking Glassのゲスト側クライアントをインストールします。

3. VM設定の変更: VMのXML定義で、共有メモリデバイス（/dev/shm/looking-glass）をVMにマウントします。

   <filesystem type='mount' accessmode='passthrough'>
     <source dir='/dev/shm/looking-glass'/>
     <target dir='looking-glass'/>
   </filesystem>
   

4. 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パススルー環境を構築する際、単にGPUを購入するだけでなく、CPU、マザーボード、メモリ、電源といった周辺機器の互換性と性能バランスが全体の安定性とパフォーマンスを決定します。2026年時点で主流となっている構成は、Intel第14世代CoreシリーズやRyzen 9000シリーズといった最新世代のIOMMU対応CPUと、PCIe 5.0対応マザーボードの組み合わせです。本セクションでは、具体的な製品例を用いて、価格帯、スペック、用途、判断基準の4軸で主要な構成要素を比較します。これにより、予算と目的に応じた最適なコンポーネントの選択が可能になります。

主要GPUの価格・スペック・用途比較

GPUパススルーにおいて、ゲストOSとして動作する仮想マシンの用途（ゲーミング、3Dレンダリング、AI推論）によって、推奨されるGPUアーキテクチャと価格帯は大きく異なります。AMD Radeon RX 7000シリーズはOpenCLやVulkanのネイティブなサポートが厚く、VFIOとの親和性が高い一方で、NVIDIA GeForce RTX 40シリーズはCUDAエコシステムの利用者にとって不可欠です。以下の表は、代表的なGPUモデルを比較したものです。

CPUとマザーボードのIOMMU対応比較

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を搭載する場合に有利です。

メモリ構成とHugePages最適化比較

GPUパススルー環境では、ゲストOSのメモリ管理効率を向上させるため、Linuxホスト側でHugePages（巨大ページ）の利用が推奨されます。これにより、TLB（Translation Lookaside Buffer）のミスヒットが減り、メモリアクセスのオーバーヘッドが低下します。また、VMに割り当てるメモリ容量と、ホストOSが確保するHugePagesのサイズ（通常2MBまたは1GB）の設定が、パフォーマンスに直結します。以下の表は、メモリ容量と設定方法の比較です。

電源供給と冷却システムの比較

GPUパススルーでは、GPUがVM内でフル稼働するため、ベアメタル時と同様、あるいはそれ以上に安定した電源供給と冷却が必要です。特に、GPUのPCIeスロットからの給電（最大75W）に加えて、8ピンコネクタによる追加給電が必要となります。高消費電力なGPU（例：RTX 4090）を搭載する場合、電源ユニットの定格出力と、CPU/GPUの瞬時消費電力（Transient Spike）への耐性が重要です。

国内流通とサポート体制の比較

GPUパススルー環境の構築には、ハードウェアの入手可能性とアフターサポートも重要な要素です。特に、BIOSアップデートによるIOMMUグループの修正や、ドライバーの最新化が必要となる場面では、国内でのサポート体制が役立ちます。また、中古市場での価格変動も大きく、時期による購入戦略の違いを理解しておく必要があります。

これらの比較表を参照し、自身の使用環境（Proxmox VEかlibvirtか、メインGPUかサブGPUか、予算はどれくらいか）に合わせてコンポーネントを選択することが、失敗のないGPUパススルー環境構築の第一歩となります。特に、IOMMUグループの確認は購入前に必須であり、マザーボードのレビューやCPUベンチマーク情報で事前に確認しておきましょう。

よくある質問

Q1. GPUパススルーに必要な最低限のPCスペックは？

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通信のボトルネックを最小限に抑えられます。

Q2. Proxmox VEとUbuntu libvirt、どちらが初心者向けですか？

技術的な習得コストを抑えるならProxmox VE、柔軟なカスタマイズを求めるならUbuntu libvirtが適しています。Proxmox VEはWeb GUIでIOMMUグループ確認やVFIOバインド設定が直感的に行えるため、CLI操作に不慣れな方でも比較的容易に構築できます。一方、Ubuntu libvirtはvirshコマンドやXMLファイル編集が必要ですが、Debian系パッケージ管理との親和性が高く、特定のドライバアップデートやカスタムカーネルビルドが必要な上級者向けです。まずはProxmox VEで基本を学び、必要に応じてlibvirtへ移行するのが効率的です。

Q3. NVIDIA GPUのCode 43エラーを回避する方法は？

NVIDIAドライバーが仮想環境を検知してインストールを拒否するCode 43エラーは、GPUのベンダーIDやhypervisorフラグを隠蔽することで回避可能です。Proxmox VEでは、VM設定の「オプション」→「qemuサーバーのプロパティ」でhypervisorフラグを削除するか、vendor_idを空文字列に設定します。libvirt環境では、VMのXML定義に<vendor_id state='on' value='xxxxxxxxxxxx'/>を追加して偽造値を設定します。これにより、NVIDIAドライバーはホスト上の物理GPUとして認識し、正常に動作します。ただし、ドライバーアップデート後に再設定が必要な場合があるため注意が必要です。

Q4. GPUパススルーのパフォーマンス損失はどの程度ですか？

GPUパススルー（VFIO）におけるパフォーマンス損失は、適切に設定された環境では5%未満、一般的には95%以上のベアメタル比が達成可能です。PCIeバス経由の通信オーバーヘッドは微小であり、CPUコアのピン留め（Pinning）やHugePagesの有効化により、さらに1〜2%の改善が見込めます。主要なベンチマーク結果では、NVIDIA GeForce RTX 4090を使用した場合、3DMark Time Spyスコアがベアメタルとほぼ同等となり、ゲーム内のフレームレート変動も最小限に収まります。ただし、ホストOSのリソース競合を防ぐため、CPUとメモリの割り当てには十分な余裕を持たせることが重要です。

Q5. GPUが1枚しかない場合、パススルーは可能ですか？

物理的に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のシャットダウン処理が失敗するとホストがフリーズするリスクがあり、バックアップと慎重な運用が必須です。

Q6. AMD GPUとNVIDIA GPU、どちらが仮想化向けですか？

コストパフォーマンスと設定の容易さを重視するならAMD GPU、高品質なレンダリングやNVIDIA専用ソフトの安定性を求めるならNVIDIA GPUが適しています。AMD Radeon RXシリーズは、VFIO環境でのリセットバグ対策が比較的単純で、オープンソースのamdgpuドライバーがホスト側でも利用しやすいため、初期設定が楽です。一方、NVIDIA GPUはCode 43回避の一手間が必要ですが、CUDA利用やDLSSなどの独自機能を利用できる利点があります。2026年時点で両社ともIOMMUグループの分離性が向上しており、互いに大きな格差はなくなりましたが、NVIDIAの専門ドライバーの安定性は依然として優れています。

Q7. Looking Glassは必要ですか？

ホスト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側でも画面がフリーズします。

Q8. USBデバイス（キーボード・マウス）のパススルー設定は？

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接続の有線デバイスを使用するのが確実です。

Q9. オーディオパススルーはどう設定すればよいですか？

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連携設定が推奨されます。

Q10. 将来的にGPUパススルーは必要なくなりますか？

クラウドゲーミングやブラウザベースの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を構築可能です。

記事の主要なポイントを下記に整理します。

• 必須環境の確保: IOMMU対応CPU（Intel VT-d/AMD-Vi）と、ホスト用とゲスト用の2枚以上のGPU構成が基本です。IOMMUグループの確認は、エラー回避の第一歩となります。
• ドライバーの正しいバインド: vfio-pciドライバーを用いてGPUをホストから解放し、VFIOデバイスとして識別させる手順が不可欠です。これにより、仮想マシンへの独占的なアクセスが可能になります。
• NVIDIA Code 43対策: NVIDIA GPUで発生する「Code 43」エラーは、vendor_idの隠蔽とhypervisorフラグの調整により回避できます。最新のドライバーでは改善されていますが、設定確認は必要です。
• AMD GPUのリセットバグ対策: AMD GPUではリセットバグに注意し、適切なPCIリセット手順を設定することで、クラッシュやフリーズを防ぎます。
• パフォーマンス最適化: CPU Pinning、hugepagesの有効化、IOMMUグループの分割などを適切に行うことで、ベアメタル比95%以上のパフォーマンスを引き出せます。
• 周辺機器と画面出力: Looking Glassによるホスト画面の低遅延共有、USBデバイス（キーボード・マウス）のパススルー、オーディオの処理により、快適なゲーミング体験を提供できます。
• トラブルシューティングの重要性: 起動失敗やパフォーマンス低下の原因は、GRUBパラメータ、BIOS設定、ドライバーバージョンの整合性にあることが多いです。ログ確認と段階的なデバッグが成功への近道です。

GPUパススルーの構築は、初期設定に手間がかかりますが、一度確立すれば、仮想化の恩恵を受けながら最高のゲーム性能を享受できます。まずはIOMMUグループの確認から始め、小規模なテスト環境で手順を確立することをお勧めします。仮想化プラットフォームの設定ファイルやドキュメントを参照し、自身の環境に合わせて慎重に調整を進めてください。