Info2softは、ウェブサイトでより快適で適切な閲覧体験を提供するためにCookieを使用しています。 プライバシーポリシー
Loading...
By:
VMware環境でGPUを利用するには自動的な設定は存在しません。ホスト側の適切な設定、ライセンス、仮想マシンの設定が整っていない場合、ゲストOSが物理グラフィックスハードウェアを認識できなくなります。VMware ESXiでGPUパススルーを有効化する場合でも、複数の仮想マシンでGPUを共有する場合でも、適切な手法はハイパーバイザーと業務要件によって異なります。
本ガイドではVMware環境でGPU利用を有効化する3つの手法を解説します。
各手法にはそれぞれ異なるハードウェア要件、ライセンス上の制約、用途ごとのトレードオフが存在し、詳細は後述の各セクションで記載します。
標準状態のVMware ESXiおよびWorkstationはソフトウェアエミュレート型SVGAドライバーを使用しており、物理グラフィックスデバイスは自動的に仮想マシンに公開されません。GPU負荷の高いタスクを仮想マシン上で実行する必要がある場合は、明示的な設定が必須となります。
VMwareは用途・環境に応じて3種類の手法に対応しています。
GPUパススルー vs NVIDIA vGPU vs Workstation 3Dアクセラレーション
下表に主要な相違点をまとめます。
| パススルー（DirectPath I/O） | NVIDIA vGPU | Workstation 3D | |
|---|---|---|---|
| 対応プラットフォーム | ESXi / vSphere | ESXi + NVIDIAライセンス | VMware Workstation |
| VMごとのGPU割当 | 1対1専有 | 1台のGPUを複数VMで共有 | ホストGPUを仮想的に共有 |
| CUDA / AI業務対応 | 完全対応 | Cシリーズプロファイルのみ対応 | 非対応 |
| VDI / マルチユーザー | 不可 | 対応 | 不可 |
| VMライブマイグレーション | 非対応 | 対応 | 該当なし |
| コスト | ハードウェア費のみで低コスト | ライセンス費が追加され高コスト | 低コスト |
| 最適な用途 | AI/機械学習、レンダリング、HPC | 企業VDI、リモートワーク | 開発、検証、簡易3D作業 |
仮想化環境を設定変更する前に、ハードウェア、ホストBIOS、ハイパーバイザーバージョン、ライセンスがすべて必要条件を満たしているか確認してください。これらの確認を怠ることがGPU仮想化設定失敗の最も多い原因です。
VMにGPUアクセスを許可するには、ホストCPUとマザーボードがハードウェア支援型ダイレクトI/Oに対応している必要があります。
VMwareがGPUと連携するために、事前にホストファームウェアを下記通り設定します。
PCIeパススルーの動作仕様はVMwareのバージョンによって異なります。
NVIDIAとAMDは製品ラインをコンシューマー向けとエンタープライズ向けに分けており、仮想化機能の対応可否がこれによって決まります。
NVIDIA vGPUを利用するにはハードウェアとは別にサブスクリプション型ライセンスが必要です。主なライセンス種別は以下の通りです。
ハードウェアとライセンスの要件を確認した後、ハイパーバイザーの設定作業に進めます。
GPUパススルー（VMDirectPath I/O）はVMに物理PCIe GPUを排他的かつ直接利用させ、ハイパーバイザーの変換レイヤーを完全に迂回します。ゲストOSが物理マシンと同じようにGPUを認識するため、AI/機械学習、レンダリング、CUDA業務に適しています。
ESXiホスト側の設定からVMへGPUを割り当てるまでの4ステップを記載します。
VMがGPUを利用するには、事前にESXiがPCIeデバイスの制御権を解放する必要があります。
NVIDIA GeForceドライバーはVM内で実行されていることを検知すると起動を拒否し、ゲストOS上で「Code 43」エラーを発生させます。本パラメータを追加することでハイパーバイザーの存在を隠蔽し、当該エラーを回避できます。
lspci | grep -i nvidia
GPUが正常に認識されたら、当該VMでGPUアクセラレート業務を実行可能な状態となります。
パススルーとは異なり、NVIDIA vGPUは1台の物理GPUを複数のVMが同時に共有することを可能にします。1ユーザーごとに専用GPUを割り当てることが現実的でないVDI環境、エンジニアリングクラスタ、AI処理パイプラインに適しています。
1. vSphereクライアントにログインし、対象ESXiホストを選択
2. 設定タブを開き、ハードウェアを展開してグラフィックスを選択
3. ホストグラフィックス配下の編集をクリックし、標準グラフィックス種別を共有ダイレクトに設定
4. ホストのSSHを有効化し、SSHクライアントで接続
5. ホストをメンテナンスモードに切り替え：
esxcli system maintenanceMode set --enable true6. vGPUホストドライバーのVIBパッケージを、ホストからアクセス可能なデータストアにコピー
7. VIBファイルの絶対パスを指定してドライバーをインストール：
esxcli software vib install -v /vmfs/volumes/任意のデータストア名/NVIDIA-VMware_ESXi_Driver.vibesxcli software vib installコマンドは非推奨。代わりにesxcli software component applyを使用する。正確なコマンド構文はNVIDIA vGPUリリースノートを参照8. ホストを再起動、メンテナンスモードを解除後、下記コマンドを実行しドライバーのロードを確認：
nvidia-smiNVIDIA vGPUプロファイル名の命名規則
NVIDIAのプロファイルには統一された命名ルールが存在します。例えばNVIDIA A40-4Qは下記の要素で構成されます。
用途に合わせたプロファイルクラスの選び方
nvidia-smi
出力結果に割り当てた仮想プロファイル、VRAM割当量、稼働中プロセスが表示されれば正常です。
VMware Workstationはハードウェア直上ではなく、ホストOS上で動作するため、GPUの利用仕様がESXiと大きく異なります。設定作業を行う前にこの違いを理解する必要があります。
WorkstationはPCIeパススルーに対応していません。これはホスト型ハイパーバイザーのアーキテクチャ上の制限であり、設定不備によるものではありません。
代わりにWorkstationは仮想化変換APIを活用してグラフィックスアクセラレーションを提供します。
nvidia-smiを実行しても出力は何も表示されない
頻出するトラブルと対処法を記載します。
デュアルGPUノートPCでVulkanレンダラー競合
内蔵Intel GPUとディスクリートNVIDIAカードを搭載したノートPCでは、VMがクラッシュしたり画面が真っ暗になるケースがあります。VMの.vmxファイルに下記パラメータを追加しVulkanレンダリングを無効化してください。
mks.enableVulkanRenderer = "FALSE"
Workstationアップデート後の画面描画乱れ
ウィンドウのちらつき、カーソル位置ズレが発生する場合は、ゲスト側のSVGAドライバーがホスト新版と不整合を起こしている状態。ゲストOSからVMware Toolsをアンインストール、再起動後、最新版VMware Toolsを再インストールしてください。
3Dアクセラレーションのチェックボックスがグレーアウト
ホストBIOS/UEFI上でハードウェア仮想化拡張機能（Intel VT-xまたはAMD-V）が有効になっているか確認してください。これらのCPU機能が無効だとWorkstationはハードウェア支援型グラフィックスを提供できません。
GPU仮想化はホストハードウェア、ハイパーバイザー、ゲストOS、ドライバースタックが密接に連携する仕組みのため、下記の代表的な障害と解消方法を記載します。
1. 「ホスト再起動後もパススルーを有効化できません」（再起動後もステータスが「再起動必要」のまま）
ESXiカーネルが自身のコンソール出力用にGPUを占有し、パススルーレイヤーに解放できていないことが原因です。
解決策：ホストを再起動し、PCIデバイス画面に戻ってパススルーのオンオフを切り替え直す。状態が「有効」に変わらない場合はSSHで接続し下記コマンドを実行：
esxcli system settings kernel set -s vga -v FALSE
コマンド実行後再度ホストを再起動し、パススルーステータスを確認します。
2. 「モジュール ‘DevicePowerOn’ 起動失敗」（PCIデバイス追加後VMが起動しない）
PCIeパススルーデバイスはVMのメモリを常時物理メモリに固定する必要があります。標準状態のESXiはVMメモリをディスクにスワップ可能なため、デバイス直接割り当てと競合します。
解決策：対象VMの設定の編集を開き、メモリ項目を展開しゲストメモリをすべて予約（ロック）にチェック。保存後VMを起動します。
3. GPUドライバーが検出されない / Windowsデバイスマネージャーに「コード43」が表示される
NVIDIA GeForceなどのコンシューマー向けGPUは、仮想マシン内で動作していることを検知すると、自動的に機能を無効化する仕様になっています。
対処法：仮想マシンの設定にハイパーバイザーのシグネチャーをゲストOSに隠すパラメーターを追加します。
設定の編集＞VMオプション＞詳細＞構成パラメーター＞構成の編集を開き、以下を追加します。
hypervisor.cpuid.v0 = FALSE
設定を保存してVMを起動し、ゲストOS内でGPUドライバーを再インストールしてください。
4. 「モジュール’MKS’の電源起動に失敗しました」
このエラーは、VMwareの仮想3Dアクセラレーション（vSGA）を有効にした状態でNVIDIA vGPUを設定した際に発生しやすいです。仮想ディスプレイレイヤーで競合が起きるためです。
対処法：
vSGAを無効にすると、NVIDIAゲストドライバーが直接3Dアクセラレーションを処理するようになります。
5. VMware Workstation上でnvidia-smiを実行すると「デバイスが見つかりません」と出力される
これは仕様上の正常な動作です。VMware Workstationは物理GPUをゲストOSに公開しません。VMは仮想のVMware SVGA 3Dアダプターを使用するため、nvidia-smiやCUDA、その他GPUコンピュートツールはゲスト内で動作しません。
CUDAやコンピュート処理を利用する場合は、GPUパススルーまたはNVIDIA vGPUを搭載したESXiを使用してください。
GPUパススルーを設定するとvSphereのライブマイグレーション（vMotion）が利用できなくなります。物理PCIeデバイスをVMに直接割り当てているため、標準の移行経路が無効になるからです。サーバー更新、ホスト廃止、データセンター統合といった場面でVMを移行する必要が生じた際に大きな課題となります。
GPUパススルーVMを移行するには通常、VMをシャットダウンしPCIデバイスの割り当てを解除してから移行、移行先ホストで再度パススルー設定を行う手順が必要です。複数のGPUワークロードを運用する環境で、この作業を手動で大規模に実施するには多大な時間を要し、人的ミスも発生しやすくなります。
i2Migrationはこうした複雑な移行シナリオに特化したツールです。ブロックレベルとファイルレベルを組み合わせたハイブリッドレプリケーションによる無停止の完全マシン移行に対応しており、移行中も本番ワークロードを稼働させ続けられます。移行完了後、移行先ホストにシステムを起動した状態でGPUパススルーを再設定可能です。
VMware HAとGPUワークロードを併用する環境では、i2Migrationとi2Availabilityを組み合わせることでより万全な体制を構築できます。i2Migrationは一時的なシステム移行を担い、i2Availabilityは常時レプリケーションと自動フェイルオーバーによる継続的な高可用性を実現します。
VMwareでGPUを利用する際は、環境に適した方式を選択することが重要です。パススルーは1台のVMにフルなハードウェア性能を提供し、NVIDIA vGPUは複数ユーザーでGPUを共有できます。Workstationの3Dアクセラレーションは専用ハードを必要とせず、開発・検証用途に適しています。
パススルー設定のVMを後に移行する必要がある場合は事前に計画を立てましょう。Info2softのi2Migrationといったツールを活用すれば、本番環境を停止させず、GPU設定済みのワークロードをホストや環境間で複雑な手順なしに移行できます。
