Il 4 settembre 2026 Proxmox VE è entrato ufficialmente nel programma Omnissa Horizon Ready Hypervisor. È una notizia più importante di quanto sembri, ma anche più facile da interpretare male.
La certificazione non trasforma Proxmox in un sostituto 1:1 di vSphere dentro Horizon. Omnissa certifica il funzionamento in Manual Provisioning Mode: le virtual machine vengono create e gestite fuori dall’automazione nativa di Horizon, poi registrate sul Connection Server tramite Horizon Agent e utilizzate come desktop o RDS host.
Questo significa che oggi Proxmox può essere una piattaforma supportata per eseguire workload Horizon, anche con NVIDIA vGPU. Non significa invece che Horizon possa usare Proxmox come usa vCenter per creare Instant Clone, applicare power policy o gestire il ciclo di vita delle VM.
Ed è proprio questa distinzione a rendere interessante la notizia.
La certificazione: cosa è stato validato
Il programma Horizon Ready Hypervisor nasce per permettere ai produttori di hypervisor terzi di certificare la compatibilità con Horizon 8 nel Manual Provisioning Mode. Omnissa fornisce una serie di test, il vendor li esegue e invia i risultati per la revisione. Una volta approvati, il prodotto viene pubblicato nella compatibility guide e rientra nel modello di joint support previsto dal programma.
Proxmox VE è ora presente in questo programma. Proxmox dichiara inoltre la certificazione per NVIDIA vGPU, quindi una VM Horizon eseguita su Proxmox può utilizzare una vGPU configurata sul layer hypervisor.
Il confine però è chiaro nella documentazione Omnissa: il programma supporta le feature disponibili alle registered devices in Manual Provisioning Mode. Provisioning e Power Policy non sono supportati.
Come funziona Horizon su Proxmox
Con una VM non-vSphere, Horizon non parla con un manager dell’hypervisor per crearla. La macchina deve esistere già.
Il flusso operativo è questo:
- si crea la VM su Proxmox VE, manualmente o tramite una propria automazione;
- si installa e prepara il sistema operativo;
- si installa Horizon Agent;
- l’Agent registra la macchina sul Connection Server;
- in Horizon Console la VM viene utilizzata come registered non-vSphere machine;
- la macchina viene inserita in un manual desktop pool selezionando
Other sources; - Horizon continua a occuparsi di entitlement, brokering e sessione remota.
Dal punto di vista dell’utente l’esperienza può rimanere quella Horizon: Horizon Client, Unified Access Gateway, Connection Server, Blast Extreme e desktop assegnato.
Il punto in cui cambia l’architettura è dietro il desktop. Il lifecycle della VM appartiene al layer Proxmox e ai processi operativi dell’azienda, non a Horizon.
Perché non è ancora un sostituto di vSphere per tutti i VDI
Il confronto diventa evidente quando si guarda a un ambiente basato su Instant Clone.
In un’architettura vSphere, Horizon può partire da una golden image e dal relativo snapshot e utilizzare vCenter per pubblicare l’immagine e creare il pool. La documentazione Omnissa descrive la creazione di VM interne, replica e componenti necessari al processo di Instant Clone.
Nel modello Proxmox certificato oggi questo collegamento non esiste. Horizon non invia a Proxmox una richiesta del tipo “crea 500 desktop da questa immagine”, non accende e spegne le VM attraverso una power policy e non ricrea automaticamente un clone al logoff.
Quindi un ambiente con centinaia o migliaia di desktop non persistenti, aggiornati centralmente tramite golden image e Instant Clone, non può essere migrato limitandosi a cambiare hypervisor.
Serve ridisegnare il provisioning oppure mantenere vSphere per quel workload.
Dove invece Proxmox è già una possibilità concreta
Ci sono scenari Horizon in cui la mancanza di Instant Clone pesa molto meno.
Il primo è quello dei desktop persistenti o dedicati. Se le VM hanno un ciclo di vita relativamente lungo, possono essere provisionate su Proxmox con template, API, Terraform, Ansible o altri strumenti e poi registrate in Horizon.
Il secondo riguarda i manual desktop pool. Omnissa supporta assignment dedicato e floating anche per registered machines, pur con alcune differenze rispetto alle VM vSphere gestite direttamente.
Il terzo è RDS. Horizon consente manual farm composte da RDS host già esistenti e la documentazione specifica che questi host possono essere VM vSphere, macchine fisiche oppure VM non-vSphere. Questo apre la strada a Windows Server su Proxmox con Horizon Agent, published desktop e published application.
Il quarto è il VDI con GPU. Proxmox VE è stato certificato anche come Horizon Ready Hypervisor con NVIDIA vGPU. La configurazione della GPU, però, resta responsabilità dell’hypervisor e dello stack NVIDIA: le opzioni 3D Renderer tipiche dei pool vSphere non sono disponibili nei manual pool di registered non-vSphere machines.
La matrice reale delle feature
| Funzione | vSphere gestito da Horizon | Proxmox in Manual Provisioning Mode |
|---|---|---|
| Horizon Agent | Sì | Sì |
| Connection brokering | Sì | Sì |
| Manual desktop pool | Sì | Sì |
| Manual RDS farm / published apps | Sì | Sì |
| NVIDIA vGPU | Sì | Sì, certificata |
| Power policy gestita da Horizon | Sì | No |
| 3D Renderer configurato da Horizon Console | Sì | No |
| Automated full-clone provisioning | Sì | No |
| Instant Clone | Sì | No |
Questa tabella è probabilmente il modo più semplice per leggere la notizia. La compatibilità riguarda il piano di accesso e delivery del desktop. L’automazione del compute rimane separata.
Il punto interessante: Proxmox ha già gli strumenti per automatizzare
Qui nasce una domanda architetturale più interessante.
Proxmox VE dispone già di REST API, template, linked clone, Terraform/OpenTofu, Ansible e procedure di automazione. Il problema quindi non è l’assenza assoluta di strumenti per creare VM. È l’assenza, oggi, di una integrazione nativa tra il lifecycle Horizon e quello Proxmox equivalente al rapporto Horizon-vCenter.
Un’azienda può costruire un proprio processo:
golden image -> automation -> clone Proxmox -> customization -> Horizon Agent -> registration -> pool
È tecnicamente possibile, ma cambia la responsabilità operativa. Devi gestire tu naming, capacity, cleanup, aggiornamenti, stato delle VM e coerenza tra inventory Proxmox e inventory Horizon.
Per 30 desktop persistenti può essere perfettamente ragionevole. Per 3.000 desktop non persistenti il problema assume un’altra dimensione.
Anche le published application diventano interessanti
La possibilità di usare VM non-vSphere nelle manual farm rende Proxmox rilevante anche fuori dal classico desktop Windows 11.
Si possono creare RDS host su Proxmox, installare Horizon Agent, registrarli e inserirli in una manual farm. Da quella farm Horizon può pubblicare desktop multi-session e applicazioni.
È un caso d’uso potenzialmente importante per aziende che usano Horizon soprattutto come application delivery platform e non dipendono dall’automazione Instant Clone.
Anche qui la separazione è netta: Horizon gestisce sessioni e brokering; Proxmox e il team infrastrutturale gestiscono la vita della VM.
vGPU cambia il tipo di workload che si può valutare
La certificazione NVIDIA vGPU evita che la discussione resti confinata al task worker VDI.
Proxmox include il supporto a NVIDIA vGPU tra le proprie funzioni compute. Con Horizon, una VM non-vSphere può usare direttamente la GPU resa disponibile al guest dal third-party hypervisor. Per una workstation virtuale grafica, quindi, il flusso può essere:
GPU fisica -> profilo vGPU -> VM Proxmox -> Horizon Agent -> Blast Extreme -> utente
Il sizing, i profili vGPU, il licensing NVIDIA e l’assegnazione delle risorse restano sul layer Proxmox/NVIDIA.
È una differenza importante rispetto a vSphere, ma non rende il workload meno reale. Semplicemente sposta la responsabilità del controllo.
La certificazione arriva nello stesso momento in cui cambia anche il supporto Proxmox
Due giorni prima dell’annuncio Omnissa, Proxmox ha annunciato l’estensione del supporto enterprise a copertura 24/7.
Dal 19 ottobre 2026 il piano Premium prevede copertura continua, ticket illimitati e risposta prioritaria entro due ore per i casi critici. Il piano Standard passerà alla copertura 24/7 entro la fine del 2026. Il supporto riguarda Proxmox VE, Backup Server e Datacenter Manager.
Proxmox dichiara inoltre più di 2,3 milioni di server PVE attivi nel mondo e oltre 60.000 aziende con un piano di supporto attivo.
Questi numeri vengono dal vendor e vanno letti come tali. Il dato interessante per chi fa architecture assessment è però un altro: supporto h24, escalation vendor e certificazioni con software enterprise sono requisiti che spesso entrano direttamente nelle RFP e nelle policy interne.
La certificazione Horizon e il nuovo supporto 24/7 rimuovono due obiezioni che in passato potevano fermare la valutazione prima ancora del PoC.
Non significa che il business case sia automaticamente migliore
Il costo dell’hypervisor è solo una parte del TCO di un ambiente VDI.
Se per sostituire l’automazione Horizon-vCenter devo sviluppare e mantenere pipeline di provisioning, procedure di cleanup, image lifecycle e monitoring aggiuntivo, quella complessità ha un costo.
Allo stesso modo bisogna verificare storage, backup, HA, operations, competenze interne, hardware certification, support model e processi di incident escalation.
Per questo eviterei la conclusione “Proxmox costa meno quindi conviene”. La domanda corretta è quanto valore stiamo ottenendo dalle funzioni integrate che perderemmo e quanto è realmente complesso ricostruirle nel nostro scenario.
Tre scenari che valuterei in modo diverso
Persistent VDI da qualche decina o centinaio di VM. Proxmox oggi è una possibilità concreta. Il provisioning può essere separato da Horizon e l’assenza di Instant Clone può avere un impatto gestibile.
RDS e published applications. È probabilmente uno dei casi più interessanti. Manual farm e VM non-vSphere sono già un modello previsto da Horizon.
Large scale non-persistent VDI. Qui vSphere mantiene un vantaggio sostanziale nell’integrazione nativa con Horizon. Instant Clone, golden image lifecycle e automazione del pool non sono dettagli operativi: sono parte dell’architettura.
Il segnale che leggerei dietro l’annuncio
Per anni Proxmox è stato spesso escluso dalle valutazioni enterprise con obiezioni preliminari: supporto, certificazioni vendor, ecosistema e integrazioni.
La certificazione Horizon non elimina le differenze con vSphere. Al contrario, le rende molto più facili da misurare.
Adesso possiamo fare una domanda più utile: per questo specifico workload, quali funzioni vSphere-Horizon utilizziamo realmente e quali possiamo spostare sul layer Proxmox o su un’automazione esterna?
Se la risposta include soprattutto brokering, desktop persistenti, RDS e vGPU, Proxmox è diventato difficile da ignorare.
Se la risposta è un ambiente pesantemente basato su Instant Clone e gestione automatica delle immagini, oggi la distanza rimane evidente.
Ed è forse proprio questo il vero passo avanti: non dover più decidere se Proxmox sia “enterprise” in astratto. Possiamo finalmente discutere, workload per workload, se soddisfa i requisiti reali.