You use GPUs with VMware or Proxmox VMs through either PCIe passthrough, which dedicates a whole physical GPU to a single VM, or vendor virtualization technology like NVIDIA vGPU, which splits a physical GPU into multiple virtual GPUs shared across several VMs. On Proxmox, PCIe passthrough requires enabling IOMMU in the host BIOS and kernel boot parameters, blacklisting the GPU's driver on the hypervisor host so it does not claim the device, and then assigning the GPU directly to a VM's configuration, after which the guest OS installs its own NVIDIA driver as if it had a physical GPU. VMware supports the same passthrough approach through its DirectPath I/O feature, and additionally offers NVIDIA vGPU support through vSphere for organizations licensed for it, letting multiple VMs share a single physical GPU with driver-level isolation rather than requiring one VM per GPU. vGPU requires an NVIDIA vGPU software license and GPUs from the supported list, generally data center cards like the L40S, H100, or RTX PRO 6000 rather than older or unsupported workstation cards. Passthrough gives near-native performance but ties a GPU to one VM, while vGPU trades some overhead for multi-tenant flexibility. Nanobase AI configures both passthrough and vGPU deployments depending on whether a customer needs full GPU performance or multi-tenant density.
Two different models, two different trade-offs
PCIe passthrough dedicates an entire physical GPU to a single virtual machine, while NVIDIA vGPU splits one physical GPU into multiple virtual GPUs shared across several VMs with driver-level isolation. The choice is not about which is "better" but about whether a workload needs a whole GPU's performance in one VM, favoring passthrough, or needs several VMs to share GPU capacity with reasonable isolation, favoring vGPU, which requires a supported card and a software license.
Setting up passthrough on Proxmox
- Enable IOMMU in the host BIOS (Intel VT-d or AMD-Vi) and add the corresponding kernel boot parameter (
intel_iommu=onoramd_iommu=on) to the bootloader configuration. - Blacklist the GPU's driver on the Proxmox host itself so the hypervisor does not claim the device before the VM can, typically by adding the GPU's PCI vendor and device ID to a
vfio-pcimodule configuration. - Reboot and confirm the GPU appears bound to
vfio-pcirather than the NVIDIA driver usinglspci -k. - Add the PCI device to the target VM's configuration, enabling PCIe passthrough for that specific device.
- Boot the VM and install the NVIDIA driver inside the guest OS exactly as if it had a physical GPU, since the guest has no visibility into the underlying hypervisor.
- Validate with
nvidia-smiinside the guest to confirm the GPU is recognized and reporting expected memory and clock values.
vGPU profiles on VMware
VMware supports the same passthrough approach through DirectPath I/O, and additionally offers NVIDIA vGPU through vSphere for organizations holding the appropriate license, letting multiple VMs share one physical GPU with the vendor driver enforcing isolation between them rather than relying on the hypervisor alone.
| vGPU profile pattern | Memory per VM | Typical fit |
|---|---|---|
| Full-size profile | Entire GPU memory | Single demanding VM, near-passthrough performance |
| Half-size profile | Half of GPU memory | Two VMs sharing one GPU |
| Quarter-size profile | Quarter of GPU memory | Four lighter VMs, e.g. dev workstations or small inference |
| Smallest supported profile | Minimum vendor-defined allocation | Many low-demand VMs, VDI-style density |
vGPU requires GPUs from NVIDIA's supported list, generally data center cards such as the L40S, H100, or RTX PRO 6000 rather than older or unsupported workstation parts, and the corresponding vGPU software license tier.
Pitfalls that catch teams off guard
Passthrough ties a GPU to one VM at the hardware level, which breaks live migration for that VM since migration requires moving to hardware with an equivalent device already bound and available, a real constraint for organizations relying on vMotion or its Proxmox equivalent for maintenance windows. Guest and host driver versions need careful alignment, particularly for vGPU, where the vGPU manager component on the hypervisor and the guest driver inside each VM must be compatible versions from the same release train, and mismatches produce initialization failures that look like a hardware problem. IOMMU grouping can also block passthrough of a single GPU if it shares an IOMMU group with unrelated devices on the motherboard, sometimes requiring a BIOS update or PCIe slot change to isolate the GPU into its own group.
Frequently asked questions
Does GPU passthrough work with consumer GPUs on Proxmox?
Technically often yes for compute workloads, though NVIDIA's licensing terms for consumer GeForce cards generally restrict their use in virtualized data center environments, so production deployments should use data center-class cards licensed for the intended use case.
Can a VM with passthrough GPU be resized later?
No, passthrough assigns a specific physical device, so changing GPU allocation means reconfiguring the VM to a different physical GPU rather than resizing an existing allocation, unlike vGPU profiles which can sometimes be changed with a VM restart.
Is vGPU performance close to passthrough?
A full-size vGPU profile using the entire GPU memory allocation performs close to passthrough, while smaller profiles trade proportional performance and memory for higher VM density on the same physical hardware.
How Nanobase AI helps
Nanobase AI configures both PCIe passthrough and NVIDIA vGPU deployments on Proxmox and VMware depending on whether a customer needs full GPU performance for a single workload or multi-tenant density across several VMs, including driver version alignment and IOMMU topology validation before go-live.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.