Sharing one GPU across VMs and containers: SR-IOV, vGPU, and the easy way
How to share a single GPU between multiple VMs or containers on Proxmox - the container shortcut, Intel iGPU SR-IOV, NVIDIA vGPU (and the vgpu_unlock route), plus which hardware actually supports it.
You have one GPU and several things that want it - Plex, Jellyfin, Frigate, maybe a small LLM. Can they all share it at once? The honest answer depends entirely on one question you have to settle first: are those workloads in containers, or in separate VMs? Because the two cases are worlds apart in difficulty.
First decide: containers or VMs?
If your services run in containers (Docker, or Proxmox LXC), sharing one GPU is easy and free. Multiple containers can use the same iGPU or GPU at the same time - you just expose the device to each of them:
- Intel / AMD: pass
/dev/driinto each container. One N100 iGPU can feed Plex, Jellyfin, and Frigate together. - NVIDIA: install the NVIDIA Container Toolkit and give each container access to the card; the driver time-slices it across them.
No special hardware, no SR-IOV, no license. This is what most homelabs actually do, and for a single-node Plex + Frigate box it is the right answer. If containers work for you, stop here - you do not need anything below.
The hard case is VMs. A virtual machine wants a whole PCI device to itself (that is what plain "GPU passthrough" gives you - one GPU, one VM). To hand a slice of one GPU to several VMs at once, the card has to be partitioned in hardware or firmware. That is where SR-IOV and vGPU come in, and where your choice of hardware suddenly matters a lot.
What can slice a GPU across VMs
There are three real technologies, and each is tied to specific hardware:
- SR-IOV - the GPU exposes several hardware "virtual functions", each passed to a VM. This is the Intel path (12th-gen and newer iGPUs, and the Data Center Flex cards) and AMD's MxGPU on pro/datacenter cards.
- NVIDIA vGPU - NVIDIA's mediated split. Officially it needs a paid vGPU software licence and a supported datacenter/pro card. Unofficially, the community
vgpu_unlockproject enables it on older consumer and Quadro cards. - GVT-g - Intel's older mediated split for 9th-11th-gen iGPUs. It has been deprecated and dropped from modern kernels, so treat it as gone.
Support matrix
| Hardware | Sharing tech | Multiple VMs | Multiple containers | Home-server note |
|---|---|---|---|---|
| Intel iGPU, 12th gen+ (N100/N150/N305, Iris Xe, Core 12-14, Core Ultra) | SR-IOV (i915-sriov-dkms / Xe) | yes (~7) | yes | The value pick - a whole homelab from one iGPU |
| Intel iGPU, 9th-11th gen (UHD 620/630) | GVT-g (mediated) | deprecated | yes | GVT-g removed in modern kernels - containers only now |
| Intel Arc consumer (A- and B-series) | none | no | yes | Intel restricts SR-IOV to Arc Pro / Flex |
| Intel Data Center Flex 140/170 | SR-IOV (native) | yes | yes | Real native SR-IOV, but pricey and rare for home |
| NVIDIA datacenter/pro (Tesla T4, RTX A-series, RTX Ada pro) | vGPU (licensed) | yes | yes | Official vGPU needs a paid NVIDIA licence |
| NVIDIA older (Tesla P4/P40/P100/M40, Quadro P/T, GTX 10/16, RTX 20) | vGPU via vgpu_unlock |
yes* | yes | Maxwell/Pascal/Turing only; unofficial, grey area |
| NVIDIA GeForce, RTX 30/40 series | none | no | yes | Ampere/Ada consumer: no vGPU and no unlock |
| AMD Instinct / Radeon Pro V / FirePro S | MxGPU (SR-IOV) | yes | yes | Pro/datacenter cards only |
| AMD consumer Radeon | none | no | yes | Single passthrough only |
*grey area - see the vGPU note below.
The Intel iGPU route (the one most people should use)
If you want several VMs to share graphics on Proxmox, a 12th-gen or newer Intel iGPU is the cheapest, cleanest way to do it. An N100/N150/N305, an Iris Xe box, or any 12th-14th-gen Core chip can expose its iGPU as SR-IOV virtual functions - typically up to 7 - so up to seven VMs each get hardware transcode and quick-sync. You enable it with the community i915-sriov-dkms driver today; on Proxmox VE 9.2+ (kernel 7.x) Intel's newer xe driver is bringing native SR-IOV without the DKMS module. Either way you need a matching kernel and the guest driver installed, and the number of virtual functions is fixed when you configure it.
This is genuinely the standout: a fanless ~7W box can hand a real GPU slice to a Plex VM, a Frigate VM, and a couple of others at once. See the N100 mini-PCs and the Iris Xe NUC 13 Pro, and pick the exact generation with the QuickSync-by-generation guide.
The NVIDIA vGPU route (licence or unlock)
NVIDIA's vGPU splits a card across VMs, but it is gated:
- Officially, it needs NVIDIA's paid vGPU software licence and a supported card - the datacenter Tesla/L-series and the professional RTX A-series and RTX Ada cards. That is the sanctioned, supported path, and the licence cost is why almost no homelab takes it.
- Unofficially, the
vgpu_unlockproject enables vGPU on older silicon - Maxwell, Pascal, and Turing - which is why the used Tesla P4 and Tesla P40 are homelab favourites for this. It does not work on Ampere or Ada consumer cards, so a GeForce RTX 30 or 40 series can only be passed whole to a single VM.
So on NVIDIA your realistic multi-VM options are: a used Pascal/Turing card via vgpu_unlock (free but unofficial and fiddly), or a pro RTX A-series/Ada card with a licence (supported but not cheap). Browse the accelerators list to see which cards fall on which side.
The AMD route (rare at home)
AMD's SR-IOV (MxGPU) exists only on specific pro and datacenter cards - FirePro S-series, Radeon Pro V-series, and the Instinct MI accelerators, driven by AMD's GIM driver. Consumer Radeon cards cannot do it and are single-passthrough only. There is no consumer AMD equivalent of the Intel iGPU trick, which is a big reason Intel dominates homelab GPU-sharing.
Practical notes
- Containers first. Before reaching for any of this, ask whether your services can be containers. If yes, share
/dev/dri(Intel/AMD) or use the NVIDIA Container Toolkit and you are done - no SR-IOV, no licence. - The shared slice is still one GPU. SR-IOV or vGPU splits capacity, it does not multiply it. If one iGPU transcodes ~5 streams, seven VMs are dividing those ~5 streams, not getting five each. Size with the transcode calculator.
- Frigate competes for the same silicon. If a box also runs Frigate on the iGPU (OpenVINO), that eats into the transcode budget - size conservatively or add a dedicated detector.
- Kernel matching matters.
i915-sriov-dkmsmust match your running kernel, and it can break on a kernel upgrade; pin your kernel or check the module supports the new one before updating. vgpu_unlockis a grey area. It is unofficial, unsupported by NVIDIA, and can break on driver updates. Fine for a hobby lab, not for anything you need to be reliable.
Picking, in one line each
- Containers only, one node: you need none of this - share
/dev/drior the NVIDIA toolkit. - Several VMs, cheap and clean: a 12th-gen+ Intel iGPU (N100/Iris Xe) with SR-IOV.
- Several VMs, you already own a used Pascal/Turing card:
vgpu_unlock, eyes open. - Several VMs, must be supported/reliable: a pro NVIDIA RTX A-series/Ada card with a vGPU licence, or an Intel Flex.
Start from a box whose iGPU can do it on the mini-PC list, or a card on the accelerators list - each page now flags its GPU-sharing support.