Horizon auf Proxmox: was die Zertifizierung trägt — und was nicht

/01Was „Horizon Ready" für Proxmox VE bedeutet

Omnissa Horizon läuft seit dem 4. September 2026 offiziell auf Proxmox VE — allerdings nur im Manual Provisioning Mode. Horizon vermittelt dort Verbindungen zu Desktops, die Sie selbst anlegen, einschalten und pflegen; die Automatik, die Horizon unter vSphere ausmacht, gibt es auf Proxmox nicht.

Die Proxmox Server Solutions GmbH hat an diesem Tag gemeldet, dass Proxmox VE im Programm „Omnissa Horizon Ready Hypervisor" zertifiziert ist; im selben Programm ist Proxmox VE als Drittanbieter-Hypervisor mit Unterstützung für NVIDIA vGPU geführt. Das Programm selbst beschreibt Omnissa auf seiner Tech-Zone-Seite: Hypervisor-Hersteller führen einen vorgegebenen Satz an Testfällen aus, Omnissa prüft die Ergebnisse und trägt das Produkt in den Kompatibilitätsleitfaden ein. Der Eintrag bedeutet laut Omnissa „joint support" — gemeinsamen Support für Kunden, die das zertifizierte Produkt mit Horizon im Manual Provisioning Mode betreiben. Unterstützt werden Horizon-Versionen ab 2506.

Was die Zertifizierung nicht ist: keine Integration, bei der Horizon den Proxmox-Cluster über eine Schnittstelle steuert. Omnissa formuliert die Zielgruppe des Programms als „Horizon working on Hypervisor without any API request for provisioning". Und weiter, ohne Spielraum: „Provisioning and Power policy are Not supported." Es ist auch kein Ersatz für eine Horizon-Lizenz — Omnissa weist darauf hin, dass der allgemeine Horizon-Support getrennt gekauft wird.

Technisch ging das nämlich schon vorher. Die Horizon-Dokumentation hält fest, dass Horizon 8 manuelle Pools „on any non-vSphere capacity" unterstützt, und nennt als Beispiele Hyper-V, Azure Native und Nutanix AHV. Neu ist für Proxmox-Betreiber also nicht die Machbarkeit, sondern die Gewissheit, dass ein Ticket bei Omnissa nicht mit dem Hinweis auf eine ungeprüfte Plattform zurückkommt.

/02Manual Provisioning Mode: Horizon ohne vCenter

Horizon kennt zwei Welten. In der ersten ist vCenter angebunden: Horizon klont aus einem Golden Image ganze Pools, schaltet Desktops nach Bedarf ein und aus, verteilt neue Images im laufenden Betrieb. In der zweiten registrieren sich Maschinen selbst beim Connection Server, während der Installation des Horizon Agent — Omnissa nennt sie „registered machines". Für diese Maschinen gibt es nur einen Pool-Typ: den manuellen Desktop-Pool mit der Quelle „Other sources".

Omnissa beschreibt die Grenze dieses Pool-Typs selbst nüchtern: Im Vergleich zu automatisierten Pools habe ein manueller Pool „limited features", und Horizon verwalte den Lebenszyklus der Desktops darin nicht. Konkret heißt das auf Proxmox: Sie legen jede Desktop-VM an, treten sie der Domäne bei, installieren den Agent, und erst dann taucht sie unter Settings > Registered Machines > Others in der Horizon Console auf und kann einem Pool zugeordnet werden.

Was Horizon in diesem Modus weiterhin leistet, ist der eigentliche Kern einer VDI-Lösung auf Nutzerseite: Anmeldung, Berechtigungen, Verbindungsvermittlung über Connection Server und gegebenenfalls Unified Access Gateway, das Blast-Protokoll, Umleitungen für USB, Drucker und Laufwerke, die Zuordnung Benutzer zu Maschine. Die Bedienoberfläche für die Anwender ändert sich durch den Wechsel des Hypervisors nicht. Das ist der Grund, warum das Modell für Bestandskunden überhaupt attraktiv ist.

/03Was gegenüber vSphere fehlt: Instant Clones, Power Policy, Lebenszyklus

Die folgende Tabelle stellt gegenüber, was ein Horizon-Betreiber unter vSphere gewohnt ist und was im Manual Provisioning Mode auf Proxmox übrig bleibt. Die Spalte „Horizon auf Proxmox" folgt der Omnissa-Tabelle „Desktop Pool Settings for Manual Pools" für registrierte Maschinen; die Spalte „Ersatz" beschreibt, wie wir die Lücke im Betrieb schließen würden — das ist unsere Bewertung, keine Herstelleraussage.

Die gewichtigste Zeile ist die erste. Omnissa beschreibt die Vorteile von Instant Clones selbst: Sie entstehen schnell, sind beim Anlegen bereits eingeschaltet, erledigen Anpassung und Domänenbeitritt im ersten Startvorgang, und ein Pool lässt sich „in a rolling process with zero downtime" patchen. Genau dieses Verfahren — ein Image pflegen, alle Desktops davon ableiten, nach dem Patch neu ableiten — ist der Grund, warum große Horizon-Umgebungen mit wenig Personal auskommen. Auf Proxmox entfällt es.

Die Proxmox-eigenen Linked Clones sind dafür kein Ersatz. Laut Proxmox-Dokumentation entsteht ein solcher Klon „nearly instantaneous" aus einer schreibgeschützten Vorlage und verweist weiter auf deren Daten. Horizon weiß davon aber nichts: Es gibt keinen Mechanismus, der nach einem Patch der Vorlage die abgeleiteten Desktops neu erzeugt und die Benutzer dabei mitnimmt. Das müssten Sie selbst bauen.

/04Einrichtung: Desktop-VM, Horizon Agent und Registrierung

Der Ablauf ist bei jeder Desktop-VM derselbe, und genau deshalb lohnt es sich, ihn zu skripten. Auf Proxmox-Seite entsteht der Desktop aus einer vorbereiteten Vorlage; auf Horizon-Seite wird er vorregistriert und meldet sich bei der Agent-Installation an. Für Windows-Desktops braucht die Vorlage die VirtIO-Treiber, einen Gast-Agent und — für Windows 11 — ein virtuelles TPM.

# Proxmox: Desktop aus Vorlage 9000 klonen (Full Clone, eigenständige VM)
qm clone 9000 4101 --name vdi-cad-01 --full 1 --storage ceph-vm
qm set 4101 --tags vdi,horizon --onboot 1
qm start 4101

# Prüfen, welche Desktops laufen
qm list | grep vdi
#  4101 vdi-cad-01   running   16384   128.00   12345
#  4102 vdi-cad-02   stopped   16384   128.00       0

Wir nehmen für Horizon-Desktops den Full Clone, nicht den Linked Clone. Ein Linked Clone bindet die VM dauerhaft an die Vorlage — Proxmox lässt das Löschen einer Vorlage nicht zu, solange davon abgeleitete Klone existieren —, und weil Horizon den Lebenszyklus nicht steuert, wird aus dem Platzvorteil auf Dauer eine Abhängigkeit, die niemand mehr überblickt. Den zusätzlichen Platz eines Full Clone auf Ceph nehmen wir dafür bewusst in Kauf.

Für die Registrierung bietet Horizon seit Version 2512 die sogenannte Machine Credential Pairing. Die Maschine wird vorher in der Horizon Console unter Settings > Registered Machines > Ready to Pair über ihr Active-Directory-Computerkonto eingetragen; die Agent-Installation braucht dann kein Administratorkennwort mehr in der Befehlszeile. Voraussetzungen laut Omnissa: Domänenmitgliedschaft, Connection Server und Agent ab 2512, Windows 10 oder 11 (64 Bit) oder Windows Server 2019, 2022 oder 2025.

# Windows-Desktop: Horizon Agent unbeaufsichtigt, ohne vCenter,
# Connection Server automatisch finden (Maschine vorher "Ready to Pair")
agent-installer.exe /s /v"/qn VDM_VC_MANAGED_AGENT=0 VDM_PAIRING_MECHANISM=2 ADDLOCAL=Core,ThinPrint,USB,RTAV,ClientDriveRedirection"

# Erwartung: nach Abschluss und Neustart erscheint die Maschine in der
# Horizon Console unter Settings > Registered Machines > Others
# und kann einem manuellen Desktop-Pool zugeordnet werden.

Der Schalter, auf den es ankommt, ist VDM_VC_MANAGED_AGENT=0. Omnissa nennt ihn ausdrücklich Pflicht: Der Wert 0 richtet den Agent für Maschinen ein, die nicht von vSphere verwaltet werden. Eine Falle liegt gleich daneben: Die Reparaturfunktion des Installers ist für eine nicht verwaltete Installation laut Omnissa nicht unterstützt — wer „Reparieren" wählt, bekommt wieder einen vCenter-verwalteten Agent. Bei Problemen also deinstallieren und neu installieren, nicht reparieren.

Die ältere Variante mit VDM_PAIRING_MECHANISM=1 verlangt VDM_SERVER_NAME, VDM_SERVER_USERNAME und VDM_SERVER_PASSWORD. Das funktioniert, legt aber das Kennwort eines Horizon-Administrators in Skripte und Softwareverteilung. Wo Version 2512 verfügbar ist, gibt es dafür keinen Grund mehr.

/05Patchen und Bereitstellen ohne Instant Clones

Ohne Instant Clones ist jeder Desktop ein eigener Server. Das ist keine Formsache, sondern die eigentliche Betriebslast dieses Modells: Monatliche Windows-Updates, Anwendungsupdates und Treiberstände müssen auf jede VM einzeln, so wie auf einen physischen Arbeitsplatz. Die Werkzeuge dafür sind dieselben wie für Notebooks — WSUS, Intune oder eine Softwareverteilung —, nur dass die Geräte im Rechenzentrum stehen und nachts erreichbar sind.

Daraus folgt eine Entscheidung, die vor dem ersten Desktop fallen sollte: persistent oder nicht. Persistente Desktops (dedizierte Zuweisung, der Nutzer behält „seine" VM) passen zum Manual Provisioning Mode, weil der Lebenszyklus ohnehin bei Ihnen liegt. Nicht persistente Desktops, die bei jeder Abmeldung verworfen werden, sind ohne Instant Clones mühsam: Sie müssten das Zurücksetzen selbst bauen, etwa über eine Proxmox-Snapshot-Rücksetzung nach Abmeldung, und Profile und Nutzerdaten konsequent auslagern.

Was wir in der Praxis skripten

• Bereitstellung: Klon aus Vorlage, Name und Tag setzen, Start, Domänenbeitritt und Agent-Installation per Startskript — ein Lauf pro neuem Arbeitsplatz.
• Vorlagenpflege: Die Vorlage bekommt monatlich dieselben Updates wie die Desktops. Sonst startet jeder neue Desktop mit einem Rückstand, der erst beim nächsten Patchlauf aufgeholt wird.
• Bestandsabgleich: Einmal pro Woche Abgleich zwischen den VMs mit dem Tag vdi auf Proxmox und den registrierten Maschinen in Horizon. Abweichungen sind fast immer verwaiste VMs nach Personalwechseln.

# Bestand: alle VDI-Desktops im Cluster mit Knoten und Zustand
pvesh get /cluster/resources --type vm --output-format json \
  | jq -r '.[] | select((.tags // "") | test("vdi")) | [.vmid, .name, .node, .status] | @tsv'
# 4101  vdi-cad-01  pve01  running
# 4102  vdi-cad-02  pve02  stopped

Gesichert werden die Desktops wie jede andere VM. Mit dem Proxmox Backup Server fallen bei vielen nahezu gleichen Windows-Installationen durch die Deduplizierung deutlich weniger Daten an als die Summe der Plattengrößen vermuten lässt — wie viel, hängt an Ihrer Umgebung und lässt sich nur messen.

/06NVIDIA vGPU unter Horizon auf Proxmox

Für grafiklastige Arbeitsplätze ist der vGPU-Teil der Pressemitteilung der wichtigere. Das Proxmox-Wiki hält fest: „Beginning with NVIDIA vGPU Software 18, Proxmox Virtual Environment is an officially supported platform." Die Kompatibilitätstabelle dort führt Proxmox VE 8.4 und die 9er-Reihe bis 9.2 mit jeweils passenden vGPU-Zweigen und Kerneln. Für Support-Fälle verlangt Proxmox laut Wiki sowohl eine NVIDIA-vGPU-Berechtigung als auch eine Proxmox-Subskription der Stufe Basic, Standard oder Premium.

Die vGPU wird auf Proxmox an der VM eingerichtet, nicht in Horizon. Bei Ampere- und neueren Karten muss vorher SR-IOV aktiv sein; Proxmox liefert dafür einen eigenen systemd-Dienst, weil das NVIDIA-Skript allein Neustarts nicht überlebt. Die Zuweisung eines Profils sieht so aus:

# SR-IOV für alle unterstützten NVIDIA-Karten dauerhaft aktivieren
systemctl enable --now pve-nvidia-sriov@ALL.service

# Verfügbare vGPU-Typen auf einer virtuellen Funktion abfragen
pvesh get /nodes/pve01/hardware/pci/0000:01:00.4/mdev

# Profil an Desktop-VM 4101 hängen (Typ laut Abfrage oben)
qm set 4101 -hostpci0 01:00.4,mdev=nvidia-660

Fünf Grenzen, die im Projekt auffallen und im Wiki stehen:

• Konsole: Die eingebaute noVNC- oder SPICE-Konsole von Proxmox zeigt das vGPU-Bild nicht. Für die Fehlersuche braucht es einen Fernzugang im Gast — bei Horizon ohnehin vorhanden, aber nicht, wenn der Agent selbst das Problem ist.
• Schnellstart: Unter Windows 10 und 11 muss der Schnellstart abgeschaltet sein, sonst startet die VM nach einem hybriden Herunterfahren unter Umständen nicht mehr.
• Lizenz im Gast: Ohne per NTP synchronisierte Uhrzeit kann der Gast keine NVIDIA-Lizenz anfordern.
• Kartenmodus: Manche Workstation-Karten müssen mit NVIDIAs Display Mode Selector umgestellt werden; die Anzeigeausgänge sind danach abgeschaltet.
• Kein KI-Stapel: NVIDIA AI Enterprise ist auf Proxmox VE laut Wiki nicht offiziell unterstützt — wer dieselben Karten für KI-Arbeit teilen will, plant das getrennt.

Eine Lücke ist in den Quellen nicht beantwortet: ob eine VM mit vGPU unter Proxmox im laufenden Betrieb auf einen anderen Knoten wandern kann. Das Wiki äußert sich dazu nicht. Für die Planung gehen wir davon aus, dass vGPU-Desktops für Wartungsfenster heruntergefahren werden müssen, bis Proxmox oder NVIDIA etwas anderes dokumentieren. Wie sich Profile auf Karten verteilen, zeigt unsere Seite zum GPU-Pooling in virtuellen Desktops.

/07Wo es hakt: Umzug, Energie und Support-Kette

Umzug bestehender Desktops von vSphere

Instant-Clone-Pools lassen sich nicht sinnvoll umziehen — die Klone sind flüchtig und entstehen aus dem Golden Image. Umzuziehen ist das Image selbst oder, bei persistenten Desktops, jede einzelne VM. Proxmox bringt dafür einen Import-Assistenten mit, der VMs direkt von ESXi übernimmt und den größten Teil der Konfiguration abbildet. Zwei Punkte aus der Proxmox-Migrationsanleitung treffen VDI besonders: Der Zustand eines virtuellen TPM lässt sich von VMware nicht nach Proxmox übertragen — bei Windows-11-Desktops mit BitLocker müssen die Wiederherstellungsschlüssel vorher gesichert sein. Und die MAC-Adressen ändern sich, wenn man sie nicht ausdrücklich übernimmt.

Dazu kommt der Agent: Ein Desktop, der unter vCenter lief, hat einen verwalteten Horizon Agent. Auf Proxmox muss er als nicht verwalteter Agent neu installiert werden, wie in Abschnitt /04 beschrieben. In der Praxis ist es bei Desktops oft schneller, aus einer frischen Vorlage neu bereitzustellen und nur die Nutzerdaten mitzunehmen, als jede VM einzeln zu importieren und nachzuarbeiten. Wie der Hypervisor-Wechsel insgesamt abläuft, beschreibt unser Beitrag zu VMware-Alternativen und Proxmox VE.

Energie: Desktops laufen rund um die Uhr

Weil die Power Policy entfällt, schaltet Horizon keinen Desktop aus, wenn sich niemand anmeldet, und keinen ein, wenn jemand kommt. Ohne eigenes Zutun laufen alle VMs Tag und Nacht. Bei Office-Desktops ist das vor allem Arbeitsspeicher, der belegt bleibt; bei vGPU-Desktops ist es Grafikspeicher, der für andere Profile fehlt. Ein zeitgesteuertes Herunterfahren nach Dienstschluss und Hochfahren vor Arbeitsbeginn ist mit qm shutdown und qm start schnell gebaut — es ist aber ein Behelf ohne Kenntnis, ob gerade jemand angemeldet ist. Wer das sauber will, fragt vor dem Abschalten die Sitzungen im Gast ab.

Wer hilft, wenn es klemmt

„Joint support" heißt: Omnissa und Proxmox sprechen miteinander. Es heißt nicht, dass ein Anbieter den ganzen Stapel verantwortet. Ein typisches Ticket „Bildschirm bleibt schwarz" kann am Horizon Agent, am NVIDIA-Gasttreiber, an der vGPU-Lizenz, am Proxmox-Host oder am Netz liegen — vier Hersteller, vier Verträge. Wer heute einen VMware-Partner hat, der alles aus einer Hand betreut, verliert diese Einheit beim Wechsel, wenn er sie nicht bewusst neu ordnet.

/08Horizon, RDS oder DaaS: Entscheidung nach Arbeitsplatzzahl

Horizon auf Proxmox steht nie allein zur Wahl. Daneben stehen der klassische Terminalserver mit Remote Desktop Services — viele Nutzer teilen sich ein Server-Betriebssystem — und ein betriebener virtueller Desktop als Dienst (DaaS), bei dem Sie Arbeitsplätze beziehen statt eine Plattform zu betreiben. Die Zahl der Arbeitsplätze verschiebt die Rechnung, weil im Manual Provisioning Mode der Aufwand linear mit jeder VM wächst.

Die Zahl der Nutzer je Terminalserver in der zweiten Zeile ist eine Annahme zur Veranschaulichung — sie hängt an Anwendung, Arbeitsspeicher und Nutzerverhalten und kann deutlich darüber oder darunter liegen. Der Kern der Tabelle bleibt davon unberührt: Bei RDS patchen Sie Hosts, bei Horizon im Manual Provisioning Mode patchen Sie Arbeitsplätze.

Die Entscheidungslogik

• Wenn eine Horizon-Lizenz noch läuft, die Nutzer persistente Desktops haben und vSphere ohnehin abgelöst wird — dann ist Horizon auf Proxmox der Weg mit der geringsten Änderung für die Anwender.
• Wenn die Anwendungen auf einem Terminalserver laufen und niemand eine eigene Maschine braucht — dann ist RDS günstiger im Betrieb, unabhängig vom Hypervisor. Wie man einen Terminalserver nach einem fehlgeschlagenen Update wieder zum Laufen bringt, steht im Beitrag zum RDS-Notfallplan.
• Wenn Grafik, Isolation oder Softwarekonflikte eine eigene VM je Nutzer verlangen, aber niemand eine Horizon-Lizenz hat — dann braucht es keinen Broker zu kaufen: Eine VM je Nutzer mit RDP oder NoMachine reicht.
• Wenn Sie bei 300 Arbeitsplätzen Instant Clones intensiv nutzen und das Team klein ist — dann sollten Sie den Wechsel auf Proxmox für die VDI-Schicht zurückstellen, bis Sie die Bereitstellung automatisiert haben, und die Server-Schicht zuerst umziehen.

/09Für wen sich Horizon auf Proxmox lohnt

Am meisten gewinnt, wer gerade VMware ablöst, eine laufende Horizon-Lizenz hat und den Anwendern keinen neuen Client zumuten will. Für diese Gruppe ist die Zertifizierung tatsächlich ein Fortschritt: Bisher hing an der Kombination das Risiko, im Fehlerfall ohne Herstellerunterstützung dazustehen. Das ist mit dem Eintrag im Kompatibilitätsleitfaden vom Tisch, sofern Horizon ab 2506 läuft.

Es lohnt sich auch für Umgebungen mit wenigen, aber anspruchsvollen Desktops — Konstruktion, Bildbearbeitung, Simulation —, die ohnehin persistent sind und für die die fehlenden Instant Clones kaum ins Gewicht fallen. Hier zählt vGPU auf einem gemeinsamen On-Premise-Cluster mehr als die Pool-Automatik.

Irrelevant ist das Thema für Sie, wenn Sie kein Horizon einsetzen. Wer heute über virtuelle Desktops nachdenkt, ohne eine Horizon-Lizenz zu besitzen, sollte nicht wegen dieser Zertifizierung einsteigen: Er bezahlt einen Broker, dessen stärkste Funktionen auf Proxmox nicht verfügbar sind. Und wer bereits mit RDS zufrieden ist, hat durch die Nachricht keinen Anlass zum Handeln.

Ehrlich: Die Zertifizierung macht Horizon auf Proxmox unterstützbar, nicht bequem. Wer mit Instant Clones groß geworden ist, wird den Komfort vermissen. Wer persistente Desktops betreibt, verliert dagegen weniger, als die Schlagzeile befürchten lässt — vorausgesetzt, Patch-Management und Bestandsabgleich sind organisiert, bevor der erste Desktop umzieht. Wie die Desktop-Frage nach dem Supportende von Windows 10 aussieht, behandelt unser Beitrag zu Windows 10 ESU, Terminalserver und DaaS.

/10Häufige Fragen