Some Design Considerations for virtualizing SAP on VMware vSphere

Recently I was working with one of the customer who was migrating his SAP environment from IBM AIX to Cisco’s UCS platform and the customer was looking for some Best Practices from a VMware standpoint. I thought, this would make a good blog post.

There’s lot of information out there, but the following should help you get started.

So here they are:

  • The basis team should leverage Early Watch Reports to come up with sizing for the SAP virtual machines. Use requirements from the basis team for the application and DB servers for all the modules. The sizing should be done based on their existing environment and its utilization. 
  • Follow SAPS based workload Sizing recommendations. 
  • Reserved all memory based on SAP best practices for production. Definitely no overcommitment of Memory. 
  • Size VMs so that CPU and memory will fit within NUMA boundaries.
  • Reserve Memory for SAP Production Virtual Machines. 
  • Ensure database servers separate LUNS for data , logs, and archive.
  • The Guest OS swap will be separated to a LUN that is not replicated.
  • The boot disk and all other disk partitions should be aligned for optimal performance at the VMFS and the OS level.
  • Leverage Cisco UCS service profile to create consistent server Hardware configurations.
  • Plan vCPU per CPU core based on applications requirements. HT should be enabled to reduce impact of over commitment.
  • The ESX hosts for the SAP environment needs to exist in a dedicated cluster with its own networking and storage zoning.
  • Ensure virtual machines are configured to fit within NUMA nodes. 
  • Host profiles should be leveraged to ensure consistent configuration across all ESX hosts in the cluster.
  • Database Storage Design should be similar to Physical. We also need to factor in space to be used by the .vswp files in the Virtual Machines. The size of a .vswp file is equal to Total configured memory – reservation if provided. So if no reservations are provided, then the size of each .vswp file is equal to the amount of memory and hence the Storage sizing needs to factor that as well for the overall sizing. 
  • Use separate LUNs for OS,Data and Swap. 
  • Dedicate LUNs provided for DB related files to guarantee the required performance. 
  • All Database and Application disks should be Eager-Zero Thick Provisioned. 
  • Guest Page Files should be stored in a separate disks. 
  • At the Storage level, use Thick Provisioning. 
  • Use the UCS capability to create vNICs for separate ports for management,vMotion and Production traffic. Separate them by VLANs. 
  • The standard SAP Rules apply for Databases. See SAP Note 592393. 
  • See SAP Note 1056052 for additional vSphere Guidelines – 


Few good online resources:


Also note there was a recent announcement at SAPHIRE 2016, few days back(17th May) that SAP supports SAP HANA on vSphere 6 . Please see 

Happy Virtualizing!!



CentOS7 Customization needs vCenter Server 5.5 U3

Holla! It’s been some time that I wrote on my blog, I am happy to share my recent experience with one of the customer who runs a private cloud built out of the vCloud Suite.

The customer is running a 6.2 vRealize Automation built on top of vCenter Server 5.5 U2d and ESXi 5.5U2. The R&D Team immediately needed a couple of CentOS7 machines to run their builds, however the current catalog did not have it.

The Cloud Infrastructure and Management  team curated a CentOS7 machine and built it as per their organizational standards and had VMware Tools installed, created a template and finally got that added as a catalog item on the vRA Catalog list.

Here comes the situation: VMs provisioned by the vRA portal were being allocated IP Addresses from the Network Profiles, however when we logged into those CentOS7 machines, we did not see any IPv4 assigned to it(it showed a IPv6). Neither did we see the IP Address on the Summary page of the VM on the vSphere Web Client/vSphere Client.

We were already running CentOS6.6/RHEL6/RHEL7 as catalog items and they were just running perfectly fine! What could be wrong with CentOS7? After all we were using the same Customization Specification for all Linux based machines!!

Ok. So lets do a recap – vRA provisioned the machine, it allocated an IP from the Network Profile, it also initiated a Customize Machine workflow to get it customized and it was powered on. We verified this by looking at the Tasks and Events of that machine as well, all of them were Completed successfully.

The customization tasks showed us a line stating that “For details, reference the log file /var/log/vmware-imc/toolsDeployPkg.log in the guest OS”

We looked into the file and we see that the IP Address field was blank in the toolsDeploypkg.log file which hinted us that probably there is something wrong with the Guest Customization Specification. But hey, how come we were able to successfully provision other VMs out of the same spec!

This made us turn to our favourite messiah – Google!! and we stumbled upon by @plankers .

The trick was to fool the customization spec to believe that /etc/redhat-release stated “Red Hat Enterprise Linux Server release 7.0 (Maipo)”

Once this was done, the trick worked!!!

Only after this we saw this really important document – Guest OS Customization Support Matrix at which stated the obvious – CentOS7 requires vCenter Server to be at the 5.5 Update 3 Build, which we were not.

The above is a hack(definitely not supported by VMware Support), I would highly recommend you to get the Upgrade done.

However in my customer’s case, where the Upgrade had a lot of dependencies, this was a quick and dirty way to get CentOS7 machines to the R&D folks, which made them happy!!

Thanks to @plankers.

Lessons learned:

  1. Pre-requisites – Check compatibility guides, in this case the GOS Customization Support Matrix.
  2. Search better in Google! 😉