Omnissa Horizon on Nutanix: the optimizations to apply, on AHV and on vSphere

With Horizon 8 2512, support for Nutanix AHV became generally available, and “Horizon on Nutanix” no longer just means vSphere on Nutanix hardware. Nutanix and Omnissa have published a lot of documentation on how to integrate the two worlds: tech notes, a Validated Design, best practice guides and the Horizon 8 architecture guide. In this article I collect the optimizations the two vendors recommend, layer by layer, with my point of view as a Nutanix and EUC architect.

Two ways to run Horizon on Nutanix

Horizon can run on Nutanix with two hypervisors. On vSphere the integration is the classic one with vCenter, and Nutanix has a dedicated best practice guide. On AHV, since 2512, Horizon integrates with Prism Central, which acts as the capacity provider: it creates, clones, deletes and powers on VMs in place of vCenter. AHV supports automated pools, both desktop pools and RDSH farms, and manual pools; the management components run on AHV too: Connection Server, Unified Access Gateway, App Volumes, Dynamic Environment Manager, Horizon Recording and Horizon Edge Gateway.

Some concepts change, and it’s worth having them clear before you design:

On vSphere	On AHV
Integration with vCenter	Prism Central as the capacity provider
Golden image snapshot	Prism Central template, based on recovery points without snapshot chains
VMFS or NFS datastore	Nutanix storage container
Customization with ClonePrep or Sysprep and guest customizations	Customization with ClonePrep or Sysprep and custom profiles
App Volumes with VMDKs attached through vCenter	App Volumes with in-guest VHDs on SMB shares, for example Nutanix Files
Unified Access Gateway deployed from an OVA	Unified Access Gateway deployed with Omnissa’s PowerShell scripts against Prism Central

As for versions, the Omnissa documentation for 2512 lists Prism Central 2024.3, AOS 7.0 and AHV 10.0 as the minimums; before you start, check the combination in the Omnissa Interoperability Matrix anyway. Two practical notes: on AHV only the automated activation of Horizon Universal subscription licenses is supported, and since 2512.1 Connection Servers and Horizon Agents must be upgraded together, because the pairing mechanism between them changed (KB 6001315).

Architecture: pods, blocks and Prism Central

The Horizon pod-and-block architecture doesn’t change. On AHV each resource block is made of one or more AHV clusters, and Omnissa recommends giving each block a dedicated Prism Central instance: failure domains stay separate, and a Prism Central issue stays confined to one block.

Prism Central

Sizing. An instance can handle up to 25,000 VMs, but for VDI the recommendation is to stay within 5,000 VMs per instance, in the Large size; X-Large if monitoring shows you need it.
Availability. Prism Central isn’t in the session path: if it goes down, connected users and new connections to desktops that are already provisioned keep working. What stops is provisioning, refresh after logoff and power operations. You protect it with AHV VM high availability or with the three-VM scale-out deployment; the Nutanix Validated Design uses a scale-out Prism Central in each datacenter, with the capacity provider pointing to its virtual IP address.
Provisioning peaks. If logoffs and desktop re-creation are concentrated at certain times of day, Prism Central can become the bottleneck. Nutanix recommends creating the VMs of automated pools with All Machines Up-Front rather than Machines on Demand, and scaling them down outside business hours with automation that adjusts the pool’s maximum and spare VM counts.
Service account. Use a dedicated account in Prism Central, local or from Active Directory, with the Super Admin role the integration requires.

AHV clusters and density

Don’t design to the maximums. AHV supports 32 nodes per cluster, 200 powered-on VDI VMs per node and 4,096 VMs per cluster, but for VDI Nutanix recommends at most 16 nodes per cluster, with at least n+1: 15 usable nodes.
VMs per node. Nutanix’s rough guideline, also quoted by Omnissa, is about 150 VDI VMs per node, which means up to 2,250 VMs per cluster. The Nutanix Validated Design, with Windows 11 and the Login Enterprise Knowledge Worker profile, qualified 100 VMs per node and 1,500 per 16-node cluster, staying below 85% CPU and 5% CPU ready. Windows 11 is heavier than Windows 10: use these numbers as a reference and validate them with your own workloads.
Smaller clusters, smaller failures. Fewer nodes per cluster means fewer users affected by a failure and shorter maintenance windows: the Validated Design estimates 16 hours to update a 16-node cluster with LCM, and 8-node blocks cut that time in half.

Management servers

Connection Servers. At least three per pod, so the pod stays redundant during maintenance too; the Validated Design uses four when connections go through UAGs. Each Connection Server handles up to 4,000 sessions, 2,000 if they come through UAGs; Nutanix recommends staying within 2,000 and starting from the Omnissa minimum of 4 vCPUs and 10 GB of RAM.
HA and anti-affinity. Turn on AHV VM high availability and create anti-affinity rules, so servers with the same role don’t end up on the same host.
Management and desktops. If they share the cluster, prioritize resources for the management components and account for them in your sizing; the Validated Design separates them into a dedicated management cluster.
Load balancers. Connection Servers, UAGs and Horizon Recording need a load balancer that supports session persistence: the one built into Prism Central doesn’t.

Storage: containers, data reduction and CVMs

For the desktop container, the vSphere guide and the AHV Validated Design point in the same direction:

Setting	Recommendation
Compression	Inline, with zero delay
Deduplication	Off for nonpersistent desktops; consider it only for full clones and writable volumes
Erasure coding	Off: it isn’t suitable for VDI
Replication factor	RF2 with fault tolerance 1; RF3 only for more demanding SLAs
Containers	One per use case: if you have full clones and nonpersistent clones, use two

For resilience, the Validated Design prefers multiple RF2 clusters over RF3 clusters, and turns on the HA option that reserves failover capacity. Size CVM memory with the tables in the CVM Memory Configuration section of the Prism Element guide: both Nutanix and Omnissa recommend it, because the CVMs serve all the desktop I/O.

The detail that makes the difference: no BitLocker in the image

Omnissa explains an AHV behavior worth knowing. When you push an image, the old clones and their recovery points are deleted, but they stay on disk until the space reclamation cycle, which runs every hour: for a while, usage goes up. Thanks to redirect-on-write each new clone takes little space, so the spike stays small. With BitLocker on, however, each VM consumes its entire allocated disk, and the spike becomes significant.

So turn off device encryption in the golden image and prevent BitLocker from turning it back on. There is a second reason too: data encrypted in the guest usually doesn’t compress. If you need encryption at rest, use the Nutanix one: the Validated Design encrypts the entire cluster.

Network and security

Physical network. Every write is replicated to another CVM, so latency between nodes adds up to storage latency. The Validated Design uses a 25 GbE leaf-spine topology, with MLAG or vPC instead of stacking, an untagged CVM and hypervisor VLAN on the server ports and tagged VLANs for workloads.
DHCP and DNS. On AHV you can use Nutanix IPAM, which already has high availability built in. Keep leases short on the VDI scope and align them with DNS scavenging; with a Windows DHCP server, Nutanix suggests going from the default 8 days to one hour.
Active Directory. The network chosen for the pool must be mapped to an Active Directory site, which is an Omnissa requirement, and each site must have local domain controllers, global catalogs and DNS.
Microsegmentation. Flow Network Security protects VMs with policies based on Prism Central categories. Categories also drive storage policies, disaster recovery and RBAC: every desktop inherits the ones applied to the template, so choose them carefully.
Blast. Configure QoS for Blast traffic, user access ports of at least 1 GbE, and enough bandwidth for users connecting over WAN or VPN.

VMs: sizing, images and templates

Sizing

vCPUs. At least 2 for Windows 10, 3 for Windows 11 and 6 for RDSH on Windows Server 2019 and 2022. The Validated Design qualified Windows 11 with 4 vCPUs and 6 GB.
Scale out rather than up. The hypervisor scheduler does a better job than Windows: more small VMs perform better than a few large ones. On AHV there’s no difference between one socket with multiple cores and multiple sockets, and Nutanix suggests a single socket. As VMs grow, keep an eye on NUMA boundaries.
Overcommit. At most 8:1 for Windows client and 2:1 for Windows Server, while watching CPU ready: more vCPUs per VM can push it up.
Memory. Never overcommit it. As a reference, 4 GB for Windows 10, 6 GB for Windows 11 and at least 32 GB for RDSH, adjusted to your applications.
Virtual hardware. SCSI controller and the default disk and network adapter, that is, VirtIO-SCSI and VirtIO-Net. Windows 11 needs vTPM and Secure Boot.

Golden images and templates

A fresh image, when you can. Nutanix recommends building a new image for AHV rather than converting the vSphere one. If you convert it with Move, remove Nutanix Guest Tools and VMware Tools after the conversion, keeping the VirtIO drivers.
VirtIO yes, NGT no. Always install the latest VirtIO drivers in the image, but don’t install NGT in images for automated pools. For dedicated machines, install it after deployment.
vTPM. It’s defined in the Horizon compute profile and can’t be cloned: Horizon replaces it on every VM it deploys.
Optimization. Apply the Omnissa optimizations with the OS Optimization Tool, together with the Manually creating optimized Windows images for Horizon VMs guide, and repeat them after every operating system or application update.
Agents. Follow the installation order Omnissa specifies for Horizon Agent, Dynamic Environment Manager and App Volumes. The agent registers with the Connection Server at install time: to uninstall it or change its components, first delete the VM from the Horizon console.
One template per pod. The agent stays bound to the pod it registered with, so a multi-pod architecture needs one image per pod: it pays to build them with automation, for example Packer, Ansible or MDT.
No template versioning. Horizon doesn’t support Prism Central template versioning: update the image and create a new template.
Customization. For nonpersistent pools the Validated Design uses ClonePrep; Sysprep is still available when you need it.

GPUs

Use up-to-date drivers and a supported pairing of host and guest drivers, and install the driver in the template before provisioning. If you add the GPU to the template later, you have to redeploy the machines or add it to them manually.
Keep enough GPU capacity free to power on the template during update cycles.
A VM with a GPU reserves all of its memory, NVIDIA vGPU doesn’t support virtualization-based security, and AHV always places GPUs with depth-first scheduling.

Antivirus and updates

Configure the recommended exclusions for all components, and repeat the exercise for every new application.
Schedule scans outside business hours and in stages, and run a full scan before sealing the image.
Roll out patches in successive rings, measuring their impact.

App Volumes, DEM and profiles on Nutanix Files

On AHV, App Volumes uses the in-guest VHD model on SMB shares, and Nutanix Files becomes the natural choice, for Dynamic Environment Manager and Horizon Recording too. Nutanix specifies the share type for each component:

Component	Share type	Continuous availability
App Volumes, packages	Standard	Yes
App Volumes, Writable Volumes	Standard, across multiple shares balanced with a storage group	Yes
DEM, configuration	Standard, preferred	No
DEM, profile archive	Distributed, one top-level directory per user	No, except for Flex configurations
Horizon Recording	Distributed, one top-level directory per server	Yes

Access. Turn on access-based enumeration on the profile archive shares; SMB encryption is optional.
Replication between sites. Packages replicate with App Volumes Application Synchronization, the DEM configuration with Smart DR and the profile archive with VDI Sync. For Writable Volumes, use Smart DR in active-passive or active-active pinned architectures; active-active roaming needs a third-party replication product.
Sizing Files. Use the use cases from the Nutanix Files sizing guide: Home Directories for VDI, Container-Based for Writable Volumes, Performance-Sensitive Application Shares: Random for packages and Home Directories for VDI, File-Based for DEM.
Packaging. For each package, deploy a new VM from a Nutanix template.
Alternatives. Instead of DEM you can use FSLogix Profile Container, again on Files.

If you stay on vSphere

For those running Horizon on Nutanix with vSphere, the Nutanix best practice guide adds a few specific rules:

Containers. A single container and datastore for desktops and RDSH, a separate container for App Volumes packages, and two containers if you have both full clones and instant clones.
Shadow clones and View Storage Accelerator. Instant clones all read from the replica disk, and Nutanix shadow clones cache it on every node, so reads stay local. That’s why Nutanix recommends turning off View Storage Accelerator (CBRC) and ignoring the warning Horizon shows when you create the pool.
vCenter. Even though a vCenter manages up to 8,000 instant clones, Nutanix recommends staying within 2,000 desktops per vCenter.
Maintenance with LCM. Usually each host has a primary VM per pool that LCM can’t shut down: deselect the automatic shutdown, because vCenter deletes the primary VMs when the host enters maintenance mode and recreates them afterwards. To keep the pool from going into an error state because the replica is powered off on a host under maintenance, disable provisioning during the work, or update a host without replicas first and move them there.
Base VM. PVSCSI or LSI Logic SAS controller, VMXNET3 adapter, thin disk, no floppy, LPT and COM ports disabled and hot plug turned off.

Multisite and disaster recovery

On Nutanix each site has its own cluster and its own Prism Central, configured as a separate capacity provider: there’s no single integration point like the vCenter of a stretched vSAN. Continuity is built with Cloud Pod Architecture: a global entitlement that groups pools on different capacity providers distributes sessions across sites, active-active or active-passive. In the Nutanix example each site has 100% of the capacity and serves 50% of the users. Remember that templates are bound to the pod through the agent, and that manual pools are the best fit for failover between pods.

My checklist

Versions checked in the Interoperability Matrix, with Connection Servers and agents upgraded together.
One Prism Central per block, Large, at most 5,000 VMs, protected with HA or scale-out.
VDI clusters of 16 nodes at most, with n+1, and density validated with a load test.
Containers with inline compression, no deduplication or erasure coding, in RF2.
CVM memory sized according to the Prism Element tables.
A fresh golden image, up-to-date VirtIO, no NGT, no BitLocker, optimized with OSOT.
Automated pools with All Machines Up-Front and ClonePrep for nonpersistent desktops.
HA and anti-affinity for the management servers, and load balancers with session persistence.
App Volumes, DEM and Recording on Nutanix Files, each with the right share type.
Microsegmentation with Flow, and template categories chosen carefully.

Horizon on AHV is a young integration, but the two vendors’ documentation is already solid and, above all, consistent: it follows the same principles that apply to any VDI on Nutanix. My advice is to start from the Validated Design, adapt it to your own numbers and measure before going into production.

References

Omnissa Horizon on Nutanix AHV (Nutanix, TN-2162)
Omnissa Horizon on AHV Design (Nutanix Validated Design, NVD-2173)
Omnissa Horizon on Nutanix Using vSphere Best Practices (Nutanix, BP-2060)
Migrating Omnissa Horizon Workloads from VMware ESXi to Nutanix AHV (Nutanix, TN-2139)
Horizon 8 architecture: Nutanix AHV deployments (Omnissa Tech Zone)
Omnissa Horizon 8 on Nutanix AHV design guidance (Omnissa technical blog)
Manually creating optimized Windows images for Horizon VMs (Omnissa Tech Zone)
Omnissa Horizon 8 2512 Release Notes (Omnissa)