Oracle licensing for VMware

By Paul Bullen, Senior License Consultant, Rocela.

Recently, there has been renewed interest on VMware’s position regarding Oracle Certification, Support and Licensing.

This document lays out, amongst other popular Oracle-on-VMware topics, some logical and reasoned discussion about using DRS Host Affinity in order to limit Oracle license requirements within a VMware cluster. They suggest that limiting a VM to a particular physical host (or subset of hosts) within a cluster will reduce the license requirement and that only those physical servers require licensing for Oracle.

Understandably, this can have the potential to massively change your licensing requirements – the general stance has been that all physical nodes within a cluster, regardless of whether they are running a VM with Oracle on it, need to be licensed.

The VMware article is logical, interesting and its assertions are very positive, however it is worth remembering: this is a VMware paper. It is not underwritten by Oracle, and ultimately it is Oracle who decides how their products are to be licensed.

We work with clients using VMware and Oracle every day: we are unaware of any change of general stance from Oracle. Therefore, you should be fully aware of the potential licensing implications should Oracle audit your use of Oracle on VMware clusters.


Virtualisation – The Reality, not the hype. Final Part

By Tam Kyle, Senior License Consultant, Rocela

Before I launch into the thorny topic of Oracle licensing when virtualising, it’s probably worth reminding ourselves of what has been discussed beforehand … briefly!

So, Part I covered what virtualisation is and why companies are so keen to take advantage of it with Part II discussing the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

And so, to Part III – the impacts and considerations of Oracle licensing when virtualising. Where to start?

Cost saving or cost avoidance?
Let’s start with the obvious – money. What are you trying to achieve? Direct cost saving or cost avoidance? Do you actually know if it’s possible to reduce or avoid Oracle costs? If you have a fixed maintenance stream, then you are paying for what you have already bought irrespective of the actual amount of usage. Your support fees will not necessarily reduce in line with reduced usage – all you will have done is freed up licenses for use elsewhere in the business, all the while paying support for shelfware – but that might be beneficial to you as opposed to dropping the bottom line.

Your license contracts will determine whether and indeed how you can terminate licenses and it’s certainly not as easy as saying, “I’ve virtualised, therefore my footprint is smaller, so I’ll pay less.”

Smaller footprint
And whilst we are on that topic, are you sure that your footprint is smaller? In other words, have you considered whether your virtualisation technologies allow licensing in a sub-capacity context? In plain English, have you been able to establish whether you only need to license the bit of the box that you are using? As it turns out, this is not necessarily always the case. My fuller publication will walk you through a few scenarios with some surprising conclusions.

Server Clustering
One of the great benefits of some virtualisation technologies is the capability to join physical servers together (clustering). This allows for resilience and the seamless moving of virtual machines between hosts within the cluster. However the license terms underpinning this may prove prohibitive – for example, Oracle’s current stance on VMware is that you have to license all the boxes in the cluster because you are giving the VM’s the capability of roving. Many would argue that the VM is never in two places at once or that this virtualisation technology is ‘hard’ because it’s technically the same as Oracle’s, so why should they consider it ‘soft’ and force the entire cluster to be covered?

Have you considered that you may need to license your installation twice whilst you have parallel running during a migration to a virtualised infrastructure? Whilst this will most likely be a new and additional spend, it may not need to be licensed in the same way as your original setup.

Who said licensing was easy? In truth, there are many nuances around the various virtualisation/isolation/partitioning technologies in use – the breadth and licensing impact of these technologies isn’t easily understood and is frequently open to interpretation depending on the operational, business and contractual context.

The 3 Vital Treatments
Drawing this 3 part summary to a close, what we are saying – that virtualisation is an abstraction of hardware from operating systems and software. Organisations consider virtualisation to save money, provide operational flexibility and prepare for future technologies. Many organisations’ virtualisation projects run into trouble when they fall foul to unfixed requirements, underestimating the technical challenge, vendor support and lock-in and unintended licensing implications.

So, our 3 Vital Treatments, to keep in mind when embarking upon virtualisation projects are:
1. Get the requirements right – what is the purpose of the project? Have you consulted experts to see if you can save money and is it the optimal way to save money?
2. A tight business case – consider all elements. Understand the potential benefits and pitfalls of your virtualisation choices especially in license terms – how do you license your new virtualisation setup and how is it different from your existing license provision?
3. Control – understand migration needs and ensure you can operate your virtualisation setup ongoing, especially from a license perspective.

The full Virtualisation Publication will offer you much more detail and insight into this paradigm and is available to download from our website.

This concludes our series on Virtualisation – if you have any questions then please do not hesitate to email me on

Virtualisation – The Reality, not the Hype. Part II

by Tam Kyle, Senior License Consultant

It’s been a few weeks since we posted our last blog (Part I) which covered what Virtualisation is and why companies are so keen to take advantage of it. In this piece, we will discuss the sort of problems organisations encounter when virtualising and at a high level, how you can avoid these issues in the future.

Remember, at the end of this series, we will publish a fuller Virtualisation publication written by one of our Senior License Consultants, Tam Kyle – this will offer you much more detail and insight into this paradigm , how to side step the common pitfalls, its impact on licensing and the ‘3 Vital Treatments’ for Virtualisation ROI.

So, why do organisations get themselves into hot water when it comes to virtualising their environment? From our Roundtable discussion hosted in November last year, and our day to day working with large enterprise organisations, we have obtained an insight into some of the most common areas that companies fall foul of when virtualising.

• Scope creep – Part of the problem with virtualisation is that when you actually get something delivered, it’s good – people want more and they want it now. Don’t be distracted by the potential of success – by all means entertain change to your scope, but do it formally.

• Understand your needs and objectives – there are many physical implementations of virtualisation technology, but they’re not all alike; advanced implementations will bring advanced benefits, but require advanced technology. Have you considered the potential financial impact in your business case?

• Vendor Support – does the Vendor support your applications on a virtualised stack?

• Migration – Many organisations underestimate the work involved in migration. Get it wrong and you’ve got a broken application as well as a set of disgruntled users.

• License implications of migration – Checking whether your vendor is going to require you to double up licenses for the duration of the migration is important or you may unwittingly fall foul of their licensing rules potentially incurring unbudgeted expense for license non compliance

• Vendor lock-in – Your application is running on virtualised platforms and infrastructure in such an abstract manner that you don’t even know where your data is anymore. For some organisations, particularly those with sensitive data, this might not be ideal. Also, what happens if you need to change vendor?

• Ongoing control – Virtualisation isn’t a silver bullet – you don’t just walk away when it’s done. You’ve actually added a layer to your setup, so who manages the virtualisation part ongoing?

Avoiding the common issues of Virtualisation

Obviously I could go on for some time on how to avoid these common issues – for the purposes of this post, I have kept this deliberately brief. Remember that there will be a fuller publication available for down loading from our website after we have posted Part III (probably in a week’s time).

Our approach would be to understand your requirements thoroughly – document these and obtain appropriate sign off. Make sure that your business case has senior sponsorship and similar sign-off. Accommodate changes, but do it within a formal change request process.

Match your needs to a product set, or more rightly, product sets. Don’t necessarily force yourself towards one vendor – you might need to swap at some point.

Understand the footprint you are attempting to virtualise and remember, it’s unlikely that you’ll achieve 100% virtualisation. Manage expectations accordingly.

Consider the fact that there are some applications that just do not sit well with virtualisation; some are too big, have special vendor configurations and are tightly bound to hardware layers. There are other applications that you would not migrate for non-technical reasons such as company culture, 3rd party vendors and internal governance for example.

In our final blog post, we’ll look at the thorny issue of licensing impacts, with particular focus on Oracle.

Subscribe if you want to be notified of its publication.

Virtualisation – The Reality, not the hype. Part I

Tam Kyle, Senior License Consultant

So, just to remind everyone, Rocela will be posting a series of short blogs based on a Virtualisation Roundtable discussion that we hosted in November last year. This topic proved to be particularly relevant with many of our clients so much so that we thought we’d share the experience with you.

Remember, at the end of this series, we will publish a fuller Virtualisation publication written by one of our Senior License Consultants, Tam Kyle – this will offer you much more detail and insight into this paradigm, how to side step the common pitfalls, its impact on licensing and the ‘3 Vital Treatments’ for Virtualisation ROI.

As we said in our introduction post earlier this week, this piece will concentrate on (at a very high level) what Virtualisation is and why companies are so keen to take advantage of it.

So, what are we talking about when we discuss Virtualisation? The concept of Virtualisation is not a new one – IBM was one of the first to produce a type of Virtualisation years ago however this was restricted to its large expensive mainframe platforms.

Today, when you look at standard server based virtualisation technologies, what we are referring to (in very simplistic terms) is an abstraction of the hardware interface from the operating system – allowing you to visualise your Operating System (OS) as not being ‘hard wired’ to your hardware – i.e. decoupling your operating system and everything that runs on it from the physical tin. That being said, Virtualisation is no longer restricted to servers – you can virtualise storage, desktops, applications and so on. Gartner predicts that by 2018, the percentage of x86-architecture workloads running in VM’s will be a massive 86%.

In general, there are 3 main kinds of virtualisation:

• OS virtualisation
• Type 2 Hypervisors
• Type 1 Hypervisors

The type you chose/use depends on many factors – cost, functional or operational requirement, strategic vision, resource constraints, current issues and so on.

In general, the differences surround how a particular Virtualisation technology is implemented, and what it’s operational and functional capabilities and constraints are. For example, all OS Virtualisation ‘instances’ need to be of the same type, whereas Type 1 hypervisor ‘instances’ can usually run many different operating systems – you could have a Windows server running in a VM (virtual machine), alongside a Linux server in another VM. This provides more flexibility but requires typically more effort to provision, operate and support.

Let’s have a quick look at why Virtualisation is so popular with businesses today. Well, the answer is simple – time and money.

It’s a well known fact that the sheer complexity of datacentre technology and manpower required can impede an organisations ability to make change happen quickly which could affect their competitive edge in the market place. Furthermore, the ever increasing costs of power, square footage, hardware, software and internal resources means those organisations will be paying more and more to keep their IT lights on.

Virtualisation can help to solve both these problems – put simplistically, by decreasing the amount of physical hardware and space required to do the same (or a much better job), you decrease the amount of power, footfall and manpower and in turn, reduce cost. You are paying much less for more.

Virtualising also allows for much quicker and simpler provisioning – whether it’s resolving a failing server, running maintenance patching or accommodating new applications. It’s the dream scenario every IT or Datacentre Manager dreams of – efficient, resilient with minimal ‘hands on’ management.

You might be saying to yourself ‘I know all this’, however from our experience in helping clients resolve Oracle licensing issues, what is less understood is why many Virtualisation projects go wrong, particularly when it comes to license compliance. In our next blog post, we’ll take a look at some of the common issues including the impact on licensing.

Subscribe if you want to be notified of its publication.

%d bloggers like this: