How to Partition Your GPU on Proxmox: Share One NVIDIA Card with Multiple VMs

Table of Contents

The Problem: One GPU, Too Many Tasks

We’ve all been there. You just shelled out $400 for a solid NVIDIA RTX card, only to realize it’s tied to a single Windows VM. You want that card to handle a Windows gaming instance, an AI server running Ollama, and a Plex media server for hardware transcoding—all at the same time.

Usually, we rely on PCIe Passthrough. This gives 100% of the hardware to one Virtual Machine (VM), but it locks everyone else out. If your Windows VM is idling, that GPU power is just sitting there wasting electricity. Partitioning changes the game by letting you slice one physical card into several virtual ones, making your HomeLab significantly more efficient.

Comparing Approaches: Passthrough vs. Partitioning

Choosing the right method depends on whether you value raw power or high hardware utilization. Here is how the two technologies stack up in a real-world Proxmox environment.

PCIe Passthrough (The 1:1 Method)

How it works: The host OS completely ignores the GPU and hands the entire PCI address to a single VM.
Performance: You get roughly 98% of native bare-metal speed.
Limitation: It is an all-or-nothing deal. Only one VM can access the hardware.

vGPU Partitioning (The 1:N Method)

How it works: A specialized driver splits the GPU into multiple “Mediated Devices” (mdev). Each VM sees its own smaller NVIDIA card with a dedicated portion of VRAM.
Performance: Shared based on your profile. For example, you can split a 12GB RTX 3060 into three 4GB instances.
Limitation: Setup is more hands-on and requires bypassing NVIDIA’s software locks on consumer-grade cards.

Pros and Cons of vGPU Partitioning

Before you dive into the command line, consider if the benefits outweigh the maintenance requirements for your specific setup.

Pros:

Better ROI: Run a Windows desktop and a headless AI server simultaneously on one card.
Lower Power Bills: One GPU running three tasks consumes far less idle power than three separate cards.
Dynamic Scaling: You can assign a small 2GB profile to a Linux container and a larger 8GB profile to a gaming VM.

Cons:

Setup Hurdles: You must patch the kernel and use community scripts to trick consumer drivers into enabling enterprise features.
Fragility: Proxmox kernel updates can sometimes break the vGPU mapping, requiring a driver reinstall.

Recommended Hardware and Prerequisites

Enterprise cards like the Tesla P4 or T4 support this out of the box. However, most users prefer using RTX or GTX cards they already own. This guide focuses on NVIDIA architectures like Pascal, Turing, and Ampere.

Host: Proxmox VE 8.x (ensure you are on a stable kernel).
GPU: NVIDIA GTX 10-series, RTX 20/30/40-series, or Tesla P4/P40.
BIOS: Enable VT-d (Intel) or AMD-Vi (AMD) along with Above 4G Decoding and SR-IOV.

Step-by-Step Implementation

Follow these steps to turn your standard RTX card into a multi-instance powerhouse.

1. Prepare the Proxmox Host

To start, we need to enable IOMMU and tell the kernel to load the VFIO modules. Open your GRUB configuration:

nano /etc/default/grub

Modify the GRUB_CMDLINE_LINUX_DEFAULT line. For Intel users, it should look like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

Apply the changes and add the modules to your system configuration:

update-grub
echo "vfio" >> /etc/modules
echo "vfio_iommu_type1" >> /etc/modules
echo "vfio_pci" >> /etc/modules
echo "vfio_virqfd" >> /etc/modules

2. Install Dependencies and vGPU Unlocker

NVIDIA normally restricts vGPU features to expensive Quadro and Tesla cards. To bypass this on a GeForce card, we use the vGPU-ProxMox scripts. These tools allow a consumer card to report itself as an enterprise model.

Grab the build essentials and the specific headers for your Proxmox kernel:

apt update
apt install -y build-essential dkms pve-headers-$(uname -r) git

Clone the community-maintained unlocker tool. Always check the repository for the latest compatibility notes regarding Proxmox 8:

git clone https://github.com/it-proste/vGPU-ProxMox.git
# Follow the script instructions to prepare the host environment

3. Install the NVIDIA vGPU Manager

You will need a specific version of the NVIDIA vGPU Manager driver. While these are typically found in the NVIDIA Enterprise portal, many users locate the required .run files through community mirrors.

Install the driver on your host with the unlocker active:

chmod +x NVIDIA-Linux-x86_64-xxx.xx-vgpu-kvm.run
./NVIDIA-Linux-x86_64-xxx.xx-vgpu-kvm.run --dkms

Reboot your machine and run nvidia-smi. If the driver is working, you will see your GPU details. Next, verify that the virtual profiles are available:

ls /sys/class/mdev_bus/0000:01:00.0/mdev_supported_types/

Note: Replace 0000:01:00.0 with your actual GPU PCI ID found via lspci.

4. Assigning vGPU to a Windows VM

Now that the host is ready, head over to the Proxmox Web UI to configure your VM:

Navigate to your Windows VM and click Hardware.
Click Add -> PCI Device.
Select your GPU and choose an MDev Type. A profile like nvidia-259 usually provides a 2GB framebuffer.
Check Primary GPU if you intend to use this for gaming or a remote desktop.

Crucially, you must install the NVIDIA vGPU Guest Driver inside the Windows VM. Standard GeForce drivers will fail to initialize. The guest driver version must match the host manager version exactly.

5. Setting up the AI Server (Linux VM)

Adding AI capabilities is just as simple. Assign a vGPU profile to your Linux VM (Ubuntu 22.04 works best). Inside the guest, install the NVIDIA utility and the Container Toolkit:

# Inside the Linux Guest
sudo apt install nvidia-utils-xxx
sudo apt install nvidia-docker2
sudo systemctl restart docker

This allows you to run a Large Language Model (LLM) in a Docker container while your Windows VM simultaneously handles a heavy video export.

Final Thoughts on vGPU

While the setup isn’t a simple “one-click” affair, the efficiency gains are massive. My own HomeLab went from three power-hungry GPUs down to a single RTX 3060. This one card now powers my daily Windows workstation, a stable diffusion lab, and my media server without breaking a sweat.

If your VM fails to start with an “MDEV” error, check that the nouveau driver is blacklisted on the host. Also, ensure your kernel headers haven’t drifted from your running version. Once you get this running, you will never go back to the limitations of standard passthrough.