A lot of customers are using VMware as Hypervisor to run the HANA workload. Since the initial certification of this platform there are some limitations regarding features and sizing. Some of this limitations depending on the vSphere version. With every maintenance you have to take attention to compatibility and parametrization. The most VMware administrators don’t know any of the SAP HANA dependencies. May be this blog is the chance to bring them and your landscape up-to-date before you get support issues.

So, we have two possibilities as maintenance scenarios: the update of the vSphere version and a hardware change (security is another topics which I don’t want to discuss in the HANA context of VMware, because there is no SAP dependency). Both can take place due to support, limitation or feature dependencies.

1. vSphere version
2. Hardware change
3. Miscellaneous

---

1. vSphere version

At first check if your vSphere version is supported with your current hardware. I heard from some customers that the matrix on the wiki page is pretty hard to interpret because it is too big and not handsome.

Long story short: Haswell and Broadwell are currently not supported for vSphere 7.0+. As you can see it is planned for Broadwell. I will update the blog if anything changes.

This means with these old processors (Haswell and Broadwell) you can max. go for vSphere 6.7 U3.

Source: ©2021 VMware, Inc

If you want to go for vSphere 7.0 you have to buy new hardware. If you have such new processor architecture and want to migrate your VMs via vMotion you have to check the EVC compatibility (see below).

Attention:

vCLS: Starting with vSphere 7.0 the VMware Clustering Services vCLS needed to be considered for the sizing. For details check Erik’s blog. vMotion: VM moves over CPU families limits (e.g. Broadwell => Cascade Lake) should be handled carefully due to some limits and performance brakes. Check the EVC modes and compatibilities, but I recommend a general VM restart if you migrate VMs between CPU families although the EVC compatibility is guaranteed. EVC: EVC is short for Enhanced vMotion Compatibility. EVC allows you to migrate virtual machines between different generations of CPUs.

Source: ©2021 VMware, Inc

Why you should go for vSphere 7.0? Normally the virtual performance overhead is about 10-15%. This is the factor the sizings are calculated in the past. The bare metal benchmark of the Fujitsu PRIMEQUEST 3800B2 vs. virtualized benchmark vSphere 7.0 U1 BW benchmark 448 vCPU VM on Fujitsu PRIMEQUEST 3800B2 shows us an overhead of ~3% in phase 1 and an overhead of ~9% in phase 2. Both times below 10%! This means besides the features the performance is another argument for vSphere 7.0.

Just to name some other arguments besides the benchmark performance (more details):

• vMotion performance is 2-3 times faster compared to vSphere 6.7U3
• general support till April 2025

From the perspective of support there is no need to upgrade from ESXi 6.5 to 6.7 besides security aspects. But if you take the features into account you have pmem, scale-out and more than the former limit of 128 vCPUs => depending on the hardware 144 to 256 vCPUs. This is important if you have analytical workload (BW) or special workload like bank analyzer, SCM, IS-U etc.

---

2. Hardware change

Overview:

• 6TB can be only achieved with Skylake and Cascade Lake within HANA on VMware (6.7 U2+)
• vSphere 6.7U2/U3 : Skylake and Cascade Lake up to 224 vCPU
  
• vSphere 7.0 incl. U1/U2: Skylake and Cascade Lake up to 224 vCPU
  

If you don’t want or even can run a scale-out setup because it is not supported for your current environment you have to go for bare metal or IBM Power architecture.

Every time you upgrade the hardware, you also have to check the hardware version of each VM running on the ESXi host. If your VM is e.g. still on version 10, the limits regarding number of cores and the former memory limits are still valid for the VM which means the former ESXi 5.5 limits. I recommend to upgrade the hardware version least on every major release upgrade. If the minor versions have no limitation which hit you and downtime is a driving factor in your business, skip the hardware version update till you really need them. It is just a simple VM restart – not really time intensive. In the end it depends on how many VMs you have to handle and how big is your downtime window.

Source: ©2021 VMware, Inc

Details:

Another topic is NUMA and the vCPU parametrization. So, check the NUMA settings and vCPU settings at least once a year. If you change the hardware which normally means also that the number of cores per socket are increasing, you have to adjust your settings. Check e.g. parameters like numa.autosize.vcpu.maxPerVirtualNode and numa.vcpu.preferHT regarding your sizing, because this parameters won’t be adjusted automatically. This means also have an eye on your NUMA settings! Therefor another blog exists.

---

3. Miscellaneous

1. Parameter
2. Certification

Pmem is available since vSphere 6.7 EP14 or vSphere 7.0 P01. Please check the wiki page for details.

Please refer SAP note 2700084 and SAP Note 2786237 – Sizing SAP HANA with Persistent Memory for details on compute and memory sizing for Optane PMem enabled SAP HANA systems.

vSAN

Check the wiki page for more details about vSAN

Parameter

Check the table from VMware

Certification

The SAP HANA installation must done by an SAP certified engineer, qualified as SAP Certified Technology Specialist – Required exam: C_HANATEC_16+

If there is no one with valid certification in your company you know there are some outstanding consultants out there – ready to support you

---

Summary

Your check list for VMware maintenance in a HANA context:

• check compatibility of hardware and vSphere versions
• check feature compatibility
• check EVC
• check sizing (overcommitment and noisy neighbours)
• check hardware version
• check VMware parameters

In the end – like every maintenance with SAP HANA – you have to do some pre-checks, because not every scenario is supported.

Sources:

wiki: SAP HANA on VMware vSphere
SAP Note: 2393917 – SAP HANA on VMware vSphere 6.5 and 6.7 in production
SAP Note: 2937606 – SAP HANA on VMware vSphere 7.0 in production
wiki: SAP HANA based Applications on VMware vSAN (SAP HANA HCI)
wiki: SAP HANA with Persistent Memory on VMware vSphere
SAP Note: 2954515- SAP HANA Persistent Memory – memory mode
SAP Note: 2913410 – SAP HANA on VMware vSphere with Persistent Memory
SAP Note: 2786237 – Sizing SAP HANA with Persistent Memory
SAP Note: 2700084 – FAQ: SAP HANA Persistent Memory