Oracle VM hard partitioning – potential licensing and performance issues

Oracle VM for x86 can be a very lucrative proposal for a company who is either trying to keep Oracle licensing costs down or trying to get out from under an Oracle licensing audit (shudder). However understanding how Oracle licensing works can be like peeling back the layers of an onion. We’ll take a swipe at some of the outer layers in today’s discussion.

It’s safe to say that Oracle licensing is not very VMware friendly. You are generally required to license every core of every server in the cluster. This means not only licensing all the cores on the server you are running the VM (Virtual Machine) on, but all the cores on any server that the VM could potentially be migrated to (think vMotion).

With Oracle VM for x86, you only need to license the cores you require as long as you use their hard partitioning technology to isolate the VM to specific cores. Given an example scenario of a single socket 8 core Intel Xeon based server, I’ll talk a little about some performance caveats you need to be aware of when implementing hard partitioning.

Let’s say you own 1 processor license for Oracle Database Enterprise Edition, and you are running it on a single socket 8 core server which is running Oracle VM for x86.  Based on my personal understanding and experience with deploying oracle database on OVM for numerous customers, you would be in compliance as is- assuming you implement hard partitioning. The core multiplier for Intel Xeon chips is .5 and you own 1 processor license. This equals out to 2 cores. If you have more cores available on the server than what you’re using, then you can implement hard partitioning in Oracle VM for x86. This restricts your database VM to specific vCPUs (Virtual CPUs) and does not allow it to go outside of those limits even though more cores are technically available for use. You need to be wary of two things though:


NOTE: In the diagrams below, I’m assuming Intel’s HyperThreading technology is being used.  This creates two “threads” per core that each appear as a vCPU to Oracle VM for x86.  Explaining how Intel HyperThreading works is beyond the scope of this document, however suffice it to say that for every core, you get 2 vCPUs.


1) you should choose vCPUs that align on core boundaries as much as possible when you configure the partition. In other words, don’t pick vCPU0,2,4 and 6 from cores 0,1,2 and 3 respectively and think you’re only using 2 cores. Even though that may represent 2 cores worth of processing power, to Oracle it is considered to be 4 cores and they will expect you to be licensed as such!  Here’s the wrong way to do it:


assign cores to db VM wrong

Below would be the correct way to pin your vCPUs to stay within core boundaries more effectively:


assign cores to db VM correct

2) just because you “pin” a given VM to a set of vCPUs, that’s no guarantee that other VM’s can’t use those very same vCPUs too! Given a pinned VM and other non pinned VMs, the non pinned VMs could potentially stray onto the pinned VM’s vCPUs and cause unintended performance issues. To avoid this, pin your database vm to it’s vCPUs and then pin all other VM’s to the remaining vCPUs to keep them separate. You may still need to adjust this approach based on how many VM’s you are running.  Here is the wrong way to do it:

assign cores performance issues wrong


And here is a better way to do it:

assign cores performance issues correct



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s