Proxmox vGPU mit NVIDIA: Lizenz-Setup korrekt aufziehen

NVIDIA vGPU auf Proxmox VE ist 2026 endlich ein ausgereiftes Setup. Seit dem offiziellen Support ab Host-Treiber 17.x und der stabilen Integration in Proxmox VE 8.2 lassen sich Ampere- und Ada-Lovelace-Karten wie L40S, L4 oder A16 sauber an virtuelle Desktops und KI-Workloads verteilen. Was in der Praxis regelmäßig Kunden ausbremst, ist nicht die Technik selbst — sondern die Lizenzkette. Ein falsch dimensionierter DLS-Server, ein abgelaufener Token oder das falsche Profil führen dazu, dass Anwender nach 20 Minuten in den eingeschränkten Modus fallen und die VM effektiv unbenutzbar wird.

Dieser Beitrag zeigt, wie Sie eine vGPU-Umgebung auf Proxmox von Grund auf sauber aufsetzen, welche Komponenten wirklich nötig sind und woran typische SMB-Deployments scheitern. Er richtet sich an IT-Verantwortliche, die eine VDI- oder Rendering-Umgebung für 10 bis 100 Nutzer planen.

Die Lizenzkette: Was NVIDIA seit vGPU 17 verlangt

Seit dem Wechsel weg von den alten FlexNet-basierten Lizenzservern läuft die Lizenzierung ausschließlich über den NVIDIA License System (NLS). In der Praxis relevant ist die DLS-Variante (Delegated License Service) — eine Appliance, die im eigenen Rechenzentrum läuft und keine ständige Cloud-Verbindung braucht. Die Alternative CLS (Cloud License Service) ist für SMB-Umgebungen unpraktisch, weil sie einen dauerhaften Internet-Zugang der VMs erzwingt.

Der Ablauf ist konzeptionell einfach, aber jeder Schritt hat seine Tücken:

1. NVIDIA Enterprise Portal: Lizenz-Pool anlegen, Server-Instanz erzeugen, Client-Konfigurations-Token exportieren.
2. DLS-Appliance im eigenen Netz deployen (VM aus dem NVIDIA-Portal, OVA oder qcow2).
3. Token auf die DLS hochladen und die Lizenzen “einchecken”.
4. Guest-VM greift beim Booten des Grafiktreibers auf die DLS zu und holt sich ein Leased License Ticket.

Ein Ticket ist typischerweise 24 Stunden gültig und wird alle 12 Stunden erneuert. Fällt die DLS länger als 20 Minuten weg, verliert die Guest-VM ihren “Licensed”-Status und schaltet auf reduzierte Auflösung sowie Frame-Rate-Limit.

Hardware und Profile: Was passt zu welchem Anwendungsfall

NVIDIA lizenziert vGPU nicht pro Karte, sondern pro concurrent user und Profil-Klasse. Für die Kalkulation lohnt sich ein Blick auf typische Konstellationen aus unseren Kundenprojekten:

Karte	vRAM	Typische Profile	Sinnvolle User/Karte	Anwendungsfall
NVIDIA L4	24 GB	2Q, 4Q, 8Q	3-12	Office-VDI, CAD-Viewing
NVIDIA L40S	48 GB	4Q, 8Q, 16Q	3-12	CAD, KI-Inferenz, Rendering
NVIDIA A16	4x 16 GB	1B, 2B, 4B	16-64	Klassische Office-VDI
NVIDIA H100 NVL	94 GB	24Q, 47Q, 94Q	1-4	KI-Training, LLM-Inferenz

Die Profil-Suffixe entscheiden über die Lizenz-Klasse und die Nutzung:

• B (Virtual PC): Office, Web, leichtes Multi-Monitor. Günstigstes Lizenz-SKU.
• Q (Virtual Workstation): CAD, Adobe, Zertifizierungen für Autodesk/Solidworks.
• C (Compute Server): reine CUDA-Workloads, kein Displayoutput.

Ein häufiger Fehler ist, ein 4Q-Profil für Office-Nutzer zu vergeben, weil “mehr RAM = besser”. Das führt dazu, dass die Karte weniger Nutzer gleichzeitig bedienen kann und Sie die Lizenz-Klasse Virtual Workstation zahlen, obwohl Virtual PC reichen würde.

Host-Setup auf Proxmox VE 8.2

Der Host-Treiber wird nicht aus den Debian-Repositories installiert, sondern manuell aus dem NVIDIA Enterprise Portal geladen. Wichtig ist die exakte Kombination Host-Treiber und Guest-Treiber — die Major-Version muss auf beiden Seiten übereinstimmen.

# Kernel-Header und Build-Umgebung
apt update
apt install -y pve-headers-$(uname -r) build-essential dkms mdevctl

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

# vfio-Module blacklisten für nvidia
echo "blacklist nouveau" > /etc/modprobe.d/blacklist-nouveau.conf
update-initramfs -u
reboot

# Host-Treiber installieren (Beispiel 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

# Verifikation
nvidia-smi
mdevctl types

mdevctl types zeigt die verfügbaren Profile pro physischer GPU. Diese IDs werden später in der VM-Konfiguration referenziert. In Proxmox VE 8.2 lassen sich die Profile über die Web-UI unter “Hardware -> Add -> PCI Device -> Raw Device -> MDev Type” direkt auswählen — vorausgesetzt der Host-Treiber ist korrekt geladen.

DLS-Appliance aufsetzen

Die DLS wird als VM-Image aus dem NVIDIA-Portal geladen (qcow2 oder OVA). Für den Betrieb reicht eine kleine VM mit 4 vCPU, 8 GB RAM, 30 GB Disk. Diese VM sollte in einem Management-Segment liegen, das für alle vGPU-Guests per HTTPS auf Port 443 erreichbar ist.

Wichtige Punkte für die Konfiguration:

• Statische IP oder feste DHCP-Reservation: Der Client-Token enthält die Adresse. Ein Wechsel bedeutet neuen Token-Rollout.
• Zeitsynchronisation via NTP: Token sind zeitbasiert signiert. Ein Drift von mehr als 5 Minuten führt zu Rejection.
• Zwei DLS-Instanzen im HA-Verbund: NVIDIA unterstützt seit NLS 3.x einen aktiven HA-Modus. Für produktive VDI-Umgebungen ist das dringend empfohlen.
• Backup der Configuration Database: Die DLS-Weboberfläche bietet einen Export — ohne Backup ist im Fehlerfall ein kompletter Neu-Rollout inklusive Token nötig.

Nach dem Deployment loggen Sie sich am Portal ein, erzeugen eine Server-Instanz vom Typ “On-Premises DLS”, laden die generierte .dlc-Datei auf die Appliance hoch und weisen dem Server Ihre Lizenzen zu. Der anschließend generierte Client-Konfigurations-Token wird auf allen vGPU-Guests hinterlegt.

Guest-Setup und Token-Verteilung

Im Guest (Windows 11 oder eine unterstützte Linux-Distribution) wird der passende Guest-Treiber installiert — gleiche Major-Version wie Host, aber die “Guest”-Variante. Der Client-Token gehört auf Windows-Systemen unter:

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

Unter Linux:

/etc/nvidia/ClientConfigToken/

Nach einem Neustart des NVIDIA-Display-Diensts bzw. der VM zeigt nvidia-smi -q | grep -A2 License den lizenzierten Zustand. Für einen Rollout auf viele Golden Images empfiehlt sich, den Token in das Base-Image aufzunehmen und die Verteilung über die üblichen Deployment-Werkzeuge zu automatisieren.

Typische Fallstricke aus der Praxis

Die häufigsten Support-Fälle, die wir bei Proxmox-Beratung rund um vGPU sehen, drehen sich nicht um die Hardware:

• DLS nicht erreichbar: Firewall-Regel zwischen VDI-Segment und Management fehlt oder blockiert Port 443. Test mit curl -k https://dls.local:443/ aus der Guest-VM.
• Falsches Profil verhindert Booten: Wenn ein Q-Profil zugewiesen ist, aber die Q-Lizenzen aufgebraucht sind, startet der Grafiktreiber, verliert aber sofort die Lizenz. Die VM wirkt langsam ohne klare Fehlermeldung — ein Blick in das NVIDIA-Eventlog zeigt “License acquisition failed”.
• Token abgelaufen: Der Client-Config-Token hat eine feste Laufzeit (oft 12 Monate). Ein Kalendereintrag mit 30 Tagen Vorlauf spart eine hektische Ticket-Welle.
• Zeitdrift auf DLS oder Guest: Wir haben Fälle gesehen, in denen ein defekter Batteriepuffer im Host zu einer 3-Stunden-Zeitdifferenz führte — die DLS lehnte sämtliche Requests ab.
• Mischbetrieb unterschiedlicher Treiber-Majors: Ein Host mit 17.x und Guest mit 16.x funktioniert nicht. Nach Host-Updates muss jedes Guest-Image nachgezogen werden.

Wenn Ihre vGPU-Umgebung auf gemeinsamem Storage liegt, lohnt sich ein Blick auf schnelles NVMe-Backend — TrueNAS mit NVMe-Tier oder ein lokales ZFS-Mirror-Setup pro Node sind hier bewährte Optionen.

Kostenrahmen für eine typische SMB-VDI-Umgebung

Für eine Beispiel-Umgebung mit 30 Office-Nutzern auf einem Proxmox-Cluster mit einer NVIDIA L4 pro Node:

Position	Größenordnung
NVIDIA L4 (24 GB) pro Host	ca. 2.500-3.000 EUR
vGPU Virtual PC Lizenzen 30 CCU (jährlich)	ca. 3.500-4.500 EUR
DLS-Appliance	in NLS enthalten
NVIDIA Enterprise Support (empfohlen)	ca. 15-20% der Lizenz

Die Lizenzkosten pro Nutzer und Jahr liegen für Virtual PC im Bereich von 130-150 EUR, für Virtual Workstation deutlich höher (ca. 400-500 EUR pro CCU). Diese Preise ändern sich regelmäßig — verlassen Sie sich für konkrete Angebote immer auf ein aktuelles Reseller-Quote.

Fazit

vGPU auf Proxmox ist technisch stabil, die Lizenzkette ist der eigentliche Engpass. Wer DLS von Anfang an redundant plant, Zeitquellen sauber setzt, die Profile am tatsächlichen Bedarf ausrichtet und Token-Ablaufdaten aktiv überwacht, bekommt eine VDI- oder Rendering-Plattform, die ohne wiederkehrende Ausfälle über Jahre läuft. Der Aufwand für ein sauberes Initial-Deployment ist überschaubar — die Kosten für ein schlecht geplantes Rollout mit ständigen Lizenz-Drops sind es nicht.

DATAZONE unterstützt Sie bei Auswahl der passenden Karten, Auslegung der Lizenz-Pools, Aufbau der DLS-Infrastruktur und dem Golden-Image-Rollout auf Proxmox VE 8.2. Von der Bedarfsanalyse bis zum produktiven Betrieb decken wir den gesamten Zyklus ab — inklusive Dokumentation für Ihr Team. Sprechen Sie uns an über Kontakt für ein unverbindliches Erstgespräch zu Ihrem vGPU-Projekt.