Oracle is not supported on VMWare

FALSE. Oracle does not cercify its products, specifically its database, on VMWare. Oracle will always give assistence on VMWare if it can be proved that the problem is not VMWare specific and the issue can be reproduced on bare metal servers.What this means is that Oracle could stop working on a SR it it considers there’s a related problem that should be scalated to VMWare support. My experience, after have worked on lots of SRs, has always been good, without any problem regarding VMWare, even when a issue ends in a new internal bug request being opened by Oracle. I have never been stopped by being working on VMWare. Yes indeed there’s a explicit mention to minimum version for RAC databases for SRs to be accepted on creation. This version is 11.2.0.2, and I have no experience regarding opening RAC issues for lower RAC databases on VMWare, so I can’t tell how strict Oracle is applying this rule. VMWare published this WhitePaper saying that until then, they had never received an issue related with Oracle databases where VSphere was the origin of the problem:

I must shutdown my VMs for hot-adding a virtual disk

FALSE. Adding new disk devices for ASM without disruption is possible. When we use a datastore for creating virtual disks, we are using VMFS filesystem. VMFS by default disables shared access to these devices by multiple virtual machines. ASM is aware it is working with clustered storage when using RAC, and it can manage access concurrency through multiple cluster nodes to the same disks. So ASM does not depend on OS or SCSI technologies to be able to coordinate it’s nodes when accessing shared storage. For such applications, VMWare can be configured for disabling this shared access limitation by means of activating the multi-writer flag in the virtual disks.

As consecuence of VMWare bug 2078540, multi-writer flag got disabled when a new disk was added to a running VM, so no new ASM disks could be hot-plugged. This issue was solved in ESXi 5.5 P02 build -1892794, so later versions do not have this restriction. In case of using an affected version, workaround is indeed shutting down the VMs before adding new disks, but this is the exception and not the rule.

I can’t make VM snapshots when using RAC

FALSE. We usually find customers suffering this issue associated to a misconfiguration at VMWare level. It’s true that multi-writer flag restricts the available features on virtual disks and virtual machines (like suspending a VM or hot adding virtual disks to new adapters). We can take a look to the available features at VMWare:

In my opinion (wich, as Radiohead would say, “is not of consecuences” 🙂 ), workinh with sysadmins, it can be confusing reading in this matrix that snapshots are not supported (even virtual backup solutions will not work!). This is strictly true but, from an Oracle Database point of view, what is interesting for us is that we really can make VM snapshot if we use independent-persistent disks. This is available since vSphere 5.1u2. It’s important taking in mind that as ASM disks are going to be independent-persistent, they are not going to be included in the snapshot (or in the virtual backup). This is something that we don’t care as we should be protecting our database backups using RMAN. Taking a look at Oracle Databases on VMware RAC Deployment Guide, we can see the recommended configuration for ASM storage:

  • Paravirtual SCSI controller apart from system controller for local disks.
  • Thick Provision Eager Zeroed. Disks will be created with their real full size and filled with zero values. This is slower than thin-provisioning, but it’s clearly a better choice.
  • Multi-Writer.
  • Independent if we use virtual VMFS disks (independent-persistent when using RDM).

We can take a look at a practical sample in some screenchots from the RAC on VMWare document:

Shared virtual disks for ASM connected to the paravirtual controllers. There are two controllers in the sample for the limits in maximum LUN devices attached to each of them.

 

ASM shared disks with multi-writer flag enabled.

 

Configuración independiente y con Thick Provision Eager Zeroed cuando creamos discos ASM sobre VMFS. En caso de emplear RDM, los discos deben ser Independent-Persistent

I can’t use Veeam Backup when using RAC on VMWare

FALSE since vSphere 5.1. The reason is the same as described in the previous paragraph. We only need to correctly configure virtual disks and controllers for system and ASM. Doing this we’ll be able to make snapshots (excluding ASM disks) and the virtual machine will be copied by Veeam Backup. This copy will only be valid for VM and OS restoration, but not for the database and should use RMAN for better protection.

All processors in the VMWare cluster must be licensed

QUESTIONABLE.Oracle sales representatives or even LMS will see this clear, and they will say all processors must be licensed even when no Oracle software is being run in them. VMWare published years ago a paper called Understanding Oracle Certification, Support and Licensing fuere VMware Environments where it argues the posibility of partially licensing a subcluster for Oracle products in a VMWare deployment by means of using DRS for MV reallocation and preserve a log with the VM movements to be able to justify CPU usage. This position was also confirmed by in 2012 by Richard Garsthagen Director Cloud Business Development for Oracle’s IaaS Portfolio.In January 2017 we found a new VMWare post with a stronger positioning regarding Oracle licensing in VMWare. This is a must-read post as it references Oracle’s license agreementsand explains why Oracle’s restrictions regarding soft and hard partitioning are not included in legal documents like OLSA or OMA. VMWare explains why DRS in combination with VMWare is enough for restricting the number of processod licensed for Oracle products.

Oracle considers VMWare as a soft-partitioning technology and does not accept CPU restrictions as the number of vCPUs asigned to the VMs. Technically this is because there’s no guarantee of physical execution restrictions in the different processors or even core procesos in the hardware platform. No VMWare technology or configuration is accepted by Oracle as it does for Oracle VM virtualization (considered as hard-partitioning).

So, what happens if I never move my VM in my VMWare cluster? There is no restriction in limit vMotion physical ESX placement for a VM or even not using it. Doing so, why must I license a hardware that is never goind to be used by Oracle?. The answer is just the possibility of doing it. Again, my opinion is that VMWare argue is more reasonable than Oracle’s arguments taking in mind common sense. The expression Galaxy Licensing that VMWare uses in its post is a good synthesis of this situation in our current technological world, as vMotion is not restricted to a single vCenter as Oracle limits in its licensing rules, soi why not licensing all the ESX servers in the world or even in our different sites?

Oracle VM is a valid option for restricting Oracle licenses

TRUE. Oracle defines OVM CPU pinning as hard partitioning technology. This measn that with a right configuration, only the cores where vCPUs are pinned and running must be licensed and not all the real physical CPUs.

Tehre’s even a restriction in this rule. With Standard Edition 2 hard partitioning is not accepted for hardware with more than 2 sockets, what sounds incoherent with soft/hard partitioing politics and creates a new caterogy between these two. So, we can use hard partitioning with OVM but only with small servers even when you are going to use the same computing resources. I don’t know why this criteria, but it looks like if your big enough for buying that hardware, you are big enough for licensing Enterprise Edition, even if you don’t really need it.