Proxmox vGPU with NVIDIA: Getting the License Setup Right

NVIDIA vGPU on Proxmox VE has finally matured in 2026. With official support from host driver 17.x and stable integration in Proxmox VE 8.2, Ampere and Ada Lovelace cards like the L40S, L4 or A16 can be cleanly distributed to virtual desktops and AI workloads. What regularly slows customers down in practice is not the technology itself, but the license chain. A poorly sized DLS server, an expired token or the wrong profile causes users to drop into restricted mode after 20 minutes, making the VM effectively unusable.

This article shows how to build a vGPU environment on Proxmox from the ground up, which components you really need, and where typical SMB deployments go wrong. It is aimed at IT decision-makers planning a VDI or rendering environment for 10 to 100 users.

The license chain: what NVIDIA requires since vGPU 17

Since the move away from the old FlexNet-based license servers, licensing runs exclusively through the NVIDIA License System (NLS). In practice the relevant flavour is DLS (Delegated License Service) — an appliance that runs in your own data center and does not need a permanent cloud connection. The alternative CLS (Cloud License Service) is impractical for SMB environments because it requires all VMs to have constant internet access.

The flow is conceptually simple, but every step has its traps:

1. NVIDIA Enterprise Portal: create a license pool, generate a server instance, export the client configuration token.
2. Deploy the DLS appliance on your own network (VM from the NVIDIA portal, OVA or qcow2).
3. Upload the token to the DLS and “check in” the licenses.
4. The guest VM contacts the DLS when the graphics driver boots and picks up a Leased License Ticket.

A ticket is typically valid for 24 hours and renewed every 12 hours. If the DLS is unreachable for more than 20 minutes, the guest VM loses its “Licensed” state and drops to reduced resolution and a frame rate limit.

Hardware and profiles: matching the use case

NVIDIA does not license vGPU per card, but per concurrent user and profile class. It is worth looking at typical constellations from our customer projects for capacity planning:

Card	vRAM	Typical profiles	Reasonable users/card	Use case
NVIDIA L4	24 GB	2Q, 4Q, 8Q	3-12	Office VDI, CAD viewing
NVIDIA L40S	48 GB	4Q, 8Q, 16Q	3-12	CAD, AI inference, rendering
NVIDIA A16	4x 16 GB	1B, 2B, 4B	16-64	Classic office VDI
NVIDIA H100 NVL	94 GB	24Q, 47Q, 94Q	1-4	AI training, LLM inference

The profile suffixes decide the license class and usage:

• B (Virtual PC): Office, web, light multi-monitor. Cheapest license SKU.
• Q (Virtual Workstation): CAD, Adobe, certifications for Autodesk/Solidworks.
• C (Compute Server): pure CUDA workloads, no display output.

A common mistake is assigning a 4Q profile to office users because “more RAM equals better”. The result: the card serves fewer concurrent users and you pay for the Virtual Workstation license class even though Virtual PC would be enough.

Host setup on Proxmox VE 8.2

The host driver is not installed from the Debian repositories — it must be downloaded manually from the NVIDIA Enterprise Portal. The exact combination of host driver and guest driver matters: the major version has to match on both sides.

# Kernel headers and build environment
apt update
apt install -y pve-headers-$(uname -r) build-essential dkms mdevctl

# Enable IOMMU (Intel example)
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="quiet"/GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"/' /etc/default/grub
update-grub

# Blacklist nouveau
echo "blacklist nouveau" > /etc/modprobe.d/blacklist-nouveau.conf
update-initramfs -u
reboot

# Install host driver (example version 17.5)
chmod +x NVIDIA-Linux-x86_64-550.144.03-vgpu-kvm.run
./NVIDIA-Linux-x86_64-550.144.03-vgpu-kvm.run --dkms

# Verification
nvidia-smi
mdevctl types

mdevctl types lists the available profiles per physical GPU. These IDs are referenced later in the VM configuration. In Proxmox VE 8.2 the profiles can be selected directly in the web UI under “Hardware -> Add -> PCI Device -> Raw Device -> MDev Type”, provided the host driver is loaded correctly.

Setting up the DLS appliance

The DLS is downloaded as a VM image from the NVIDIA portal (qcow2 or OVA). A small VM with 4 vCPU, 8 GB RAM and 30 GB disk is enough. This VM should live in a management segment reachable from all vGPU guests via HTTPS on port 443.

Key configuration points:

• Static IP or fixed DHCP reservation: the client token contains the address. Changing it means a fresh token rollout.
• Time synchronization via NTP: tokens are signed with a timestamp. Drift of more than 5 minutes leads to rejection.
• Two DLS instances in HA: since NLS 3.x NVIDIA supports an active HA mode. Strongly recommended for production VDI.
• Backup of the configuration database: the DLS web UI offers an export. Without a backup a failure means a full redeployment including token rollout.

After deployment log in to the portal, create a server instance of type “On-Premises DLS”, upload the generated .dlc file to the appliance and assign your licenses to the server. The client configuration token generated afterwards has to be placed on all vGPU guests.

Guest setup and token distribution

In the guest (Windows 11 or a supported Linux distribution) the matching guest driver is installed — same major version as the host, but the “Guest” variant. On Windows the client token belongs under:

C:\Program Files\NVIDIA Corporation\vGPU Licensing\ClientConfigToken\

On Linux:

/etc/nvidia/ClientConfigToken/

After restarting the NVIDIA display service or rebooting the VM, nvidia-smi -q | grep -A2 License shows the licensed state. For rollout to many golden images we recommend baking the token into the base image and automating distribution through your usual deployment tooling.

Common pitfalls from the field

The most frequent support cases we see at Proxmox consulting around vGPU are almost never hardware related:

• DLS unreachable: firewall rule between VDI segment and management segment is missing or blocks port 443. Test with curl -k https://dls.local:443/ from inside the guest VM.
• Wrong profile blocks operation: if a Q profile is assigned but Q licenses are exhausted, the graphics driver starts and immediately loses the license. The VM feels sluggish with no clear error — the NVIDIA event log shows “License acquisition failed”.
• Expired token: the client config token has a fixed lifetime (often 12 months). A calendar reminder 30 days ahead saves a hectic wave of tickets.
• Time drift on DLS or guest: we have seen cases where a failing CMOS battery in the host caused a 3-hour time delta — the DLS refused every request.
• Mixing different driver majors: a host on 17.x with a guest on 16.x will not work. After host updates every guest image has to be updated too.

If your vGPU environment lives on shared storage, a fast NVMe backend is worth looking at — TrueNAS with an NVMe tier, or a local ZFS mirror per node, are proven options.

Cost frame for a typical SMB VDI environment

For a sample environment with 30 office users on a Proxmox cluster with one NVIDIA L4 per node:

Item	Order of magnitude
NVIDIA L4 (24 GB) per host	approx. 2,500-3,000 EUR
vGPU Virtual PC licenses 30 CCU (yearly)	approx. 3,500-4,500 EUR
DLS appliance	included in NLS
NVIDIA Enterprise Support (recommended)	approx. 15-20% of license

License costs per user and year land around 130-150 EUR for Virtual PC and significantly higher for Virtual Workstation (approx. 400-500 EUR per CCU). These prices change regularly — always rely on a current reseller quote for concrete offers.

Conclusion

vGPU on Proxmox is technically stable; the license chain is the actual bottleneck. Anyone who plans the DLS redundantly from the start, sets time sources cleanly, sizes profiles to real demand and actively monitors token expiry gets a VDI or rendering platform that runs for years without recurring outages. The effort for a clean initial deployment is modest — the cost of a poorly planned rollout with constant license drops is not.

DATAZONE supports you with picking the right cards, sizing the license pools, building the DLS infrastructure and rolling out golden images on Proxmox VE 8.2. From requirements analysis to production operation we cover the full cycle — including documentation for your team. Reach out via contact for a no-obligation initial call about your vGPU project.