Proxmox gets a serious Horizon VDI route

Proxmox Server Solutions announced on 4 September 2026 that Proxmox VE has been certified under the Omnissa Horizon Ready Hypervisor programme. The important detail is not the badge itself. It is the supported operating model: Horizon can now broker desktops and applications running on Proxmox VE in Manual Provisioning Mode, with Proxmox also pointing to certified configurations for NVIDIA vGPU use.

For Luxembourg banks, fund managers, AIFMs, PSFs and enterprise IT teams, this is another signal that the post-VMware architecture discussion is maturing. The question is no longer simply whether Proxmox can run stable KVM workloads. Many teams already know it can. The board-level question is whether open virtualization can be placed inside a regulated, supportable, auditable end-user computing stack without creating unacceptable operational risk. This certification does not solve every Horizon design problem, but it removes one of the classic blockers: unsupported VDI on an alternative hypervisor.

Regulatory & Business Impact

DORA has changed the tone of infrastructure decisions. A cheaper platform is not automatically a better platform. A more familiar vendor is not automatically a safer vendor. Under the CSSF’s DORA guidance, management bodies remain accountable for ICT risk management, budget allocation, third-party oversight and resilience strategy. That means desktop virtualization, remote access and hypervisor selection are now governance topics, not just engineering preferences.

The Proxmox-Horizon development matters because VDI is often part of the critical access layer for regulated firms. Traders, fund operations teams, risk analysts, external administrators and privileged support users may all depend on virtual desktops or published applications. If that layer fails, the incident is rarely isolated to “end-user computing”. It can become a business continuity issue, a privileged access issue, and potentially a regulatory reporting issue if critical services are disrupted.

There is also a cost-control angle that should not be dismissed. European firms are under pressure to rationalise VMware estates, reduce licensing concentration and avoid infrastructure lock-in. Proxmox VE brings KVM, LXC, software-defined storage and clustering into an open-source platform. Omnissa Horizon remains a commercial EUC control plane. Together, they create a possible middle path: keep a familiar Horizon user experience while moving selected desktop pools onto a lower-cost, more sovereign virtualization base.

But leadership should read the certification carefully. Omnissa’s Horizon Ready Hypervisor programme is explicitly for Horizon with third-party hypervisors in Manual Provisioning Mode. Omnissa’s programme notes that native Horizon provisioning and power policy are not supported in this mode. In plain language: this is not a like-for-like replacement for a deeply automated vSphere Horizon environment. It is a supported route for pre-provisioned workloads, persistent desktops and controlled pools where the lifecycle is handled outside Horizon’s native automation.

That distinction is exactly where regulated architecture work begins. If a firm wants Proxmox for VDI, it must design the missing automation layer deliberately. Golden image lifecycle, VM provisioning, patch windows, certificate rotation, user assignment, backup validation, GPU allocation, capacity management and disaster recovery all need evidence. DORA rewards controlled process. It does not reward clever undocumented shortcuts.

Architectural & Operational Blueprint

A credible Proxmox-Horizon architecture should start with segmentation. Horizon Connection Servers and Unified Access Gateway components belong in a tightly controlled access design, with clear DMZ placement, TLS hygiene, MFA integration and logging. In Luxembourg finance, I would expect this traffic path to be treated like a regulated access channel: WAF or reverse proxy controls where appropriate, F5 or Nginx patterns for controlled ingress, strong certificate lifecycle management, and no casual exposure of management interfaces.

The Proxmox layer should be built as production infrastructure, not as a cheap hypervisor island. That means clustered Proxmox VE nodes, HA groups where appropriate, resilient storage design, documented network separation for management, storage, migration and VDI traffic, and tested recovery using Proxmox Backup Server or an equivalent enterprise backup pattern. If Ceph is used, the team must prove latency and capacity behaviour under desktop boot storms and patch cycles. If ZFS-backed local storage is used, the team must prove node failure and restore procedures. Both designs can be valid. Neither should be assumed.

Manual Provisioning Mode shifts lifecycle responsibility back to the infrastructure team. That can be a strength if automation is designed properly. Ansible should own baseline configuration, VM template hardening, package updates, monitoring agents, domain join steps where applicable, and post-build validation. Terraform or API-driven workflows may be used for provisioning where the operating model supports it. The key is to make desktop creation repeatable and auditable without depending on an engineer’s memory.

Observability is the second control plane. Zabbix or Prometheus can track node health, storage pressure, replication status, GPU utilisation and network saturation. Grafana should expose executive-friendly service indicators: available desktop capacity, failed sessions, login latency, backup status and patch compliance. Horizon events, Windows event logs, Proxmox task logs and firewall telemetry should flow into a searchable evidence layer. When an incident happens, the team should not spend two hours proving whether the problem is identity, broker, hypervisor, storage or network.

This is also a good use case for private AIOps. I would not send Horizon logs, user identifiers or privileged infrastructure telemetry blindly into a public AI service. For regulated firms, a small local inference stack using vLLM or Ollama, combined with Qdrant for incident knowledge and runbook retrieval, can help engineers triage recurring faults without exporting sensitive operational data. LangGraph-style agents can assist with correlation and runbook suggestions, but approval gates must remain human-controlled for remediation actions.

Security architecture must be explicit. Privileged Proxmox access should be separated from Horizon administration. Break-glass accounts must be monitored. API tokens should be scoped, rotated and stored properly. Backups must be immutable or protected from administrative compromise. GPU-enabled VDI adds another layer: firmware, driver, guest tools and workload isolation must be part of the patch and vulnerability process, not an exception because “the GPU desktops are special”.

What This Changes in Practice

• VDI can enter the VMware-exit roadmap. Proxmox is no longer only a server consolidation option; it can now be assessed for selected Horizon desktop pools.
• Manual Provisioning Mode must be understood by management. This is supported, but it changes automation responsibilities. Native provisioning and power policy limitations need to be reflected in the operating model.
• Cost savings need evidence. Compare licensing, support, storage, backup, engineering time, migration effort and operational risk. Do not sell the move on hypervisor cost alone.
• DORA documentation becomes part of the design. Maintain architecture diagrams, dependency maps, access controls, recovery objectives, test results and third-party support evidence.
• Start with bounded pools. Persistent admin desktops, developer workspaces, GPU test pools or lower-risk internal applications are better first candidates than the most time-critical production workflows.
• Automate before scaling. If image creation, patching, assignment and rollback are manual at 50 desktops, they will become operational debt at 500.
• Build an incident evidence graph. Correlate Horizon, Proxmox, identity, firewall, storage and backup telemetry so root-cause analysis is fast and defensible.

How Ali Run AIOps Approaches This

At Ali Run AIOps, I look at this kind of shift through three lenses: resilience, sovereignty and operating cost. Proxmox can be a strong platform, but only when it is engineered with the same discipline expected from traditional enterprise virtualization: HA design, backup validation, monitoring, patch governance, access control and documented recovery. For financial services, the target is not “open source because it is cheaper”. The target is controlled independence without weakening auditability.

Our consulting approach is to build the architecture and the operational evidence together. That includes Proxmox cluster design, Horizon integration patterns, Ansible automation, Zabbix/Grafana observability, secure reverse proxy and access gateway design, and private AIOps workflows for incident response. The result should be a VDI platform that finance leadership can defend in a risk committee: lower concentration risk, clearer cost structure, and stronger operational control.

Sources

• Proxmox: Proxmox VE achieves Omnissa Horizon Ready Hypervisor Certification
• Omnissa Tech Zone: Horizon Ready Hypervisor programme
• Omnissa Product Interoperability Matrix: Hypervisors
• CSSF: ICT and cyber risk for DORA entities
• CSSF: Updates of circulars related to ICT risk management and ICT outsourcing