This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
GPU access in VMware is never automatic. Without the correct host configuration, licensing, and VM settings, the guest OS will not see your physical graphics hardware. Whether you need to enable GPU passthrough in VMware ESXi or set up shared access across multiple VMs, the right approach depends on your hypervisor and workload requirements.
This guide covers three methods for enabling GPU access in VMware environments:
Each method has distinct hardware requirements, licensing implications, and use case trade-offs, all covered in the sections below.
By default, VMware ESXi and Workstation rely on a software-emulated SVGA driver. Physical graphics hardware is not exposed to VMs automatically. If you need a VM to handle GPU-intensive tasks, access has to be explicitly configured.
VMware supports three distinct approaches, each suited to different environments and requirements.
GPU Passthrough vs. NVIDIA vGPU vs. Workstation 3D Acceleration
The table below summarizes the key differences.
| Passthrough (DirectPath I/O) | NVIDIA vGPU | Workstation 3D | |
|---|---|---|---|
| Platform | ESXi / vSphere | ESXi + NVIDIA license | VMware Workstation |
| GPU per VM | 1:1 dedicated | 1 GPU, many VMs | Virtual (shared host) |
| CUDA / AI workloads | Full support | C-series profiles only | Not supported |
| VDI / multi-user | No | Yes | No |
| Live VM migration | Not supported | Supported | N/A |
| Cost | Low (hardware only) | High (licensing required) | Low |
| Best for | AI/ML, rendering, HPC | Enterprise VDI, remote work | Dev, testing, light 3D |
Before modifying your virtualization environment, verify that your hardware, host BIOS, hypervisor version, and licenses all meet the necessary requirements. Skipping these checks is the most common reason GPU virtualization setups fail.
To enable GPU access in a VM, your host CPU and motherboard need to support hardware-assisted directed I/O.
Configure your host firmware before VMware can interact with the GPU:
Different VMware versions handle PCIe passthrough differently:
NVIDIA and AMD divide their product lines into consumer and enterprise tiers, which determines virtualization support:
NVIDIA vGPU requires subscription-based licensing in addition to the hardware. The main options are:
Once hardware and licensing are confirmed, you are ready to configure the hypervisor.
GPU passthrough (VMDirectPath I/O) gives a VM direct, exclusive access to a physical PCIe GPU, bypassing the hypervisor’s translation layer entirely. The guest OS sees the card as bare metal, making it suitable for AI/ML, rendering, and CUDA workloads.
Follow these four steps to configure passthrough on your ESXi host and assign the GPU to a VM.
Before a VM can use the GPU, ESXi needs to release control of the PCIe device.
NVIDIA GeForce drivers can detect when they are running inside a VM and refuse to initialize, resulting in a “Code 43” error in the guest OS. Adding this parameter masks the hypervisor’s presence and prevents that error.
lspci | grep -i nvidia
Once the GPU shows up cleanly, your VM is ready for GPU-accelerated workloads.
Unlike passthrough, NVIDIA vGPU lets multiple VMs share a single physical GPU simultaneously. This makes it practical for VDI deployments, engineering clusters, and AI pipelines where assigning a dedicated card per user is not feasible.
1. Log in to the vSphere Client and select your ESXi host.
2. Go to the Configure tab, expand Hardware, and select Graphics.
3. Under Host Graphics, click Edit and set the Default Graphics Type to Shared Direct.
4. Enable SSH on the host and connect via a secure shell client.
5. Put the host into Maintenance Mode:
esxcli system maintenanceMode set --enable true6. Copy the vGPU host driver VIB package to a datastore accessible by the host.
7. Install the driver using the absolute path to the VIB file:
esxcli software vib install -v /vmfs/volumes/your-datastore/NVIDIA-VMware_ESXi_Driver.vibesxcli software vib install is deprecated. Use esxcli software component apply instead. Refer to your NVIDIA vGPU release notes for the exact command syntax.8. Reboot the host, exit Maintenance Mode, and run the following to confirm the driver is loaded:
nvidia-smiUnderstanding NVIDIA vGPU Profile Names
NVIDIA profiles follow a standardized naming convention. For example, NVIDIA A40-4Q breaks down as:
Choosing the Right Workload Class
nvidia-smi
The output should show the assigned virtual profile, its VRAM allocation, and any active processes.
VMware Workstation runs on top of a host OS rather than directly on hardware. This means GPU access works differently from ESXi — and understanding that difference matters before configuring anything.
Workstation does not support PCIe passthrough. This is an architectural limitation of hosted hypervisors, not a configuration gap.
Instead, Workstation uses virtualization translation APIs to provide graphics acceleration:
nvidia-smi in the guest will return no output.
Followings are some common issues and fixes:
Vulkan Renderer Conflict on Dual-GPU Laptops
On laptops with both an integrated Intel GPU and a discrete NVIDIA card, the VM may crash or display a black screen. Add the following parameter to the VM’s .vmx file to disable Vulkan rendering:
mks.enableVulkanRenderer = "FALSE"
Graphical Corruption After a Workstation Update
Flashing windows or misaligned cursors after a Workstation update usually mean the SVGA driver in the guest is out of sync with the new host build. Uninstall VMware Tools from the guest OS, reboot, then reinstall the updated VMware Tools package.
3D Acceleration Option Is Grayed Out
Confirm that hardware virtualization extensions (Intel VT-x or AMD-V) are enabled in your host BIOS/UEFI. Workstation cannot provide hardware-accelerated graphics without these CPU features active.
GPU virtualization involves tight coordination between host hardware, hypervisor, guest OS, and driver stack. The errors below cover the most common failures and how to resolve them.
1. “Passthrough cannot be enabled until host is rebooted” (Status remains “Needs Reboot” after rebooting)
This usually means the ESXi kernel is still holding the GPU for its own console output and has not released it to the passthrough layer.
Fix: Reboot the host, return to PCI Devices, and toggle passthrough off and back on again. If the status still does not change to Active, connect via SSH and run:
esxcli system settings kernel set -s vga -v FALSE
Reboot the host again after running the command and verify the passthrough status.
2. “Module ‘DevicePowerOn’ power on failed” (VM fails to start after adding PCI device)
PCIe passthrough devices require their memory to be pinned in place at all times. By default, ESXi can swap VM memory to disk, which is incompatible with direct device assignment.
Fix: Open Edit Settings for the VM, expand Memory, and check Reserve All Guest Memory (All Locked). Save and power on the VM.
3. GPU driver not detected / Windows Device Manager shows “Code 43”
Consumer GPUs (such as NVIDIA GeForce cards) can detect when they are running inside a VM and disable themselves deliberately.
Fix: Add the following parameter to the VM’s configuration to hide the hypervisor signature from the guest OS:
Go to Edit Settings > VM Options > Advanced > Configuration Parameters > Edit Configuration, then add:
hypervisor.cpuid.v0 = FALSE
Save the settings, power on the VM, and reinstall the GPU driver inside the guest OS.
4. “Module ‘MKS’ power on failed”
This error typically appears when setting up NVIDIA vGPU on a VM that also has VMware’s virtual 3D acceleration (vSGA) enabled. The two conflict at the virtual display layer.
Fix:
The NVIDIA guest driver handles 3D acceleration directly once vSGA is disabled.
5. nvidia-smi returns “No devices were found” in VMware Workstation
This is expected behavior. VMware Workstation does not expose the physical GPU to the guest OS. The VM uses a virtual VMware SVGA 3D adapter instead, which means nvidia-smi, CUDA, and other GPU compute tools will not work inside the guest.
For CUDA or compute workloads, use ESXi with GPU passthrough or NVIDIA vGPU instead.
GPU passthrough blocks vSphere live migration (vMotion). When the VM has a physical PCIe device directly assigned, the standard migration path is unavailable. This becomes a real problem during hardware upgrades, host decommissions, or data center consolidations where these VMs still need to move.
Moving a GPU passthrough VM typically requires powering it down, removing the PCI device assignment, migrating the VM, then reconfiguring passthrough on the new host. For environments running multiple GPU-accelerated workloads, doing this manually at scale is time-consuming and error-prone.
i2Migration is built for exactly these kinds of complex migration scenarios. It supports non-disruptive full machine migration using hybrid block-level and file-level replication, so production workloads keep running during the transfer. Once the migration is complete, GPU passthrough can be reconfigured on the destination host with the system already in place.
For teams also running VMware HA configurations alongside GPU workloads, pairing i2Migration with i2Availability provides a more complete picture: i2Migration handles the one-time move, while i2Availability maintains real-time replication and automatic failover for ongoing high availability protection.
GPU access in VMware comes down to matching the right method to your environment. Passthrough delivers full hardware performance for a single VM. NVIDIA vGPU shares that hardware across multiple users. Workstation 3D acceleration covers development and testing without specialized hardware.
When passthrough VMs eventually need to move, plan ahead. Tools like Info2soft’s i2Migration handle the complexity of migrating GPU-configured workloads across hosts and environments without disrupting production.
