Proxmox VE is now Horizon Ready, but in manual mode: you create and power off the desktops yourself

Proxmox announced today, out of Vienna, that Proxmox VE has achieved certification under the Omnissa Horizon Ready Hypervisor program. Clean headline: your Horizon virtual desktops can now run on Proxmox. In the middle of that same sentence sit three words that decide the rest of the project — Manual Provisioning Mode — and the program page explains them without diplomacy: "Provisioning and Power policy are Not supported". Horizon still hands the desktop to the user. Creating it and powering it off becomes yours.

What was certified, small print first

The program is not a joint press release: it is a procedure. Omnissa hands the hypervisor vendor the Horizon binaries and a prescribed set of test cases, the vendor runs them and submits the results, Omnissa reviews and approves them, and only then does the product appear in the compatibility guide. In return the vendor may use the Omnissa Ready — Horizon logo, and the listing "signifies joint support for end users that deploy certified Partner Software with Horizon (in Manual Provisioning Mode) solutions". The parenthesis is in the original, and it bounds everything else.

Three more conditions from the same page. The table of versions supported by the program reads Horizon 2506 and above: if you run an earlier branch, this is not about you yet. The requirements section states that "General support on Horizon is purchased separately", so the certification opens the door to Omnissa answering the phone with Proxmox underneath, but it does not hand you the contract. And in the branding section, Partner Ready status is listed as "Not Eligible": this is a product certification, not an alliance.

Horizon had already left vSphere. Through another door, nine months ago

This is the context almost no coverage of the announcement puts alongside it, and it is what actually places the news. In Horizon 8 2512, released on 16 December 2025, Omnissa declared general availability of support for Nutanix AHV. Not in manual mode: with automated desktop pools and RDSH farms, on-demand provisioning with golden image workflows, power state management and pool power policy from the Horizon Console itself, all through Prism Central. That is, over the API against the hypervisor.

With that on the table, what exists today are two different regimes for living outside vSphere. One where Horizon talks to the hypervisor and keeps doing its whole job. And another, the certification program's, where Horizon asks the hypervisor for nothing and confines itself to handing users to machines that already exist. Proxmox VE has just entered the second one. That does not make it less useful, but it changes the conversation entirely: you are not choosing between vSphere and Proxmox, you are choosing how much of the operation you keep.

Manual mode, plainly

Omnissa defines it like this: Manual Provisioning Mode "enables Horizon to broker connections to workloads that are provisioned and managed outside of Horizon's native automation capabilities such as persistent virtual machines or even physical desktops". And in the program's target-audience section the integration is described as "Hypervisor - Horizon working on Hypervisor without any API request for provisioning".

No API requests. There is no hypervisor integration: there is an agent inside each machine and a broker handing out users. It is the same mechanism Horizon has used for years to publish a physical office PC, and that is at once the virtue of the design — it works with anything that can run the agent — and the exact measure of what it does not do.

The two things that stop being Horizon's job

Provisioning. In an instant-clone pool you publish a master image and the platform builds and destroys desktops on its own. In manual mode, the machine has to exist before Horizon knows anything about it: you create it in Proxmox — template, clone, cloud-init or sysprep — install the agent and register it in the pool. When you patch the image, the cycle of publishing a new version and having the desktops rebuild themselves stops existing, and you repeat the process by hand.

Power policy. Horizon stops powering the machine on when the user connects and powering it off or suspending it when they log out. If nobody else does it, the desktops stay on around the clock.

The arithmetic that is not in the press release

The Proxmox release says this lets organizations run their Omnissa virtual desktops directly on Proxmox VE "reducing infrastructure costs without compromising on performance". At the hypervisor licensing layer, that is true. One floor down the arithmetic changes, and it is worth doing with a pencil before you do it with an invoice.

Take the most boring example available: 120 desktops of 8 GB. With power policy, the memory peak looks like the number of people connected at once and at night it drops on its own. Without it, all 120 exist powered on permanently: 960 GB of assigned RAM. Proxmox has two mechanisms to keep that figure from being the real one, and it is worth knowing what state each arrives in. KSM, the deduplication of identical pages, is enabled by default — and a hundred and twenty identical Windows go a long way. Ballooning, on the other hand, has to be configured: minimum memory different from maximum on each machine and, on Windows guests, the VirtIO Balloon driver with its service installed.

And here sits a decision that almost never gets made out loud, because KSM comes switched on and nobody looks at it. Proxmox's own documentation warns that deduplication exposes machines to side-channel attacks — information about one VM can be inferred from another on the same host — and recommends, verbatim, that if you use Proxmox VE to provide hosting services you should consider disabling KSM, adding that you should check your country's regulations because "disabling KSM may be a legal requirement". On a single company's desktop estate the risk profile is not the multi-tenant one, but the decision is yours and it gets made in writing. It can be tuned per machine with the allow-ksm option. What does not work is learning about the saving without learning what it costs.

With a GPU the arithmetic hardens abruptly, and that is precisely the other headline in the announcement. Proxmox's documentation says it plainly: if you pass through a physical PCIe device or a VFIO mediated device — which is exactly what sits underneath a vGPU — ballooning will not work, because those devices are mapped to fixed memory addresses. Add that the vGPU profile carves the card's memory into slices and every powered-on machine holds its own for as long as it is booted. On an estate with vGPU, the desktop of the person on holiday takes up as much as the one that is rendering, in RAM and in GPU, and there "the desktops do not power themselves off" decides how many cards you buy.

All of this can be solved, of course: a scheduled shutdown, a task that suspends whatever has had no session for hours, policies inside the guest. But it goes from being a checkbox in a console with support behind it to being your own code, which somebody has to maintain and which can break quietly on a Friday.

What you do get

The program's exact wording is that it supports "all Horizon features that are available for Manual Provisioning Mode registered devices". That covers session brokering, the protocol, the Windows and Linux agents and user entitlements: the experience for whoever sits down in front of it does not change. And the NVIDIA vGPU certification comes with it — not new, since Proxmox VE has been an NVIDIA vGPU supported hypervisor since March 2025 — but now it lands in the same box. The project wiki publishes specific tested combinations, Proxmox VE 9.2.10 with vGPU 20.2 among them, and its support requirement is twofold: a valid NVIDIA entitlement and a Proxmox subscription at Basic, Standard or Premium level.

In July we said a logo does not migrate your infrastructure

When Proxmox joined the NVIDIA Mission Control ecosystem we wrote that a logo will not migrate your infrastructure, and we stand by it: that announcement changed no architectural requirement. This one changes one, though less than the headline suggests. The list of hypervisors Horizon gets along with stops having a single name, but it gets along with each of them to a different depth, and it is that depth — not the listing — that decides how many people you need to run it.

Who can move today and who cannot

If your desktops are already persistent — engineering with CAD and GPU, developer workstations, desktops with software tied to the machine, the thirty seats on a shop floor that have been the same virtual machine for four years — the manual model is the one you already operate. Nobody is taking away automation you were not using. Our own share of the work in those cases is already that: desktop virtualization and Windows and Linux provisioning templates for clients. The difference is that this setup now has a program behind it instead of being a decision you defend on your own.

If, on the other hand, your VDI is a floating instant-clone pool with hundreds of non-persistent desktops born in the morning and destroyed at night, you would not be changing hypervisor: you would be trading a supported automation layer for a scripting project of your own. It might still be worth it. What is not worth it is finding out halfway through. We already wrote in detail about when not to migrate from VMware to Proxmox, and this is one of those cases where the honest answer is "not yet".

The questions before you move anything

1. Which Horizon version you run. Below 2506 the program does not apply and the conversation stops there until you upgrade.
2. How many of your pools are manual today. That figure is in your console; no need to estimate it. It is the share of your VDI that can move without redesigning anything.
3. What you are comparing against. If the alternative on your table is a hypervisor Horizon manages over the API, you are not comparing two equivalent migrations, and the operational cost belongs on the spreadsheet.
4. Who powers the desktops off, with what, and who maintains it. If the answer is "we will script it", that is a task with an owner and tests.
5. How a patch to the template reaches the 120 machines. Without automated recompose this is fleet management, with the tooling and the team that implies.
6. If there is a GPU: a valid NVIDIA entitlement and a Proxmox subscription at Basic level or above. It is a support requirement, not a boot requirement. And count on there being no ballooning there.
7. The way back, written before you start. With the new site's networking genuinely in place: when migrating to Proxmox, the network lives on each node, and a desktop that boots without its VLAN is a desktop that does not exist.

That last point is not a courtesy addendum. The window to roll a migration back expires on its own, and on a desktop estate it expires faster than on a server, because every passing day there are users working on top of it. We went into it in the rollback plan for a VMware-to-Proxmox migration.

What changed today

Horizon already worked on top of Proxmox for anyone willing to try: persistent machines, agent inside, manual pool and good luck. What changed is not that it works, but that there is an entry in a compatibility guide, a certification procedure that was passed, and someone to open a ticket with when it stops working. Two years after Broadcom bought VMware, the mass exodus that was announced never quite happened: what there is instead is people moving piece by piece, as each piece runs out of reasons not to move. The virtual desktop has just lost one of its own.

Sources (consulted on 4 September 2026): the press release "Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification", Vienna, 4 September 2026: source of the "in Manual Provisioning Mode" certification, the sentence about reducing infrastructure costs, and the listing of Proxmox VE as a certified third-party hypervisor supporting NVIDIA vGPU. The program quotes — "Provisioning and Power policy are Not supported", the definition of manual mode, "Hypervisor - Horizon working on Hypervisor without any API request for provisioning", "General support on Horizon is purchased separately", "Partner Ready Status: Not Eligible", the joint support "with Horizon (in Manual Provisioning Mode) solutions" and "all Horizon features that are available for Manual Provisioning Mode registered devices" — are verbatim from Omnissa Tech Zone's Horizon Ready Hypervisor program page; the minimum version is not a sentence but the "Versions supported" table, which reads Horizon | 2506 and above. Verified configurations are published in the hypervisor compatibility guide. Nutanix AHV support at general availability with Horizon 8 2512, with automated provisioning and power management through Prism Central, in Omnissa's announcement of 16 December 2025. KSM enabled by default, the side-channel warning, the recommendation to disable it for hosting services, the "disabling KSM may be a legal requirement" line and the allow-ksm option, in the Proxmox VE administration documentation; the ballooning requirements and the fact that it does not work with passed-through PCIe or VFIO mediated devices, in Dynamic Memory Management. Tested vGPU versions on Proxmox VE (9.2.10 with vGPU 20.2) and the support requirements, in the Proxmox VE wiki; Proxmox VE has been an NVIDIA vGPU supported hypervisor since March 2025. Omnissa is the former VMware End-User Computing division, whose sale to KKR closed on 1 July 2024. Qualifier: the 120-desktops-at-8-GB example is our own arithmetic with explicit assumptions, meant to illustrate the effect of having no power policy, not a measurement of any deployment.