Proxmox VE ja és Horizon Ready, però en mode manual: els escriptoris els crees i els apagues tu

Proxmox va anunciar avui, des de Viena, que Proxmox VE ha obtingut la certificació del programa Omnissa Horizon Ready Hypervisor. Titular net: els teus escriptoris virtuals de Horizon ja poden córrer sobre Proxmox. Al mig d'aquesta mateixa frase hi ha tres paraules que decideixen la resta del projecte — Manual Provisioning Mode — i la pàgina del programa les explica sense diplomàcia: «Provisioning and Power policy are Not supported». Horizon et continua lliurant l'escriptori a l'usuari. Crear-lo i apagar-lo passa a ser teu.

Què s'ha certificat, amb la lletra petita al davant

El programa no és una nota de premsa conjunta: és un procediment. Omnissa lliura al fabricant de l'hipervisor els binaris de Horizon i una bateria de casos de prova, el fabricant els executa i envia els resultats, Omnissa els revisa i aprova, i només llavors el producte apareix a la guia de compatibilitat. A canvi, el fabricant pot fer servir el logotip Omnissa Ready — Horizon, i el llistat «significa suport conjunt per als usuaris finals que despleguen el programari del partner certificat amb solucions de Horizon (en mode d'aprovisionament manual)». El parèntesi va a l'original i acota tota la resta.

Tres condicions més, de la mateixa pàgina. La taula de versions suportades pel programa posa Horizon 2506 i superiors: si corres una branca anterior, això encara no va amb tu. L'apartat de requisits diu que «el suport general de Horizon es compra per separat», de manera que la certificació obre la porta que Omnissa t'atengui amb Proxmox a sota, però no et regala el contracte. I a l'apartat de marca, l'estat Partner Ready hi figura com a «Not Eligible»: és una certificació de producte, no una aliança.

Horizon ja havia sortit de vSphere. Per una altra porta i fa nou mesos

Aquest és el context que gairebé cap cobertura de l'anunci posa al costat, i és el que de debò situa la notícia. A Horizon 8 2512, publicat el 16 de desembre del 2025, Omnissa va declarar disponibilitat general del suport per a Nutanix AHV. No en mode manual: amb pools d'escriptoris i granges RDSH automatitzats, aprovisionament sota demanda amb fluxos d'imatge daurada, gestió d'estats d'energia i política d'energia del pool des de la mateixa consola de Horizon, tot a través de Prism Central. És a dir, per API contra l'hipervisor.

Amb això damunt la taula, el que hi ha avui són dos règims diferents de viure fora de vSphere. Un en què Horizon parla amb l'hipervisor i continua fent la seva feina sencera. I un altre, el del programa de certificació, en què Horizon no li demana res a l'hipervisor i es limita a repartir usuaris entre màquines que ja existeixen. Proxmox VE acaba d'entrar al segon. Això no el fa menys útil, però canvia del tot la conversa: no tries entre vSphere i Proxmox, tries quanta operació et quedes tu.

Mode manual, sense adorns

Omnissa ho defineix així: el mode d'aprovisionament manual «permet a Horizon intermediar connexions a càrregues de treball aprovisionades i gestionades fora de les capacitats natives d'automatització de Horizon, com ara màquines virtuals persistents o fins i tot escriptoris físics». I a l'apartat de públic objectiu del programa es descriu la integració com a «hipervisor — Horizon funcionant sobre l'hipervisor sense cap petició d'API per aprovisionar».

Cap petició d'API. No hi ha integració amb l'hipervisor: hi ha un agent dins de cada màquina i un intermediari que reparteix usuaris. És el mateix mecanisme amb què Horizon fa anys que publica un PC físic de l'oficina, i aquesta és alhora la virtut del disseny —funciona amb qualsevol cosa capaç d'arrencar l'agent— i la mesura exacta del que no fa.

Les dues coses que deixen de ser de Horizon

Aprovisionar. En un grup de clons instantanis publiques una imatge mestra i la plataforma fabrica i destrueix escriptoris pel seu compte. En mode manual, la màquina ha d'existir abans que Horizon en sàpiga res: la crees tu a Proxmox —plantilla, clon, cloud-init o sysprep—, li instal·les l'agent i la registres al grup. Quan pedaces la imatge, el cicle de publicar una versió nova i que els escriptoris es refacin sols deixa d'existir i repeteixes el procés a mà.

La política d'energia. Horizon deixa d'encendre la màquina quan l'usuari s'hi connecta i d'apagar-la o suspendre-la quan tanca sessió. Si no ho fa ningú més, els escriptoris estan encesos les vint-i-quatre hores.

El compte que no surt a la nota de premsa

La nota de Proxmox diu que això permet executar els escriptoris d'Omnissa directament sobre Proxmox VE «reduint els costos d'infraestructura sense comprometre el rendiment». A la capa de llicència de l'hipervisor, és cert. Un pis més avall l'aritmètica canvia, i val la pena fer-la amb llapis abans que amb factura.

Posa l'exemple més avorrit possible: 120 escriptoris de 8 GB. Amb política d'energia, el pic de memòria s'assembla a la gent connectada alhora i de nit baixa sol. Sense ella, els 120 existeixen encesos sempre: 960 GB de RAM assignada. Proxmox té dos mecanismes perquè aquesta xifra no sigui la real, i convé saber en quin estat arriba cadascun. El KSM, la deduplicació de pàgines idèntiques, ve activat per defecte —i cent vint Windows iguals donen molt de si—. El ballooning, en canvi, s'ha de configurar: memòria mínima diferent de la màxima a cada màquina i, als convidats Windows, el driver VirtIO Balloon amb el seu servei instal·lat.

I aquí hi ha una decisió que gairebé mai es pren en veu alta, perquè el KSM ve posat i ningú se'l mira. La mateixa documentació de Proxmox adverteix que la deduplicació exposa les màquines a atacs de canal lateral —es pot inferir informació d'una VM des d'una altra al mateix amfitrió— i recomana, literalment, que si fas servir Proxmox VE per donar serveis d'allotjament consideris desactivar el KSM, i afegeix que convé revisar la normativa del país perquè «desactivar KSM pot ser un requisit legal». En un parc d'escriptoris d'una sola empresa el risc és un altre que en un multi-inquilí, però la decisió és teva i es pren per escrit. Es pot afinar per màquina amb l'opció allow-ksm. El que no val és assabentar-se de l'estalvi sense assabentar-se a canvi de què.

Amb GPU el compte s'endureix de cop, i és just l'altre titular de l'anunci. La documentació de Proxmox ho diu sense embuts: si passes un dispositiu PCIe físic o un dispositiu mediat VFIO —que és exactament el que hi ha sota una vGPU—, el ballooning no funciona, perquè aquests dispositius estan mapejats a adreces de memòria fixes. Suma-hi que el perfil vGPU reparteix la memòria de la targeta en porcions i cada màquina encesa reté la seva mentre estigui arrencada. En un parc amb vGPU, l'escriptori de qui és de vacances ocupa el mateix que el de qui està renderitzant, en RAM i en GPU, i allà «els escriptoris no s'apaguen sols» decideix quantes targetes compres.

Tot això es resol, és clar: una apagada programada, una tasca que suspengui el que fa hores sense sessió, polítiques dins del convidat. Però passa de ser una casella en una consola amb suport al darrere a ser codi propi que algú ha de mantenir i que es pot trencar en silenci un divendres.

El que sí que t'emportes

La frase exacta del programa és que suporta «totes les funcions de Horizon disponibles per a dispositius registrats en mode d'aprovisionament manual». Hi entren la intermediació de sessions, el protocol, els agents de Windows i de Linux i l'assignació d'usuaris: l'experiència de qui seu al davant no canvia. I s'hi suma la certificació de NVIDIA vGPU, que no és nova —Proxmox VE és hipervisor suportat per NVIDIA vGPU des del març del 2025— però ara entra a la mateixa casella. El wiki del projecte publica combinacions provades concretes, per exemple Proxmox VE 9.2.10 amb vGPU 20.2, i el seu requisit de suport és doble: un entitlement de NVIDIA vigent i una subscripció de Proxmox de nivell Basic, Standard o Premium.

Al juliol vam dir que un logo no migra la teva infraestructura

Quan Proxmox va entrar a l'ecosistema de NVIDIA Mission Control vam escriure que un logo no migra la teva infraestructura, i ho mantenim: aquell anunci no canviava cap requisit d'arquitectura. Aquest en canvia un, encara que menys del que suggereix el titular. La llista d'hipervisors amb què Horizon s'entén deixa de tenir un sol nom, però s'entén amb cadascun a una profunditat diferent, i és aquesta profunditat —no el llistat— la que decideix quanta gent necessites per operar-ho.

Qui es pot moure avui i qui no

Si els teus escriptoris ja són persistents —enginyeria amb CAD i GPU, llocs de desenvolupament, escriptoris amb programari lligat a la màquina, els trenta llocs d'una nau que fa quatre anys que són la mateixa màquina virtual— el model manual és el que ja operes. Ningú et treu una automatització que no feies servir. La nostra part de la feina en aquests casos ja és aquesta: virtualització d'escriptori i plantilles d'aprovisionament de Windows i Linux per a clients. La diferència és que ara aquest muntatge té un programa al darrere en lloc de ser una decisió que defenses tu sol.

Si en canvi el teu VDI és un grup flotant de clons instantanis, amb centenars d'escriptoris no persistents que neixen al matí i es destrueixen a la nit, no estaries canviant d'hipervisor: estaries canviant una capa d'automatització amb suport per un projecte de scripting propi. Potser tot i així compensa. El que no compensa és descobrir-ho a mig camí. Ja vam escriure amb detall sobre quan no migrar de VMware a Proxmox, i aquest és un d'aquells casos en què la resposta honesta és «encara no».

Les preguntes abans de moure res

1. Quina versió de Horizon corres. Per sota de la 2506, el programa no aplica i la conversa s'atura aquí fins que actualitzis.
2. Quants dels teus grups són manuals avui. Aquesta dada és a la teva consola; no cal estimar-la. És la part del teu VDI que es pot moure sense redissenyar res.
3. Amb què estàs comparant. Si l'alternativa que tens sobre la taula és un hipervisor que Horizon gestiona per API, no compares dues migracions equivalents i el cost operatiu s'ha de posar al full.
4. Qui apaga els escriptoris, amb què i qui ho manté. Si la resposta és «ja ho farem amb un script», això és una tasca amb amo i amb proves.
5. Com arriba un pedaç de la plantilla a les 120 màquines. Sense recomposició automàtica això és gestió de parc, amb l'eina i l'equip que això implica.
6. Si hi ha GPU: entitlement de NVIDIA vigent i subscripció de Proxmox de nivell Basic o superior. És requisit de suport, no que arrenqui. I compta que allà no hi haurà ballooning.
7. La tornada enrere, escrita abans de començar. Amb la xarxa del lloc nou muntada de debò: en migrar a Proxmox, la xarxa la guarda cada node, i un escriptori que arrenca sense la seva VLAN és un escriptori que no existeix.

Aquest últim punt no és un afegitó de cortesia. La finestra per tornar enrere en una migració caduca sola, i en un parc d'escriptoris caduca més ràpid que en un servidor, perquè cada dia que passa hi ha usuaris treballant-hi a sobre. Ho desenvolupem al pla de tornada enrere d'una migració VMware→Proxmox.

El que ha canviat avui

Horizon ja funcionava damunt de Proxmox per a qui s'hi atrevia: màquines persistents, agent a dins, grup manual i sort. El que ha canviat no és que funcioni, sinó que existeix una entrada en una guia de compatibilitat, un procediment de certificació passat i algú amb qui obrir un tiquet quan deixi de funcionar. Dos anys després de la compra de VMware per Broadcom, l'èxode massiu que s'anunciava no ha estat tal: el que hi ha és gent movent-se per peces, a mesura que cada peça es queda sense motius per no moure's. L'escriptori virtual acaba de perdre'n un.

Fonts (consultades el 4 de setembre del 2026): la nota de premsa «Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification», Viena, 4 de setembre del 2026: d'allà surten la certificació «in Manual Provisioning Mode», la frase sobre reduir costos d'infraestructura i el llistat de Proxmox VE com a hipervisor de tercers certificat amb NVIDIA vGPU. Les cites del programa —«Provisioning and Power policy are Not supported», la definició del mode manual, «Hypervisor - Horizon working on Hypervisor without any API request for provisioning», «General support on Horizon is purchased separately», «Partner Ready Status: Not Eligible», el suport conjunt «with Horizon (in Manual Provisioning Mode) solutions» i «all Horizon features that are available for Manual Provisioning Mode registered devices»— són literals de la pàgina del programa Horizon Ready Hypervisor d'Omnissa Tech Zone (traducció nostra on apareixen en català); la versió mínima no és una frase, sinó la taula «Versions supported», on figura Horizon | 2506 and above. Les configuracions verificades es publiquen a la guia de compatibilitat d'hipervisors. El suport de Nutanix AHV en disponibilitat general amb Horizon 8 2512, amb aprovisionament automatitzat i gestió d'energia a través de Prism Central, a l'anunci d'Omnissa del 16 de desembre del 2025. KSM activat per defecte, l'avís de canal lateral, la recomanació de desactivar-lo en serveis d'allotjament, el «disabling KSM may be a legal requirement» i l'opció allow-ksm, a la documentació d'administració de Proxmox VE; els requisits del ballooning i que no funciona amb dispositius PCIe passats o mediats VFIO, a Dynamic Memory Management. Versions provades de vGPU sobre Proxmox VE (9.2.10 amb vGPU 20.2) i els requisits de suport, al wiki de Proxmox VE; Proxmox VE és hipervisor suportat per NVIDIA vGPU des del març del 2025. Omnissa és l'antiga divisió d'End-User Computing de VMware, la venda de la qual a KKR es va tancar l'1 de juliol del 2024. Matís: l'exemple dels 120 escriptoris de 8 GB és un compte nostre amb supòsits explícits per il·lustrar l'efecte de no tenir política d'energia, no un mesurament de cap desplegament.