Proxmox VE ya es Horizon Ready, pero en modo manual: los escritorios los creas y los apagas tú

Proxmox anunció hoy, desde Viena, que Proxmox VE ha obtenido la certificación del programa Omnissa Horizon Ready Hypervisor. Titular limpio: tus escritorios virtuales de Horizon ya pueden correr sobre Proxmox. En medio de esa misma frase hay tres palabras que deciden el resto del proyecto — Manual Provisioning Mode — y la página del programa las explica sin diplomacia: «Provisioning and Power policy are Not supported». Horizon te sigue entregando el escritorio al usuario. Crearlo y apagarlo pasa a ser tuyo.

Qué se ha certificado, con la letra pequeña delante

El programa no es una nota de prensa conjunta: es un procedimiento. Omnissa entrega al fabricante del hipervisor los binarios de Horizon y una batería de casos de prueba, el fabricante los ejecuta y manda los resultados, Omnissa los revisa y aprueba, y solo entonces el producto aparece en la guía de compatibilidad. A cambio, el fabricante puede usar el logotipo Omnissa Ready — Horizon, y el listado «significa soporte conjunto para los usuarios finales que despliegan el software del partner certificado con soluciones de Horizon (en modo de aprovisionamiento manual)». El paréntesis va en el original y acota todo lo demás.

Tres condiciones más, de la misma página. La tabla de versiones soportadas por el programa pone Horizon 2506 y superiores: si corres una rama anterior, esto todavía no va contigo. El apartado de requisitos dice que «el soporte general de Horizon se compra por separado», así que la certificación abre la puerta a que Omnissa te atienda con Proxmox debajo, pero no te regala el contrato. Y en el apartado de marca, el estado Partner Ready figura como «Not Eligible»: es una certificación de producto, no una alianza.

Horizon ya había salido de vSphere. Por otra puerta y hace nueve meses

Este es el contexto que casi ninguna cobertura del anuncio pone al lado, y es el que de verdad sitúa la noticia. En Horizon 8 2512, publicado el 16 de diciembre de 2025, Omnissa declaró disponibilidad general del soporte para Nutanix AHV. No en modo manual: con pools de escritorios y granjas RDSH automatizados, aprovisionamiento bajo demanda con flujos de imagen dorada, gestión de estados de energía y política de energía del pool desde la propia consola de Horizon, todo a través de Prism Central. Es decir, por API contra el hipervisor.

Con eso encima de la mesa, lo que hay hoy son dos regímenes distintos de vivir fuera de vSphere. Uno en el que Horizon habla con el hipervisor y sigue haciendo su trabajo entero. Y otro, el del programa de certificación, en el que Horizon no le pide nada al hipervisor y se limita a repartir usuarios entre máquinas que ya existen. Proxmox VE acaba de entrar en el segundo. Eso no lo hace menos útil, pero cambia por completo la conversación: no estás eligiendo entre vSphere y Proxmox, estás eligiendo cuánta operación te quedas tú.

Modo manual, sin adornos

Omnissa lo define así: el modo de aprovisionamiento manual «permite a Horizon intermediar conexiones a cargas de trabajo aprovisionadas y gestionadas fuera de las capacidades nativas de automatización de Horizon, como máquinas virtuales persistentes o incluso escritorios físicos». Y en el apartado de público objetivo del programa se describe la integración como «hipervisor — Horizon funcionando sobre el hipervisor sin ninguna petición de API para aprovisionar».

Ninguna petición de API. No hay integración con el hipervisor: hay un agente dentro de cada máquina y un intermediario que reparte usuarios. Es el mismo mecanismo con el que Horizon lleva años publicando un PC físico de la oficina, y esa es a la vez la virtud del diseño —funciona con cualquier cosa capaz de arrancar el agente— y la medida exacta de lo que no hace.

Las dos cosas que dejan de ser de Horizon

Aprovisionar. En un grupo de clones instantáneos publicas una imagen maestra y la plataforma fabrica y destruye escritorios por su cuenta. En modo manual, la máquina tiene que existir antes de que Horizon sepa de ella: la creas tú en Proxmox —plantilla, clon, cloud-init o sysprep—, le instalas el agente y la registras en el grupo. Cuando parcheas la imagen, el ciclo de publicar una versión nueva y que los escritorios se rehagan solos deja de existir y repites el proceso a mano.

La política de energía. Horizon deja de encender la máquina cuando el usuario se conecta y de apagarla o suspenderla cuando cierra sesión. Si no lo hace nadie más, los escritorios están encendidos las veinticuatro horas.

La cuenta que no sale en la nota de prensa

La nota de Proxmox dice que esto permite ejecutar los escritorios de Omnissa directamente sobre Proxmox VE «reduciendo los costes de infraestructura sin comprometer el rendimiento». En la capa de licencia del hipervisor, es cierto. Un piso más abajo la aritmética cambia, y merece la pena hacerla con lápiz antes que con factura.

Pon el ejemplo más aburrido posible: 120 escritorios de 8 GB. Con política de energía, el pico de memoria se parece a la gente conectada a la vez y por la noche baja solo. Sin ella, los 120 existen encendidos siempre: 960 GB de RAM asignada. Proxmox tiene dos mecanismos para que esa cifra no sea la real, y conviene saber en qué estado llega cada uno. El KSM, la deduplicación de páginas idénticas, viene activado por defecto —y ciento veinte Windows iguales dan mucho de sí—. El ballooning, en cambio, hay que configurarlo: memoria mínima distinta de la máxima en cada máquina y, en los invitados Windows, el driver VirtIO Balloon con su servicio instalado.

Y aquí hay una decisión que casi nunca se toma en voz alta, porque el KSM viene puesto y nadie lo mira. La propia documentación de Proxmox advierte de que la deduplicación expone las máquinas a ataques de canal lateral —se puede inferir información de una VM desde otra en el mismo anfitrión— y recomienda, literalmente, que si usas Proxmox VE para dar servicios de alojamiento consideres desactivar el KSM, añadiendo que conviene revisar la normativa del país porque «desactivar KSM puede ser un requisito legal». En un parque de escritorios de una sola empresa el riesgo es otro que en un multi-inquilino, pero la decisión es tuya y se toma por escrito. Se puede afinar por máquina con la opción allow-ksm. Lo que no vale es enterarse del ahorro sin enterarse de a cambio de qué.

Con GPU la cuenta se endurece de golpe, y es justo el otro titular del anuncio. La documentación de Proxmox lo dice sin rodeos: si pasas un dispositivo PCIe físico o un dispositivo mediado VFIO —que es exactamente lo que hay debajo de una vGPU—, el ballooning no funciona, porque esos dispositivos están mapeados a direcciones de memoria fijas. Súmale que el perfil vGPU reparte la memoria de la tarjeta en porciones y cada máquina encendida retiene la suya mientras esté arrancada. En un parque con vGPU, el escritorio de quien está de vacaciones ocupa lo mismo que el de quien está renderizando, en RAM y en GPU, y ahí «los escritorios no se apagan solos» decide cuántas tarjetas compras.

Todo esto se resuelve, claro: un apagado programado, una tarea que suspenda lo que lleva horas sin sesión, políticas dentro del invitado. Pero pasa de ser una casilla en una consola con soporte detrás a ser código propio que alguien tiene que mantener y que puede romperse en silencio un viernes.

Lo que sí te llevas

La frase exacta del programa es que soporta «todas las funciones de Horizon disponibles para dispositivos registrados en modo de aprovisionamiento manual». Ahí entran la intermediación de sesiones, el protocolo, los agentes de Windows y de Linux y la asignación de usuarios: la experiencia de quien se sienta delante no cambia. Y se suma la certificación de NVIDIA vGPU, que no es nueva —Proxmox VE es hipervisor soportado por NVIDIA vGPU desde marzo de 2025— pero ahora entra en la misma casilla. El wiki del proyecto publica combinaciones probadas concretas, por ejemplo Proxmox VE 9.2.10 con vGPU 20.2, y su requisito de soporte es doble: un entitlement de NVIDIA vigente y una suscripción de Proxmox de nivel Basic, Standard o Premium.

En julio dijimos que un logo no migra tu infraestructura

Cuando Proxmox entró en el ecosistema de NVIDIA Mission Control escribimos que un logo no migra tu infraestructura, y lo sostenemos: aquel anuncio no cambiaba ningún requisito de arquitectura. Este cambia uno, aunque menos de lo que sugiere el titular. La lista de hipervisores con los que Horizon se entiende deja de tener un solo nombre, pero se entiende con cada uno a una profundidad distinta, y es esa profundidad —no el listado— la que decide cuánta gente necesitas para operarlo.

Quién puede moverse hoy y quién no

Si tus escritorios ya son persistentes —ingeniería con CAD y GPU, puestos de desarrollo, escritorios con software atado a la máquina, los treinta puestos de una nave que llevan cuatro años siendo la misma máquina virtual— el modelo manual es el que ya operas. Nadie te quita una automatización que no usabas. Nuestra parte del trabajo en esos casos ya es esa: virtualización de escritorio y plantillas de aprovisionamiento de Windows y Linux para clientes. La diferencia es que ahora ese montaje tiene un programa detrás en lugar de ser una decisión que defiendes tú solo.

Si en cambio tu VDI es un grupo flotante de clones instantáneos, con cientos de escritorios no persistentes que nacen por la mañana y se destruyen por la noche, no estarías cambiando de hipervisor: estarías cambiando una capa de automatización con soporte por un proyecto de scripting propio. Puede que aun así compense. Lo que no compensa es descubrirlo a mitad de camino. Ya escribimos con detalle sobre cuándo no migrar de VMware a Proxmox, y este es uno de esos casos en los que la respuesta honesta es «todavía no».

Las preguntas antes de mover nada

1. Qué versión de Horizon corres. Por debajo de 2506, el programa no aplica y la conversación se detiene ahí hasta que actualices.
2. Cuántos de tus grupos son manuales hoy. Ese dato está en tu consola; no hace falta estimarlo. Es la parte de tu VDI que se puede mover sin rediseñar nada.
3. Con qué estás comparando. Si la alternativa que tienes sobre la mesa es un hipervisor que Horizon gestiona por API, no estás comparando dos migraciones equivalentes y el coste operativo hay que ponerlo en la hoja.
4. Quién apaga los escritorios, con qué y quién lo mantiene. Si la respuesta es «ya lo scriptaremos», eso es una tarea con dueño y con pruebas.
5. Cómo llega un parche de la plantilla a las 120 máquinas. Sin recomposición automática esto es gestión de parque, con la herramienta y el equipo que eso implica.
6. Si hay GPU: entitlement de NVIDIA vigente y suscripción de Proxmox de nivel Basic o superior. Es requisito de soporte, no de que arranque. Y cuenta con que ahí no habrá ballooning.
7. La vuelta atrás, escrita antes de empezar. Con la red del sitio nuevo montada de verdad: al migrar a Proxmox, la red la guarda cada nodo, y un escritorio que arranca sin su VLAN es un escritorio que no existe.

Ese último punto no es un añadido de cortesía. La ventana para volver atrás en una migración caduca sola, y en un parque de escritorios caduca más rápido que en un servidor, porque cada día que pasa hay usuarios trabajando encima. Lo desarrollamos en el plan de vuelta atrás de una migración VMware→Proxmox.

Lo que ha cambiado hoy

Horizon ya funcionaba encima de Proxmox para quien se atrevía: máquinas persistentes, agente dentro, grupo manual y suerte. Lo que ha cambiado no es que funcione, sino que existe una entrada en una guía de compatibilidad, un procedimiento de certificación pasado y alguien con quien abrir un ticket cuando deje de funcionar. Dos años después de la compra de VMware por Broadcom, el éxodo masivo que se anunciaba no ha sido tal: lo que hay es gente moviéndose por piezas, a medida que cada pieza se queda sin motivos para no moverse. El escritorio virtual acaba de perder uno.

Fuentes (consultadas el 4 de septiembre de 2026): la nota de prensa «Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification», Viena, 4 de septiembre de 2026: de ahí salen la certificación «in Manual Provisioning Mode», la frase sobre reducir costes de infraestructura y el listado de Proxmox VE como hipervisor de terceros certificado con NVIDIA vGPU. Las citas del programa —«Provisioning and Power policy are Not supported», la definición del modo 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 soporte conjunto «with Horizon (in Manual Provisioning Mode) solutions» y «all Horizon features that are available for Manual Provisioning Mode registered devices»— son literales de la página del programa Horizon Ready Hypervisor de Omnissa Tech Zone (traducción nuestra donde aparecen en castellano); la versión mínima no es una frase, sino la tabla «Versions supported», donde figura Horizon | 2506 and above. Las configuraciones verificadas se publican en la guía de compatibilidad de hipervisores. El soporte de Nutanix AHV en disponibilidad general con Horizon 8 2512, con aprovisionamiento automatizado y gestión de energía a través de Prism Central, en el anuncio de Omnissa del 16 de diciembre de 2025. KSM activado por defecto, el aviso de canal lateral, la recomendación de desactivarlo en servicios de alojamiento, el «disabling KSM may be a legal requirement» y la opción allow-ksm, en la documentación de administración de Proxmox VE; los requisitos del ballooning y que no funciona con dispositivos PCIe pasados o mediados VFIO, en Dynamic Memory Management. Versiones probadas de vGPU sobre Proxmox VE (9.2.10 con vGPU 20.2) y los requisitos de soporte, en el wiki de Proxmox VE; Proxmox VE es hipervisor soportado por NVIDIA vGPU desde marzo de 2025. Omnissa es la antigua división de End-User Computing de VMware, cuya venta a KKR se cerró el 1 de julio de 2024. Matiz: el ejemplo de los 120 escritorios de 8 GB es una cuenta nuestra con supuestos explícitos para ilustrar el efecto de no tener política de energía, no una medición de ningún despliegue.