VMWare – VMotion Best Practices for Oracle Instances

I would like to list the best practices, i came across Oracle articles and VMWare white papers.

  • All ESX server host hardware, in particular the CPU, must be compatible
  • All virtual switches must be configured the same way for all participating ESX server hosts
  • Use a separate non-routable subnet for all Vmotion traffic or dedicated NICs for service console and Vmotion
  • Run a private Gigabit Ethernet migration network between all Vmotion enabled managed hosts
  • Incase a LUN has to be shared between multiple VMs, set “DisallowSnapshotLUN” value to 0 in virtual center
  • There needs to be free memory greater than the VM NVRAM file size
  • Make sure that Vmotion has unique IP and there aren’t duplicate Vmotion IPs
  • Make sure that Vmotion vmkernel portgroup is on its own vswitch and has a unique VLAN ID if VLANs are being used
    • VMware Network Documents also state that Vmotion and iSCSI vmkernel interfaces need to be on isolated networks vmkernel PGs in separate vswitches, and on separate networks or VLANs
  • Make sure that Vmotion is NOT enabled on any other portgroups other than vmkernel interface intended for Vmotion
  • Check time settings, enable NTP for the ESX/ESXi Servers in the clusters
  • VMware suggests where possible to not route Vmotion traffic to limit the number of hops that Vmotion has to take, and only one vmkernel interface is permitted per vswitch
    • Every hop that Vmotion traverses adds to Vmotion latency. This is not always possible but it is a VMware suggestion
  • Follow the troubleshooting guidelines from ref. notes below:
    • Troubleshooting Vmotion Failures and Vmotion Configuration Best Practices (Doc ID 1518833.1)

SHA2 certificates with EBS 12.1.3

 

Outbound Encryption involves connections from Oracle E-Business Suite to external site(s). For outbound connections, the SHA (can be SHA-1 or SHA-2) signed PKI certificate is requested from a CA by a site you are connecting to from Oracle E-Business Suite is certified.
For this case, Oracle E-Business Suite is acting as an HTTPS client. You must trust the root CA of the remote server’s certificate chain in your truststore. Example include, but are not limited to the following:

  • Punchout in iProcurement.
  • XML Gateway connection to a partner applications.
  • Payments credit card processing.
  • Dunn & Bradstreet (HZ).
  • International Trade Management (ITM) for screening orders and deliveries.
  • CIS Tax Module

Outbound encryption for iProcurement and XML gateway to use SSLv3 with TLS / SHA2 certificates:

  • Release 12.1: Apply Patch 19835592:R12.ICX.B “Fix for Bug 19835592“
    If the supplier punchout site supports both SSLv3 and TLS, or TLS only, then it will work after applying the patch.

    • Any punchout suppliers who are only using SSLv3 will need to migrate to (or add) TLS protocol. The SSL protocol (v2 or v3) is no longer supported for use with Oracle iProcurement. Supplier sites will need to use TLS protocol
    • The fix also supports any TLS v1 version (TLS v1.0, v1.1 and v1.2)
  • For XML gateway
    • Follow the instructions in the patch README and apply the following patch: 19909850

SHA-2 signed PKI certificates are now certified for inbound connections to the Oracle HTTP Server (OHS) delivered with Oracle E-Business Suite 12.1.3

You must apply the minimum requirements when using SHA-2 signed PKI certificates. Minimum requirements include the following:

  • Upgrade FMW 10.1.3 to 10.1.3.5
  • Apply at least the October 2015 CPU to FMW 10.1.3.5
  • Follow instructions from below document for requesting SSL certificates, and loading into Oracle Wallet:
    • Enabling SSL or TLS in Oracle E-Business Suite Release 12 (Doc ID 376700.1)