SAP HANA VM Sizing on VCF 9: NUMA, vCPU and Memory

This SAP HANA VM sizing guide is part of the VCF 9 SAP HANA TDI design guide.

Short answer: SAP HANA VM sizing on VCF 9 is NUMA sizing. A HANA VM gets a half socket (only with SNC-2 where the CPU requires it), one socket, or a whole number of sockets, and nothing in between. It gets every logical CPU of the NUMA nodes it spans (vCPUs = threads, not cores), and it gets the memory of those nodes minus what ESX needs, fully reserved. Latency Sensitivity stays at Normal, CPU hot add stays off, and on consolidated hosts each virtual NUMA node is pinned to a physical one with sched.nodeX.affinity. SAP support for vSphere in VCF 9 is published in SAP Note 3663150. As of 16 October 2026 the public Broadcom material lists Intel Xeon from 2nd Gen up to Xeon 6 with P-cores. Check the note for your exact CPU, socket count and 9.x build before you order hardware.

Table of Contents

What SAP supports on VCF 9 today

Three SAP Notes matter for VCF 9, and the numbers are easy to mix up. 3663150 covers SAP HANA on vSphere in VCF and VVF 9. 3703816 covers SAP HANA on vSphere and vSAN in VCF 9, the HCI case. 3372365 is the vSphere 8 note, which is still the reference for hosts you have not upgraded yet. Older notes you will still see quoted are 2652670 (general SAP HANA VM on vSphere note), 3102813 (vSphere 7.0 with up to 12 TB and 448 vCPU VMs) and 2779240 (workload-based sizing, which you need for anything outside the standard appliance configurations). I could not read the notes themselves because they require an SAP login. Everything below comes from Broadcom’s public summaries of them and the Broadcom best practices guide.

Broadcom’s VCF 9 announcement (updated with more validated CPUs) lists Xeon 6 with P-cores (Granite Rapids), 5th Gen (Emerald Rapids), 4th Gen (Sapphire Rapids), 3rd Gen (Ice Lake) and 2nd Gen (Cascade Lake and Cooper Lake). The standard configurations go up to 2 TiB of memory and 172 vCPUs per socket. Socket counts depend on the generation. Granite Rapids is validated on 2-socket hosts, and 4-socket validation was still listed as planned in May 2026. Sapphire Rapids goes from 2 to 8 sockets, with a largest VM of 16 TiB. I found no AMD EPYC entry in any of these sources. VCF 9.1 added vSAN support for 2-socket Granite Rapids, and the VCF 9.1 scheduler post reports HANA certification with two VMs per socket on Xeon 6787P with SNC-2. If you plan anything that is not in those lists, treat it as unsupported until the note says otherwise.

The NUMA rules behind SAP HANA VM sizing

Five rules from the Broadcom best practices guide decide almost every sizing question:

Socket granularity. A HANA VM is 0.5, 1, 2, 3 or more sockets wide. If it needs more than one NUMA node, it gets all the cores of the extra node, and it spans as few nodes as possible.
Threads, not cores. With hyperthreading on (the recommended default), configure twice the core count per socket. A 2-socket VM on 60-core Sapphire Rapids is 240 vCPUs. When the VM does not span every socket of the host, numa.vcpu.preferHT=TRUE keeps its vCPUs on the hyperthreads of its own node.
Half socket depends on the CPU. Two HANA VMs sharing one NUMA node is supported up to Ice Lake. On 2-socket Sapphire Rapids, half-socket VMs need Intel sub-NUMA clustering (SNC-2), so each VM gets its own sub-NUMA node. Two VMs per socket on Granite Rapids also requires SNC-2. SNC-4 is not supported, and SNC-2 is supported only on 2-socket hosts.
No NUMA node sharing with non-HANA VMs. The guide quotes Notes 3102813 and 3372365: other VMs may run on the same host, but not on the NUMA node of a production HANA VM. The exception is 2-socket Sapphire Rapids with SNC-2, where an SAP application server or a vCLS VM may sit on another sub-NUMA node of the same socket.
Memory follows the socket. The vRAM per socket you can give a VM is the host RAM minus the ESX need, divided by the socket count. If the sized database does not fit into one socket’s share, the VM becomes two sockets wide. That is exactly the case the guide calls a poor configuration.

One point where the sources disagree: the April 2024 Broadcom blog on 4-socket Sapphire Rapids says SAP chose not to support half-socket VMs there, while the December 2024 guide and the April 2025 16 TB announcement describe half-socket VMs on 4- and 8-socket Sapphire Rapids as supported. I size 4-socket hosts in full sockets until SAP Note 3663150 confirms otherwise.

SAP HANA VM sizing worked example: a 2-socket and a 4-socket host

Assumptions, so you can redo the math with your own numbers. The CPUs are the top-bin models Broadcom uses in its own tables. Host memory follows the SAP standard of 2 TiB per socket. The ESX memory figure is my assumption. The guide’s Table 10 gives 64 to 256 GB for 2-socket hosts and 128 to 384 GB for 4-socket hosts, but it does not list 4 TB or 8 TB hosts, so I take the top of each range. The guide also says you only know the real value after all VMs with full reservations have been powered on, so treat it as a starting point. vSAPS figures are Broadcom’s estimates, which already include the 10 % virtualization deduction.

Host A: 2 × Intel Xeon 6787P (86 cores), 4 TiB RAM. That gives 172 threads per socket and 344 per host. Memory for VMs is 4,096 − 256 = 3,840 GiB: 1,920 GiB per socket, or 960 GiB per SNC-2 sub-NUMA node.

Four VMs (SNC-2 on): 86 vCPUs, 1 vSocket and up to 960 GiB each, pinned to nodes 0, 1, 2 and 3. Broadcom estimates about 160,000 vSAPS per VM and allows up to 1 TiB per VM.
Two VMs: 172 vCPUs and up to 1,920 GiB each, about 320,000 vSAPS. With SNC off, each VM is 1 vSocket on one physical node. With SNC-2 on, each VM spans two sub-NUMA nodes and gets 2 vSockets with affinities 0,1 and 2,3. The guide recommends SNC-2 mainly for half-socket VMs because a sub-NUMA node has less memory bandwidth, so I leave it off when a host carries only full-socket VMs.
One VM: 344 vCPUs, 2 vSockets, up to 3,840 GiB, about 640,000 vSAPS.

Host B: 4 × Intel Xeon Platinum 8490H (60 cores), 8 TiB RAM. That gives 120 threads per socket and 480 per host. Memory for VMs is 8,192 − 384 = 7,808 GiB, or 1,952 GiB per socket. 8 TB is the largest validated configuration for 4-socket Sapphire Rapids, and 12 TB was explicitly not supported in the 2024 announcement.

Four 1-socket VMs: 120 vCPUs and up to 1,952 GiB each, about 190,800 vSAPS each, with numa.vcpu.preferHT=TRUE and sched.node0.affinity set to 0, 1, 2 and 3.
Two 2-socket VMs: 240 vCPUs, 2 vSockets and up to 3,904 GiB each, with affinities 0,1 and 2,3.
One 4-socket VM: 480 vCPUs, up to 7,808 GiB. Here preferHT is not used, because the VM takes every socket of the host.

The guide’s own example shows why memory leads the decision. A 1,400 GB database needs 80,000 SAPS, which fits into half of a 60-core socket. On a 2 TB, 2-socket host, however, each socket has only about 960 GB after ESX, so the VM has to span both sockets. Adding memory fixes that. Adding cores does not.

VM settings for a HANA VM on VCF 9

Setting	Value	Why	Source
VM hardware version	22 on vSphere 9 (21 minimum on vSphere 8)	Upgrade after you move a VM to new hosts, then realign NUMA	Broadcom VCF 9 SAP blog
vCPUs	All threads of every NUMA node spanned (86, 120, 172, 240…)	Uses the HT capacity and keeps the VM on as few nodes as possible	BP guide, Table 36
vSockets / cores per socket	vSockets = physical (or SNC) nodes spanned	Since vSphere 6.5, cores per socket no longer drives vNUMA, but it still shapes the guest topology	BP guide; KB 340277
`numa.vcpu.preferHT`	TRUE, unless the VM spans every socket	Keeps vCPUs on the hyperthreads of the local node	BP guide; KB 2003582
`sched.nodeX.affinity`	One row per vNUMA node, e.g. node0=0, node1=1	Stops NUMA migrations on consolidated hosts. Required with SNC-2	BP guide, Tables 36 and 37
`Numa.LocalityWeightActionAffinity`	0, only if affinity is not usable	Prevents co-placement on one node through action affinity	BP guide; KB 2097369
`numa.memory.gransize`	32768	Aligns VM memory to the NUMA memory map	BP guide, Table 36
Memory reservation	Full, no overcommit	HANA memory must not be reclaimed	BP guide, Table 36
CPU	No overcommit	Sizing assumes the threads are there	BP guide, Table 36
Latency Sensitivity	Normal	The guide says don’t change it to High or Low unless VMware support tells you to	BP guide, Table 36
CPU hot add	Off	Historically disables vNUMA. vSphere 8 relaxed this, but the guide still requires it off	BP guide; KB 2040375
`sched.mem.enableTiering`	FALSE on hosts with NVMe memory tiering	A full reservation alone does not keep pages in DRAM	Broadcom tiering blogs; KB 448305
Host BIOS	HT on, high-performance power, node interleaving off, SNC-2 only where needed	Exposes the real NUMA topology to ESX	BP guide, Table 34

Persistent memory and NVMe tiering deserve a sentence each. The guide lists Optane PMem for HANA VMs as supported on ESXi 7 only, and as not supported from ESXi 8.0 U1. I found nothing that changes this for 9. For NVMe memory tiering in VCF 9.0, Broadcom says it is not suited to latency-sensitive VMs or VMs with 512 GB or more of memory, and I found no SAP statement that supports it for HANA. On a tiering-enabled cluster, I disable it per HANA VM and keep the full reservation.

Common mistakes

Setting Latency Sensitivity to High because HANA is “latency sensitive”. The HANA guide says Normal.
Counting cores instead of threads. In the guide’s Cooper Lake example, the same SAPS need takes 33 vCPUs and two sockets without HT, but 56 vCPUs and one socket with HT.
Odd vCPU counts such as 100 on a 120-thread socket, which leave a node partly used. Take the whole node or the whole sub-NUMA node.
Sizing vRAM to the socket’s DIMMs and forgetting the ESX share, so the VM spills onto a second node.
Assuming half-socket rules carry over to a new CPU generation. Ice Lake allowed node sharing. Sapphire Rapids 2-socket and Granite Rapids need SNC-2.
Mixing SNC-2 and non-SNC hosts in one cluster without VM-host rules, so a sub-NUMA-sized VM starts on a host where the topology is different.
Leaving vCLS or application VMs on the NUMA node of a production HANA VM on non-SNC hosts.
Hard affinities that collide after an HA event or maintenance mode. Two VMs pinned to node 0 on the same host compete for the same threads. The guide points to the NUMA Observer fling to catch overlaps. A vMotion of a large HANA VM also has a network side, covered in VCF 9 SAP HANA network design: why 6 NICs matter for vMotion and NFS.
Moving a VM to new hosts and keeping the old hardware version and topology.

How to verify the placement

In esxtop, press m for the memory panel and f to add the NUMA statistics. Per VM, NHN is the home node, NRMEM is remote memory, N%L is the local percentage and GST_NDx is guest memory per node. For a correctly sized 1-socket VM you want a single home node, N%L near 100 and NRMEM near zero.

Frank Denneman published a one-liner that lists running VMs with vmdumper -l and pulls the NUMA, vCPU, memory and affinity lines out of each vmware.log. His post dates from 2017, so check the output on your ESX 9 build:

vmdumper -l | cut -d \/ -f 2-5 | while read path; do egrep -oi "DICT.*(displayname.*|numa.*|cores.*|vcpu.*|memsize.*|affinity.*)= .*|numa:.*|numaHost:.*" "/$path/vmware.log"; echo -e; done

For the host side, sched-stats -t numa-pnode shows the CPUs, total memory and free memory of each physical node, sched-stats -t numa-clients shows where VM NUMA clients live, and sched-stats -t numa-migration shows migrations between nodes. If the migration counters keep rising for a HANA VM, its affinity is missing or wrong. Then run HCMT, as for any TDI system.

What I recommend

Size memory first, then fit it into whole NUMA nodes, then check SAPS. Give the VM every thread of the nodes it uses, reserve all of its memory, leave Latency Sensitivity at Normal and pin vNUMA nodes on every host that runs more than one HANA VM. Turn on SNC-2 only on 2-socket hosts that really carry half-socket VMs, and keep those hosts in their own cluster or behind VM-host rules. Write the CPU model, socket count and 9.x build you chose into the design document next to the SAP Note 3663150 revision you checked. When an incident escalates, SAP and Broadcom will check the deviations from these settings first.

SAP HANA VM Sizing and NUMA on VCF 9: A Worked Example

What SAP supports on VCF 9 today

The NUMA rules behind SAP HANA VM sizing

SAP HANA VM sizing worked example: a 2-socket and a 4-socket host

VM settings for a HANA VM on VCF 9

Common mistakes

How to verify the placement

What I recommend

Sources

What SAP supports on VCF 9 today

The NUMA rules behind SAP HANA VM sizing

SAP HANA VM sizing worked example: a 2-socket and a 4-socket host

VM settings for a HANA VM on VCF 9

Common mistakes

How to verify the placement

What I recommend

Sources

Related posts

VCF Certificate Management Tool (vcf-cert-tool): One CLI for Expired Certificates in vCenter, NSX, Supervisor and VCF Operations

How to Check VCF 9 Hardware Compatibility: Servers, CPUs, NICs and vSAN ESA Devices

vCenter and VCF Certificate Troubleshooting: Which Tool or Fix You Need