The background of this situation comes from the Processor definition itself:
"Processor: shall be defined as all processors where the Oracle programs are installed and/or running. […]"
Oracle argues that with VMware, through ease of migration with vMotion, a VM can actually run on all processors of all the ESX hosts in a vCenter (or across vCenters for VMWare 6.0). Customers have argued that they either don’t have vMotion enabled, or that they have logs of where the VM’s are and have been running in the past. This was never enough to convince Oracle and their justification is simple: vMotion is so easy to turn on and off, that even if you can show that a specific VM was running on a specific ESX host or Cluster, this does not prevent you from changing it in the future. This is exactly the difference between hard and soft partitioning technologies in Oracle’s view.
So, to get back on the question, Host Affinity falls into the same category, where Oracle will say: “Fine, this is the affinity now, but how am I to know this will not change tomorrow”. This is why they do not accept Host Affinity Rules as a valid way to limit the numbers of processors for licensing purposes with VMware technologies.
With that said, based on our experience so far, there have been a number wins in the industry, with companies being able to negotiate custom rules that Oracle accepted as a way to limit the number of cores required to be licensed in case Oracle is deployed on VMware. However, this typically happened when there was already a significant amount of (cloud) money on the negotiation table and thus, Oracle accepted on their turn, custom language.