Home > Blogs > Virtualize Business Critical Applications

Oracle on VMware vSphere & vSAN – Preparing for an the Oracle Audit

In the last post , we addressed the Licensing fuds and myths when it comes to addressing Oracle Licensing on VMware vSphere / VSAN technologies and explained how Oracle licensing DOES NOT change from a licensing perspective, whether you run Oracle workloads on a classic vSphere environment or Hyper-Converged Infrastructure solution like VSAN.

This post endeavors to explain how to go about an Oracle Licensing audit effectively by meticulously collecting all artifacts needed for the audit.

FUD

Googling the word FUD does certainly explains clearly the meaning and intention of this oft used word in the Oracle Licensing space.

 

Oracle License Audit

Having put these myths to rest, let’s talk about the “Oracle License Audit” process. Many horror stories have been echoed in the hallways of IT and around water coolers but the key thing to keep in is “Yes, we need to take that seriously but no reason to be scared about it!!! , it’s just another software audit”.

The key mantra is to be “Fully prepared for it with all relevant artifacts to defend the audit”.

We have well established beyond any reasonable doubt in the previous blog post that Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, it’s either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition).

 

Successfully defending an Oracle Audit

The primary goal of effectively defending an Oracle Licensing Audit on VMware vSphere/VSAN is to prove that an effective “Compute Segmentation” has been done to ensure that Oracle Virtual Machines runs on dedicated ESXi servers in the datacenter, because again, to re-iterate, Oracle licensing is Compute (SE2/EE)  /  User (NUP) based.

We can achieve the above goal in 2 ways
1)    Create a “Compute Enclosure” to prevent VM’s from leaving the enclosure by any means whatsoever
2)    Establishing an auditing mechanism of documenting  VM movements via vMotion events in the above “Compute Enclosure”

 

Create “Compute Enclosure”

There are 2 ways to create the “Compute Enclosure”:

Option A: Dedicated vSphere Cluster for Oracle VM’s (Recommended). This model is a widely accepted model purely from an Oracle licensing perspective.

Option B: Common vSphere Cluster where we use Affinity rules to bind Oracle VM‘s to a set of ESXi servers dedicated for Oracle workloads

Either of the 2 ways are acceptable as the Oracle OLSA / OMA does not stipulate anything about vSphere Cluster apart from the definition of the Processor as “Processor shall be defined as all processors where the Oracle programs are installed and/or running.”

In case of option B, the process of pinning Oracle VM’s to ESXI hosts have been explained in the previous blog post

https://blogs.vmware.com/apps/2017/01/oracle-vmware-vsan-dispelling-licensing-myths.html

Having created the “Compute Enclosure” i.e. a vSphere Cluster for Oracle Workloads, now we need to establish an auditing mechanism of documenting the Oracle VM movements by tracking the movement of the Oracle VM’s via vMotion events within the above “Compute Enclosure”.

 

Establishing Audit Mechanisms

Audit Information about VM Power on/off event

In the previous blog post, we showed how the VM Power On operations audit information is recorded in the vmware.log file.
https://blogs.vmware.com/apps/2017/01/oracle-vmware-vsan-dispelling-licensing-myths.html

Let’s see the contents of the vmware.log file for “testoravm” when we power it up on a vSAN Cluster

[root@w2-pe-vsan-esx-029:/vmfs/volumes/vsan:52803547e520f694-1f6104395ada7b7c/05735458-cc86-e1e9-ca71-0025b501004e] cat vmware.log
2016-12-27T21:09:09.124Z| vmx| I125: Log for VMware ESX pid=2597049 version=6.5.0 build=build-4564106 option=Release
2016-12-27T21:09:09.124Z| vmx| I125: The process is 64-bit.
2016-12-27T21:09:09.124Z| vmx| I125: Host codepage=UTF-8 encoding=UTF-8
2016-12-27T21:09:09.124Z| vmx| I125: Host is VMkernel 6.5.0
2016-12-27T21:09:09.091Z| vmx| I125: VTHREAD initialize main thread 0 “vmx” tid 2597049
2016-12-27T21:09:09.092Z| vmx| I125: Msg_SetLocaleEx: HostLocale=UTF-8 UserLocale=NULL
……….
……….
2016-12-27T21:09:09.124Z| vmx| I125: Hostname=w2-pe-vsan-esx-029
2016-12-27T21:09:09.124Z| vmx| I125: IP=127.0.0.1 (lo0)
…..
[root@w2-pe-vsan-esx-029:/vmfs/volumes/vsan:52803547e520f694-1f6104395ada7b7c/05735458-cc86-e1e9-ca71-0025b501004e]

The Power On process of an Oracle VM on a classic vSphere Cluster also records the information of the host it powers on, no different than the o/p we see above on a vSAN Cluster.

[root@wdc-esx10:/vmfs/volumes/56bce95e-eb1c7670-1464-0025b3b1b790/Template_OEL70] more vmware.log
2016-11-02T04:36:09.871Z| vmx| I120: Log for VMware ESX pid=3165445 version=6.0.0 build=build-3029758 option=Release
2016-11-02T04:36:09.871Z| vmx| I120: The process is 64-bit.
2016-11-02T04:36:09.871Z| vmx| I120: Host codepage=UTF-8 encoding=UTF-8
2016-11-02T04:36:09.871Z| vmx| I120: Host is VMkernel 6.0.0
2016-11-02T04:36:09.854Z| vmx| I120: VTHREAD initialize main thread 0 “vmx” pid 3165445
2016-11-02T04:36:09.854Z| vmx| I120: Msg_SetLocaleEx: HostLocale=UTF-8 UserLocale=NULL
….
2016-11-02T04:36:09.856Z| vmx| I120: DictionaryLoad: Cannot open file “//.vmware/config”: No such file or directory.
……..
2016-11-02T04:36:09.859Z| vmx| I120: PREF Failed to load user preferences.
2016-11-02T04:36:09.872Z| vmx| I120: Hostname=wdc-esx10.tsalab.local

 

Audit Information about VM vMotion event

Let’s see the contents of the vmware.log file of an Oracle VM when we vMotion it from one ESXi server to another ESXi server within a vSphere Cluster

[root@wdc-esx10:/vmfs/volumes/56bce95e-eb1c7670-1464-0025b3b1b790/Template_OEL70] more vmware.log
2016-11-02T04:36:09.871Z| vmx| I120: Log for VMware ESX pid=3165445 version=6.0.0 build=build-3029758 option=Release
2016-11-02T04:36:09.871Z| vmx| I120: The process is 64-bit.
2016-11-02T04:36:09.871Z| vmx| I120: Host codepage=UTF-8 encoding=UTF-8
2016-11-02T04:36:09.871Z| vmx| I120: Host is VMkernel 6.0.0
2016-11-02T04:36:09.854Z| vmx| I120: VTHREAD initialize main thread 0 “vmx” pid 3165445
2016-11-02T04:36:09.854Z| vmx| I120: Msg_SetLocaleEx: HostLocale=UTF-8 UserLocale=NULL
….
2016-11-02T04:36:09.856Z| vmx| I120: DictionaryLoad: Cannot open file “//.vmware/config”: No such file or directory.
……..
2016-11-02T04:36:09.859Z| vmx| I120: PREF Failed to load user preferences.
2016-11-02T04:36:09.872Z| vmx| I120: Hostname=wdc-esx10.tsalab.local

The VM was initially powered on wdc-esx10.tsalab.local server.

When the Oracle VM vMotion to another ESXI server either done manually or through DRS events the vMotion entries along with the source and target ESXI servers are recorded in the vmware.log file.

In the above case the Oracle VM vMotioned from wdc-esx10.tsalab.local server to wdc-esx09.tsalab.local server

root@wdc-esx10:/vmfs/volumes/56bce95e-eb1c7670-1464-0025b3b1b790/Template_OEL70] more vmware.log
…..
2016-11-02T04:44:38.156Z| vmx| I120: MigrateVMXdrToSpec: type: 1 srcIp=<10.128.136.110> dstIp=<10.128.136.109> mid=5404a192575ee uuid=38383135-3735-5355-4530-343132465936 priority=yes checksumMemory=no maxDowntime=0 encrypted=0 resumeDuringPageIn=no latencyAware=yes diskOpFile= srcLogIp=<<unknown>> dstLogIp=<<unknown>>
….

2016-11-02T04:44:38.156Z| vmx| I120: Received migrate ‘from’ request for mid id 1478061877196270, src ip <10.128.136.110>.
….
…..
2016-11-02T04:44:38.156Z| vmx| I120:    OpType: vmotion
…..
2016-11-02T04:44:38.200Z| vmx| I120: UNAME VMkernel wdc-esx09 6.0.0 #1 SMP Release build-3029758 Aug 31 2015 00:54:00 x86_64 (uwglibc release: vmware, version: 2.12.2)

The above audit trail entries are able to correctly report on the below events
•    VM Power on / off
•    VM vMotion to / from

The same Audit entries can also be captured from the vCenter database by mining the database for VM Power on / off and VM vMotion to / from events. We need to be mindful of the purge retention settings for Oracle/SQL Server vCenter database in order to ensure that we have audit trail entries for at least 2-3 audit cycles.

As we can see by creating a “Compute Enclosure” and establishing a “Effective Audit Mechanism”, we can conclusively day without any doubt that the Oracle VM’ always lived and migrated within the “Compute Enclosure” and never wandered outside !!!.

Tools to help gather audit trail

Another product from VMware which helps for purpose of Oracle Auditing is the VMware vRealize Log Insight which delivers heterogeneous and highly scalable log management with intuitive, actionable dashboards, sophisticated analytics and broad third-party extensibility. It provides deep operational visibility and faster troubleshooting across physical, virtual and cloud environments.

VMware LogInsight dashboard can help customers gather by means of audit trail records which can then be presented to Oracle LMS team as proof of Oracle workload footprint within a vSphere Cluster or a vSAN cluster.

The video below demonstrates the capabilities of VMware vRealize LogInsight for Oracle License Compliance
https://www.youtube.com/watch?v=EHcT4xDyONc

Also keep in mind the below listed controls demanded by licensing zealots is completely un-necessary and non-contractual.

-Not needed to create Network Segmentation to separate and dedicate a network segment for the vSphere Cluster for Oracle workloads

-Not needed to create Storage Segmentation to zone, map and mask Oracle specific storage LUNS to only the ESXI servers  in the dedicated vSphere Cluster for Oracle

-Do not run PowerCLI scripts / commands against the vCenter database which shows all the ESXI servers connected to the vCenter regardless of whether they are part of the vSphere dedicated cluster for Oracle or not.

If you have to run it to gather information about the ESXi servers in the Oracle vSphere Cluster, login as the user who has access to only the Oracle cluster so that way it reduces the scope of discovery to only the Oracle Cluster

This is the document which is handed out to Customers which has information how to gather information about the ESXi servers connected to the Virtual Center , it does not specify running the script against the Oracle vSphere Cluster.

 

 

A key point to keep in mind is if this document is really contractual , why is this NOT public facing ?

-Do not give access to any auditor the keys of the kingdom i.e. vCenter username and password

Really, what’s next? Separate the vSphere Cluster for Oracle in its own cage in the data center and ensure no one goes near it!! Throw a black cloth around the cage so that no one can see what’s in it?

Both of the above steps are completely un-necessary as we have well established beyond any reasonable doubt in the previous blog post that Oracle licensing is not Memory, Storage, Cluster, vCenter or Network based, it’s either User based (Named User Plus) or Processor(Socket in case of SE2 or cores in case of EE edition).

 

Artifacts helpful for an Oracle Licensing Audit defense

Here are some of the important artifacts which are useful for an Oracle Licensing audit defense

1)    Proof of Compute Enclosure
a.    Screenshot of the vSphere dedicated cluster for Oracle Workloads

b.    Screenshot of one of the ESXI servers in the cluster which clearly shows Processor Family, number of Socket and number of Cores

The Effective number of cores calculation can be found in the previous blog post
https://blogs.vmware.com/apps/2017/01/oracle-vmware-vsan-dispelling-licensing-myths.html

2. Audit Trail entries which are log file entries for every Oracle VM which shows the Power on /off and vMotion to / from operations.

VMware LogInsight can be used to extract these entries and the video below demonstrates the capabilities of VMware vRealize LogInsight for Oracle License Compliance:
https://www.youtube.com/watch?v=EHcT4xDyONc

The same Audit entries can also be captured from the vCenter database by mining the database for VM Power on / off and VM vMotion to / from events. We need to be mindful of the purge retention settings for Oracle/SQL Server vCenter database in order to ensure that we have audit trail entries for at least 2-3 audit cycles.

Conclusion
In conclusion, Oracle Licensing Audit should not be taken lightly just as you would for any other software vendor but not special and one does not have to fear it.

Be prepared with all the audit artifacts as detailed above.

 

Need Help?
For any additional Oracle Licensing on VMware clarification or help, please reach out to your respective VMware Account teams who can get our team involved in a discussion (Internal VMware folks can reach directly to us at the Tier1-Apps-Sales-Support team mailing list) and we can definitely help guide you and connect you to some of our Premier specialist partners for further discussions.

Oracle on VMware SDDC Collateral
All Oracle on vSphere white papers including Oracle licensing on vSphere/vSAN, Oracle best practices, RAC deployment guides, and workload characterization guide can be found in the url below

Oracle on VMware Collateral – One Stop Shop [Customer]
https://blogs.vmware.com/apps/2017/01/oracle-vmware-collateral-one-stop-shop.html

Run your Cloud Native Applications in production with vRealize Automation XaaS scalable components

CNA_cloud-logo

Cloud Native Applications are getting some momentum. Still there is some reticence to run these in production on premise, particularly for the applications that could become business critical.
VMware mission is to be here to help. As part of our container portfolio we do have Photon OS to run containers, enterprise-class features with vSphere Integrated Containers (VIC) and a  secure and scalable Platform as a Service with Cloud Foundry.

In the case there is a requirement for managing the life cycle of the container infrastructure as often the case for other IaaS applications vRealize Automation has some features that can help extend Photon OS availability in production.

If you are in charge of the infrastructure and have to make critical cloud native applications available in production on vSphere you may start with deploying a Photon Blueprint. Still your application may be very vulnerable. Even if Photon OS does include swarm, a Docker native clustering it still need to be managed to provide high availability and scalability. Also access to the Docker APIs is not secured.

In this blog post I will leverage vRealize Automation features to create blueprints for highly available and scalable Cloud Native Applications.

 

How I designed my HA, scalable Photon blueprint.

To make the application deployment highly available I did set the cluster option on the blueprint VM. This also provide VM based scale out and scale in day 2 operations.
To make the application cluster aware I have created a “Create docker Node” vRealize Orchestrator workflow calling the swarm API to enable swarm and join new photon hosts. I also have a “Scale in node” workflow for removing a node from the swarm or all of them when decommissioning the deployment.

While this automation gives some great flexibility. I wanted to manage individual swarm nodes from the vRealize Automation user interface:

  • Request a swarm with 2 to 8 nodes

Picture1

  • See in the vRA user self service portal the swarm nodes as distinct component running in a deployment and be able to check their properties

Screen Shot 2017-05-15 at 21.44.31

  • Scale out / Scale in Photon swarm deployment

Screen Shot 2017-05-15 at 21.46.59

  • Contextually  run node specific day 2 operations in vRA without having to switch to a CLI or third party interface
  • Manage who has access to these day 2 operations using vRA entitlements and optionally approve some operations
  • Monitor the full life cycle of the app including day 2 operations

 

vRealize Automation 7.2 XaaS scalable components as a solution for managing Photon Swarms

An XaaS scalable component is a blueprint XaaS component that can be scaled independently from the blueprint VMs. I created my own “Docker node” resource using vRO Dynamic Types and could reuse the Create and Scale in workflows to leverage this new resource type.

Picture2

A benefit from this design is that I can scale out in almost real time since I can pre-provision the VM used to scale out and just start it / join it to the swarm on node scale out.

Picture3

Then to secure the application access to the API I had two options:

  • Via a certificate
  • Using an NSX virtual Firewall Rule which is one of the vRA blueprint component

This way each swarm can only be managed by the vRO server which in turn is used by vRA end users that can only operate the applications they own.

As you can see reading this post we managed to enable, manage and combine vRealize Automation and Photon scalability and security features providing a very flexible, as a service on premise enterprise ready Cloud Native app solution.

VMworld 2017 Oracle Customer Bootcamps

VMworld 2017 Oracle Customer Bootcamps

On a mission to arm yourself with the latest knowledge and skills needed to master application virtualization?

reading book

VMworld Customer bootcamps can get you in shape to lead the virtualization charge in your organization, with Instructor-led demos and In-depth course work designed to put you in the ranks of the IT elite.

Oracle on vSphere
The Oracle on VMware vSphere Bootcamp will provide the attendee the opportunity to learn the essential skills necessary to run Oracle implementations on VMware vSphere. The best practices and optimal approaches to deployment, operation and management of Oracle database and application software will be presented by VMware expert Sudhir Balasubramanian who will be joined by other VMware and Industry Experts.

This technical workshop will exceed the standard breakout session format by delivering “real-life,” instructor-led, live training and incorporating the recommended design and configuration practices for architecting Business Critical Databases on VMware vSphere infrastructure. Subjects such as Real Applications Clusters, Automatic Storage Management, vSAN and NSX will be covered in depth.

Learn More

https://www.vmworld.com/en/us/learning/sessions.html?mid=9592&eid=CVMW2000001358867&elqTrackId=ac4f78fd201d4b8ea8c06c94903ec64e&elq=a30d659ad2934a969e912b357d9624d2&elqaid=9592&elqat=1&elqCampaignId=4153

Details

Cost: $725 / seat

Schedule:
Saturday August 26, 2017
8:00am to 5:00pm
(registration opens at 6:30am)

Location:
Mandalay Bay, South Convention Centre
3rd Floor Jasmine Rooms

Registration

Be sure to add the Bootcamp in step 4 of your VMworld conference registration, under Educational Offerings, after you’ve selected your conferences pass.

Registration is open, seating is limited! Lunch and breaks provided.

Looking forward to seeing you all there!

SAP HANA on VMware vSphere, Multi-VM Support Status as of May 2017

Since my last SAP HANA blog in February, our SAP HANA validation and engineering team was busy performing the remaining validation test on the Intel Broadwell platform.

Because of the positive results, SAP granted us Multi-SAP HANA VM and NUMA node sharing support for vSphere 6.0 and 6.5 on the 4 socket Intel Broadwell platform up to 4 TB VM sizes.

By now we have five SAP support notes that describe the support status of SAP HANA on VMware vSphere. This blog concentrates on Multi-VM configurations. For a complete overview of what is SAP supported please visit the SAP HANA on VMware vSphere Wiki pages on wiki.scn.sap.com.

The first table in this blog shows the SAP HANA Multi-VM configuration status and what is supported in production. The 2nd table shows what is VMware platform supported, but was not explicitly validated for SAP HANA workloads.

Continue reading

Oracle Database 12c on VMware vSAN — Day 2 Operations and Management

Oracle Database 12c on VMware vSAN — Day 2 Operations and Management

Customers deploying production Oracle workloads have stringent requirements to support and maintain critical database operational tasks such as Backup and Recovery, Cloning, Data Refresh for Development/Test environment and Patching. These operational tasks are also known as Database Day 2 Management Operations.

With the rapid adoption of VMware vSAN™ for business-critical workloads due to highly scalable , available , reliable and high performance HCI solution. It is essential to provide features and tools for seamless Day 1 and Day 2 Operations.

vSAN offers a range of tools and features for Day 1 and Day 2 Operations. VMware vSphere® web client provides administrator with the capability to manage their infrastructure in a unified way for deploying, provisioning, health check, and performance monitoring. vSAN 6.0 and above has improved snapshot capability, which provides users with enterprise-class snapshots and clones that can be used for Oracle database cloning use cases.

The Oracle Real Application Clusters on VMware vSAN reference architecture addresses common business challenges that CIOs face today in an online transaction processing (OLTP) environment that requires availability, reliability, scalability, predictability and cost-effective storage, which helps customers design and implement optimal configurations specifically for Oracle RAC Database on vSAN.

The Oracle Database 12c on VMware vSAN 6.2 All-Flash reference architecture addresses common business challenges that CIOs face today in an OLTP and decision-support-system (DSS) environment that requires predictable performance and cost-effective storage.

Having addressed the Day 1 operations including deployment and provisioning of critical Oracle workloads on VMware vSAN, this operation guide focuses on the Day 2 Operations of Oracle on vSAN including backup and recovery, database cloning, database refresh for test and development environment and database patching.

 

Diagram

 

VMware vSAN snapshot and clone technologies are primarily used for providing support to Oracle Day 2 Operations. VMware vSAN snapshot and clone technologies used with inherent Oracle tools provide efficient Day 2 Operations for business-critical Oracle database.

Check out the recently published Oracle Database 12c on VMware vSAN — Day 2 Operations and Management  operation guide that provides solutions and operation procedures for Oracle Database Day 2 Operations including below key oracle database tasks using vSAN snapshots and clones:

  • Backup and recovery
  • Cloning
  • Data refresh for development and test environment from production
  • Patching

While the operation guide provides above solutions natively for the Oracle database on vSAN environment. There are backup vendors who provide Oracle application-level integration along with VADP (VMware vSphere Storage APIs – for Data Protection) API integration, which can help in ease of backup/cloning, greater levels of manageability and control in vSphere environment including vSAN. These third-party backup solutions can also be used for these use cases.

Further, with the announcement of VMware Ready for vSAN program that offers partners a set of tools, resources, and processes needed to certify Data Protection products with VMware vSAN. This certification program will provide confidence with the partner data protection solutions deployed in VMware vSAN environments for seamless operation.

VMware Adapter for SAP Landscape Management – Connector for vRealize Automation 1.1

The  VMware Adapter for SAP Landscape Management just got better and provides now a connector for vRealize Automation 1.1!

Our Integrated Systems Business Unit, just released the VMware Adapter for SAP Landscape Management – Connector for vRealize Automation 1.1.

Why is this important?

The  vLA Connector for vRealize Automation feature allows SAP and VMware admins to publish SAP systems to vRealize Automation so that SAP Users can consume these contents themselves directly from vRealize Automation.

The new connector augments the automation power of VMware Adapter for SAP Landscape Management 1.4.1, which leverages capabilities of SAP Landscape Management (LaMa) and VMware SDDC, and empowers SAP customers to provision and manage SAP application seamlessly.

Continue reading

RUSH POST: VMware Tools and RSS Incompatibility Issues

UPDATE:

We have just released a new version of the VMware Tools which fixes the issue described in this post (below).

Please download and install this version of the VMware Tools, especially if you are using the VMXNet3 vNIC type for your Windows VMs.

We thank you very much for your patience and understanding while we worked on fixing this problem.

From the Release Notes:

Receive Side Scaling is not functional for vmxnet3 on Windows 8 and Windows 2012 Server or later. This issue is caused by an update for the vmxnet3 driver that addressed RSS features added in NDIS version 6.30 rendering the functionality unusable. It is observed in VMXNET3 driver versions from 1.6.6.0 to 1.7.3.0.

Continue reading

Updated – Official SQL Server on vSphere best practices guide, March 2017

Microsoft SQL Server is the most virtualized enterprise mission critical application today. In recent years it has become a mainstream effort among VMware customers to virtualize critical databases to allow better agility and scale while increasing availability and operational efficiency.

The official best practices guide for virtualizing SQL Server is now updated with information regarding vSphere 6.5 and some new lessons learned in the past year.

A big Thank you! is due to:

Allan Hirt (Twitter @SQLHA) for keeping me honest on SQL Server nomenclature

David Klee (Twitter @Kleegeek) for his help reviewing this paper

Deji Akomolafe (Twitter @dejify) for his expertise and contribution

You can read the updated guide
here: http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

As always, comments and feedback are welcome

Niran

VMware Adapter for SAP Landscape Management 1.4.1 – Automate and manage your VMware virtualized SAP Landscape

On behalf of David Gallant, ISBU, Product Management and the Integrated Systems Business Unit, we are very pleased to announce the General Availability of VMware Adapter for SAP Landscape Management 1.4.1.

VMware Adapter for SAP Landscape Management integrates SAP Landscape Management (LaMa) with VMware Software-Defined Data Center (SDDC) technologies, allowing SAP BASIS administrators, VMware administrators, SAP project and business stakeholders to automate provisioning and management of SAP landscapes running on VMware’s SDDC. The adapter is a key component of VMware private cloud solution for SAP, which defines the software stack to virtualize, secure and automate SAP environments leveraging VMware’s software-defined architecture. At its core, it includes VMware vSphere, VMware NSX, vRealize Automation and the VMware Adapter for SAP Landscape Management and will help to bring SAP Consumers closer to IT Providers, by leveraging for instance an optional service portal to perform SAP system deployments and management tasks instead of using administrator and system tools.

Below figure shows how providers and consumers can leverage the VMware Adapter for SAP Landscape Management.

VMware Adapter

This release of the adapter is a very important maintenance release. With this release, we continue to enhance support for vRealize Automation and the system automation application interface (SA-API).  These enhancements pave the way for additional customers to adopt SAP LaMa, and VMware’s SDDC.

Continue reading

Multiple production SAP HANA virtual machines on a single physical server on vSphere 6

Last week we finished the Multi SAP HANA VM and NUMA Node Sharing (CPU socket sharing) tests with vSphere 6. Due to the good results, SAP granted full production level support for multiple SAP HANA systems deployed on a single SAP HANA certified server virtualized with vSphere 6.

With this, customers can get now better TCO results by SAP HANA system consolidation and better utilizing their hardware assets.

For details please review SAP note 2315348 – SAP HANA on VMware vSphere 6 in production.

What is allowed by now with vSphere 6?

  • Consolidation of multiple SAP HANA production level VMs on a single SAP HANA certified server based on Intel Xeon E7-v3 (Haswell).
  • Possibility to share a NUMA node with two production level SAP HANA VMs. Example: 4 socket Haswell server is now able to support up to 8 SAP HANA VMs, and an 8 socket Haswell based server supports up to 16 SAP HANA VMs in production.
  • SAP HANA sizing rules must get applied and followed.
  • When sharing a NUMA node minimal 8 CPU cores (16 threads) must get assigned to the VMs, RAM must get assigned accordingly the latest SAP HANA sizing rules.
  • Enough network and storage IO capacity must be available for all running production SAP HANA VMs (SAP HANA TDI storage KPIs).
  • Enable VMware HA to protect the consolidated SAP HANA workload and ensure that enough failover capacity is available in the vSphere cluster.

What is not allowed as of today with vSphere 6?

  • No Intel E7-v4 (Broadwell) based system and vSphere 6.5 support. Validation and tests are ongoing but not finished.
  • Running more than two SAP HANA VMs on a single NUMA node (CPU socket)
  • Over-subscription of CPU and RAM resources