SAP HANA on VMware vSphere and VCF 9: support status, VM sizing and host choice

Is SAP HANA supported on VMware vSphere and VCF 9

SAP supports SAP HANA 2.0 in virtual machines on VMware vSphere 8 and on vSphere in VMware Cloud Foundation (VCF) 9 and vSphere Foundation (VVF) 9, under one SAP Note per platform version and on the CPU generations validated for it. Broadcom’s VCF blog announced SAP support for VCF 9 on 19 January 2026 and refers to SAP Note 3663150 for the details. SAP HANA on vSAN follows a separate note and needs a system certified for both SAP HANA and vSAN.

SAP Notes require an SAP account to read, so the support statements below are the ones Broadcom publishes on its VCF blog and in its SAP HANA best practices guide, which cite the notes by number. Before a production decision, read the current version of each note in the SAP support portal.

SAP HANA support status by vSphere version

Broadcom’s VCF blog posts of the dates shown and its SAP HANA on VMware vSphere Best Practices guide (December 2024 cover date). Note numbers as Broadcom cites them; SAP Note texts need an SAP login.

Broadcom’s post of 1 August 2025 addressed SAP customers still on vSphere 7. It says vSphere 7 supported SAP HANA on Haswell, Broadwell and Skylake CPUs, that “these older processors are not supported on vSphere 8 due to CPU deprecation and/or discontinuation” and that vSphere 8 is “fully supported for SAP HANA on Cascade Lake and newer Intel CPUs”. SAP HANA systems on the older CPUs therefore move to new hosts rather than through an in-place upgrade. It recommends “vSphere 8 for a straightforward uplift, or VCF 9 for a full private‑cloud foundation and support until 2031”. The same post says vSphere 8 “will be supported until October 2027”, with an optional two-year Extended Support period for purchase; our guide to the end of vSphere 8 general support covers the dates.

The January 2026 post lists Intel Xeon platforms from 2nd Gen (Cascade Lake and Cooper Lake) to Xeon 6 with P-cores (Granite Rapids) for SAP HANA on VCF 9. Cascade Lake is on that list, but Broadcom’s KB 318697 marks it as deprecated in VCF 9.x, still supported and installed with a CPU_SUPPORT_WARNING; the ESX 9 hardware requirements list the CPUs and devices to check before you keep those hosts for VCF 9. Support for Xeon 6 on vSphere 8 “was released at the end of September 2025”, so new Xeon 6 hosts can join a vSphere 8 cluster first and move to VCF 9 later.

Broadcom’s post of 12 May 2026 says “VCF 9.1 now enables the deployment of 2-socket Intel Xeon 6 CPUs with P-core systems (Granite Rapids-SP) on VMware vSAN”. In VCF 9.0 these hosts ran with Fibre Channel or NFS storage. Its plans include 4-socket Xeon 6 hosts and memory above 2 TB per CPU socket once the DIMMs are available.

SAP HANA VM sizing on vSphere: maximums per socket and host

SAP HANA VMs on vSphere are sized in whole or half CPU sockets. Broadcom’s guide lists “0.5, 1, 2-socket wide VMs on 2-socket hosts” and the same steps up to 8 sockets on 8-socket hosts. It counts each hyperthread as a vCPU, for example “56 vCPUs (28 cores plus hyperthreading)” on a 28-core socket, and recommends keeping hyperthreading on, which is the ESXi default.

Broadcom VCF blog: 19 January 2026 (Xeon 6 rows, VCF 9.0), 14 April 2025 (16 TB on vSphere 8.0 U3, scale-out on request) and 12 May 2026 (scale-out up to 48 TB on VCF 9 and later, details in SAP Note 3663150).

The January 2026 post calls “up to 2 TiB of memory and up to 172 vCPUs per CPU socket” the current maximum for standard configurations, and lists 2 TiB per socket as validated for Xeon 6 with “up to 4 TiB, yet not validated”. It adds that an 86-core CPU is typically required to reach 4 TiB per socket and that a lower core count may be enough if workload-based sizing under SAP Note 2779240 confirms it. For hosts with 4th Gen Xeon, the post lists 16 TiB as the largest VM on VCF 9.

Host memory is not all available to SAP HANA. Broadcom’s guide subtracts the ESXi memory need from the host’s memory before it places VMs, with defaults of 128 GB on 2-socket, 256 GB on 4-socket and 512 GB on 8-socket hosts. With the default, a 2-socket host with 2 TiB per socket has 128 GB less than its 4 TiB for SAP HANA VMs.

NUMA alignment, memory reservations and latency

SAP HANA is NUMA-aware, and the guide’s rules keep each VM aligned to physical sockets. Half-socket VMs on Xeon 6 require Sub-NUMA Clustering (SNC-2). The guide, written for Sapphire Rapids hosts before Xeon 6 was validated, requires the VMX parameter sched.nodeX.affinity on every VM that uses SNC-2, to prevent unwanted NUMA node migrations, and a dedicated cluster of SNC-2 hosts for migrating these VMs. Every SAP HANA VM gets numa.vcpu.preferHT=TRUE, which keeps its vCPU threads on the NUMA node.

Production SAP HANA VMs do not share hosts with other workloads. The guide says production workloads “must not run on the hosts that run the management components or non-SAP HANA VMs” and that an SAP HANA VM should not share a NUMA node with a non-SAP HANA VM. On the shared clusters that run the rest of the estate, CPU ready per vCPU shows whether the vCPU ratio still fits the workload.

Memory is sized with reservations. The guide says the host’s memory use is known only after all VMs are configured and started with memory reservations, and that the last VM started might fail to run if the reservation was chosen wrong. For workloads with very low latency requirements, the guide makes an exception to its hyperthreading advice and has a separate section on performance optimisation for low-latency SAP HANA VMs.

Storage for SAP HANA VMs and SAP HANA on vSAN

The guide asks for separate datastores for the operating system, SAP HANA binaries, shared folders, data and logs. It recommends NVMe controllers instead of PVSCSI on modern systems. The data volume is at least the size of RAM, thick-provisioned. The log volume is at least half the RAM on systems up to 512 GB and at least 512 GB, thick-provisioned, on larger ones. Production storage must meet SAP’s key performance indicators, which are measured with the Hardware and Cloud Measurement Tool (HCMT). vSphere HA and DRS for SAP HANA VMs work on Fibre Channel, NFS and vSAN datastores, not on local storage.

On vSAN, the March 2025 post on vSAN 8 ESA says “Only SAP HANA HCI certified systems can be used for SAP HANA deployments”. For VCF 9.1, the May 2026 post requires vendor-defined vSAN policies after deployment, the SAP HANA HCI vSAN detection script on the hosts and new hosts that “must meet or exceed the hardware specifications of the existing systems”. SAP NetWeaver systems on other databases need “no additional validation” on vSAN-ready systems from vendors that support both. Our comparison of vSAN ESA and OSA covers the two architectures and their requirements.

Appliance, TDI or HCI: choosing the hosts

SAP-defined appliance configurations fix the ratio of CPU to memory. The guide says hosts for SAP HANA must be SAP HANA TDI supported systems, and that since TDI Phase 5 a workload-based sizing under SAP Note 2779240 removes the dependency on “appliance configurations with fixed CPU-to-memory ratios”. HCI solutions on vSAN are vendor-specific and SAP ICC-certified, and Broadcom refers to SAP’s Certified and Supported SAP HANA Hardware Directory for the certified VCF-based systems.

In a VMware estate of 10 to 60 hosts, these rules point to a separate cluster or VCF workload domain for SAP HANA, with hosts of the same specification. The guide’s HA and vMotion support depends on shared storage, and vMotion of a large VM takes longer: “vMotioning a 2TB SAP HANA VM or a 12TB SAP HANA VM will take significantly more time to be migrated”. Large hosts have many cores, and how VVF and VCF count them is explained in our guide to VMware licensing after Broadcom.

Worked example: SAP HANA systems in a 40-host estate

Take a company with 40 vSphere 8 hosts and these SAP HANA systems: S/4HANA production at 1.5 TB, quality assurance at 1.5 TB, development at 512 GB, a sandbox at 512 GB and a BW system at 3 TB. On new 2-socket Xeon 6 hosts with 2 TiB per socket, the layouts Broadcom published for VCF 9 (sizing table above) place them as follows; for vSphere 8, check the maximums in SAP Note 3372365 first. The BW system takes one host as a two-socket VM of up to 344 vCPUs. S/4HANA production and quality assurance share a second host, one socket each. Development and the sandbox take one socket each on a third host. A fourth host of the same specification gives vSphere HA room to restart the largest VM after a host failure.

The four hosts sit in their own cluster with shared Fibre Channel or NFS storage that passes the HCMT KPIs, or form a certified HCI solution on vSAN in VCF 9.1. The guide’s rule excludes management components and non-SAP HANA VMs from production hosts; it does not address quality assurance next to production, so check SAP Notes 3372365 and 3663150 before you combine the two on one host. If development grows into more half-socket VMs, those go on SNC-2 hosts in a separate cluster.

Our VMware optimisation service audits versions, subscriptions and resource usage, and our engineering partner Vixen.UNO modernises vSphere and vSAN in agreed maintenance windows. Tell us which SAP HANA systems you run, with their memory sizes and host CPUs.

Moving SAP HANA VMs to Xeon 6 hosts and VCF 9

Broadcom’s January 2026 post gives these migration steps from older hardware:

1. Verify the SAP HANA VM sizing and choose a Xeon 6 configuration that avoids oversizing, with a turbo frequency comparable to the previous CPU.
2. Add the new host to an existing vSphere cluster or create a new one.
3. Shut down the VM and migrate it offline to the new host.
4. Upgrade the VM hardware version to at least 21 (vSphere 8) or 22 (vSphere 9).
5. Adjust cores per socket and memory alignment to the new host’s NUMA topology.
6. Start the VM and validate performance and stability.

Step 3 is an offline migration, so plan the downtime of each SAP system with the SAP basis team. Since Xeon 6 is supported on vSphere 8, the hardware move and the platform upgrade to VCF 9 can be two separate maintenance windows.

Our engineering partner Vixen.UNO carries out cross-cluster migrations in agreed maintenance windows, with a rollback plan at every stage. Describe your current hosts and target version in the form below.

What we do

Our VMware optimisation service audits the estate and licences, matches Broadcom editions to the workloads and modernises vSphere, vSAN and VCF, with engineering by our partner Vixen.UNO. In an estate with SAP HANA, the audit covers versions, subscriptions and resource usage, and the action plan sets dates ahead of renewal and end of support. Changes run in agreed maintenance windows with a rollback plan, and after the project we provide support under an agreed SLA. The first call is free of charge; the price of the technical assessment is fixed before work begins.

FAQ