We evaluated using Oracle VirtualBox, but it was more for desktop virtualization and did not fit with server virtualization. We also tried KVM, but the complexities in migration from one host to another deterred us, and the management was not as seamless for multiple hypervisors.

Given Oracle VM's favorable licensing policy allowing hard partitioning using virtualization, we found this to the the most optimal method to recommend to clients.

There are compelling reasons why one might prefer Oracle Linux to Red Hat Linux. Some of the major factors are:

1. One throat to choke. It is very useful to have one vendor on the pointy end of the stick. No finger pointing, and all buck passing is internal. Also, given the dev team is often using the same OS flavor, it can be a benefit in the first place. 
2. Optimised for databases. Many of the options: RPMs and settings which are best used to run a database are packaged into a single RPM that can be automatically deployed on Oracle Linux, but must be painfully and manually setup on RHEL. 
3. Ksplice: The ability to patch all aspects of a running Linux system, including the kernel with zero downtime is something that no other Linux provides. The UEK is enough of a differentiator to get the nod.

We evaluated other solutions but they were all expensive.

I have evaluated several options such as Proxmox, Red Hat, and Overt. They all do the same things but in different ways. They all have similar feature sets. The interfaces have their own quirks. All of the options are fairly equal with some differences.

We looked into KVm and Vmware however these options did not give us benefiits of hard partitioning and there were issues with certification and compatibility with oracle cots products.

We currently are in the decision-making process of whether we're going to remain with Oracle or whether we're going to look at a different ERP.

I looked into vSphere and Hyper-V, and then decided that we could not go with any other non-Oracle virtual technology. It had to be Oracle VM, so that's one thing I wanted to make sure was that we had Oracle VM as a new server, otherwise Hyperion is not going to be supported on non-Oracle virtual servers.

For us, the biggest thing I think is the compatibility with all the other Oracle products. We have ERP and EPM and all these reporting tools like BI. The most important factor for us is when you talk about the compatibility of all these different products, it has to have compatibility with dependent operating systems, the servers, the database, Internet Explorer browsers, Java, and all those different tools that are integrated in our system.

If we go with any other virtual servers or virtual products, let's say VMware, it is compatible but it's not 100% guaranteed that we'll be supported by Oracle support. Let's say in the future if we have a problem, Oracle support might say we are not able to support because you are using third-party tools. That's the most important factor and advantage over other tools in the market available when we choose to go with Oracle.

We just did the upgrade of our Oracle Hyperion, so one thing I learned is we could not go with any other tool because we have all these Oracle products integrated tightly and we cannot just install them on some other non-Oracle products. I think we are also talking about to move from physical to virtual for one of our Essbase databases. Right now it's on Essbase, which is under Hyperion, on a physical server, so again, just to take advantage of the cost and the recovery and the disaster recovery and all those benefits that virtual machine has to offer.

Oracle VM was recommended by the top management, and we deployed just that. This didn’t give us much chance to evaluate other options.

as mentioned earlier we used physical env as well as vmware & hyper-v. we are still using the same for other applications. But for oracle products we choose oracle vm server.

I was able to evaluate Oracle Solaris Virtualization that only runs on SPARC servers, and only runs on Oracle Solaris.

We considered the following below:

1. The physical memory supported by Oracle VM is higher

2. No of vCPU supported on guest(VM) is higher 

3. Product is free and this is the best part 

Yes, but non could beat Oracle VM's price!

We evaluated VMware, Citrix, Hyper-V, and RHEV. The main feature was the "Oracle License Compliant" and after the wide library of images. The stability and efficiency of the hypervisor was always great therefore the previous mentioned factors comes to decide.

Oracle is the only vendor that sells this. That is all there is to choose. Oracle are the only ones who can provide it.

We selected VMware and KVM.

We looked at quite a few vendors and we support different vendors as well, too. We're not a one-vendor shop. We use quite different vendors and it's all-purpose for us. For Oracle-based technology, we use Oracle VM. For non-Oracle stuff, we use VMware.

I'm sure there is one product, Oracle Data Integrator for loading bulk data from one system to another. We just starting using it. It’s a very good product, but we haven’t used all the features. Once we explored all the features, we got feedback from the company. I know so far that it’s good.

Insert linkThere were no other vendors on the shortlist, because we're an Oracle shop.
Nonetheless, when I do think about working with a vendor like Oracle, I look for depth of knowledge, reliability and whether they have a pretty good clientele out there. It's always good to compare notes or see what other people are doing out there and help one another.

We didn't really evaluate other products because we already run a lot of other Oracle solutions. Obviously, Oracle VM is supported by Oracle, which makes things easier than if we had used, for example, vSphere or Hyper-V.

I was not involved in the procurement phase.

Oracle VM was chosen mostly due to licensing issues and it is based on the stable KVM product of Red Hat.

Another one of the jobs that I do is assist my clients with migration to Oracle VM. For example, some migrate from VM to Oracle VM, and others migrate from Hyper-V to Oracle VM.

As it's Oracle, there was no need to evaluate anything else.