Oracle VM Reviews

Oracle database licensing rules make licensing on VMware cost prohibitive. Instead Oracle prefers that you use their "enterprise" virtualization product, Oracle VM. Avoid it at all costs. Threaten to migrate to MS SQL... just don't use this thing.

Pros:

• Free
• Relatively inexpensive support

Cons:

• Poor and buggy Windows client support. PVM network drivers have a serious performance bug that has not been resolved in more than a year (and three versions updates!). Luckily, there is a workaround where you can disable some features of the virtual NIC to get it working.
• "High Availability" in the OVM world means that if you shutdown a VM from within the OS, OVM automatically restarts it. If you want to actually shut down a VM you have to disable high availability, in which case you lose the ability to automatically migrate a VM if a host fails. It also means that you need to give your server admins access to the OVM Manager. For example, our DBAs can admin their Oracle servers... people who wouldn't normally have access to that level of enterprise management.
• It took three weeks and a set of consultants who knew little more than us to get storage and network working properly in a fault-tolerant manner.
• Non-existent best practices and no real community of support. Some Googling will find you the occasional blog or commercial site with tips and tricks, but they are few and far between.
• Poor management interface. In order to see the status of an individual VM you have to drill down to the correct host. There is no way to see the status of all VMs on all hosts.
• P2V is a multi-step process. Boot the server from a CD to turn it into a web server. Import web server into an OVM template. Create VM from template. Delete template. Essentially you need double the storage to get through the process.
• Minimal troubleshooting or diagnostic information without diving into the Linux OS.
• Training (virtual classroom only) was sub-standard and inconsistent. One member of our team was taught only to use the command line and was never shown the GUI. I was taught the GUI and some command line. And if you mention VMware in order to clarify concepts, prepare to get your head bitten off.
• Migrating VMs to different storage is an adaptation of the process for deploying from a template. Some inputs are ignored, and yet you are prompted for them anyway.
• You need an Oracle database to run the OVM Manager, which you install on the OVM Manager. So a key part of the infrastructure is a single point of failure.
• The SAN disk for the server pool is a single point of failure.
• If the OVM Manager goes down there is no way to manage the individual OVM hosts short of the Linux command line. The database (even when using Oracle Enterprise instead of the included Oracle XE) is prone to corruption, leaving you dead in the water. This has already happened to us once and the only solution from Oracle was to rebuild. Apparently this corruption is rather common. I know of other installations at my employer that have run into this corruption three times in the past nine months, requiring a rebuild each time. I do not feel that I can trust this product for a mission-critical production environment.
• Oracle is aware of these corruption issues but does not know the source and has no fix. They have reduced the incidence of corruption in version 3.2.3, but it is not a question of if corruption will occur, but when. The difficult thing is that the OVM manager will appear to run fine with this corruption.... until you restart the OVM manager, at which point it fails.
• The whole networking / storage / repository / configuration setup is needlessly complicated. I know this is an Oracle flavor of XEN, but... Citrix based their virtualization product on XEN and it isn't nearly as painful. Maybe Oracle should buy Citrix so they can drop OVM.
• Configuring storage that does not support their management plugins (entry-level EMC products) is an exercise in trial and error.
• If you already have another VM environment (VMware, Hyper-V) you are essentially setting up a parallel VM environment to manage.
• Cloning a VM (or cloning from a template) duplicates *everything* so be sure you don't have any ISO images attached, as they will be duplicated as well, chewing up storage.
• When you clone a VM the new files use the same name as the old with a number after it. If you don't think to rename them you will end up with a lot of files named "Windows 2008 Template (1)" "Windows 2008 Template (2)" and so on. The properties of the file will tell you to which VM it is linked, but (trust me) renaming them will save you a LOT of confusion. Things like this VMware just handles for you under the covers.

In summary: Do not use Oracle VM. If you must run Xen there are much better and manageable implementations (Citrix XenServer). If any reviewer has given Oracle VM more than two stars I seriously question whether they really have hands-on experience with the product (or have experience with a real virtualization product as a basis of comparison).

Update: After talking with other enterprises we are dropping OVM and setting up a separate VMware cluster in order to meet Oracle licensing requirements. While we will incur the expense of VMware licenses it is well worth it.

The licensing argument you will hear from Oracle regarding VMware is a scare tactic. You CAN run Oracle on VMware without breaking the bank on Oracle licensing if you plan carefully. VMware also guarantees that they will work directly with Oracle on your behalf to resolve any issues that may be linked to running on VMware.

Further update: When we gave up on Oracle VM about 9 months ago the central office tried to stick with it due to the Oracle DB licensing issues. Last week they got fed up and ordered the hardware to create a new VMware cluster dedicated to Oracle instead.

Another update: While I have not used Oracle VM since I posted this review, it is interesting to note that they have not released a new version since 2014. The latest version 3.3, did not fix any of the issues I don't think they are really serious about advancing or enhancing this product.

This is a very simple post to show the results of some recent testing that Tom and I ran using Oracle SLOB on Violin to determine the impact of using virtualization. But before we get to that, I am duty bound to write a paragraph of text featuring lots of long sentences peppered with industry buzz words. Forgive me, it’s just the way I’m wired.

It is increasingly common these days to find database environments running in virtual machines – even large, business critical ones. The driver is the trend to commoditize I.T. services and build consolidated, private-cloud style solutions in order to control operational expense and increase agility (not to mention reduce exposure to Oracle licenses). But, as I’ve said in previous posts, the catalyst has been the unblocking of I/O as legacy disk systems are replaced by flash memory. In the past, virtual environments caused a kind of I/O blender effect whereby I/O calls become increasingly randomized – and this sucked for the performance of disk drives. Flash memory arrays on the other hand can deliver random I/O all day long because… well, if you don’t know the reasons by now can I just recommend starting at the beginning. The outcome is that many large and medium-sized organisations are now building database-as-a-service platforms with Oracle databases (other database products are available) running in virtual machines. It’s happening right now.

Phew. Anyway, that last paragraph was just a wordy way of telling you that I’m often seeing Oracle running in virtual machines on top of hypervisors. But how much of a performance impact do those hypervisors have? Step this way to find out.

The Contenders

When it comes to running Oracle on a hypervisor using Intel x86 hardware (for that is what I have available), I only know of three real contenders:

• VMware vSphere (ESX)
• Oracle VM Server for x86
• Microsoft Hyper-V

Hyper-V has been an option for a couple of years now, but I’ll be honest – I have neither the time nor the inclination to test it today. It’s not that I don’t rate it as a product, it’s just that I’ve never used it before and don’t have enough time to learn something new right now. Maybe someday I’ll come back and add it to the mix.

In the meantime, it’s the big showdown: VMware versus Oracle VM. Not that Oracle VM is really in the same league as VMware in terms of market share… but you know, I’m trying to make this sound exciting.

The Test

This is going to be an Oracle SLOB sustained throughput test. In other words, I’m going to build an Oracle database and then shovel a massive amount of I/O through it (you can read all about SLOB here and here). SLOB will be configured to run with 25% of statements being UPDATEs (the remainder are SELECTs) and will run for 8 hours straight. What we want to see is a) which hypervisor configuration allows the greatest I/O bandwidth, and b) which hypervisor configuration exhibits the most predictable performance.

This is the configuration. First the hardware: 

Violin Memory 6616 flash Memory Array

This is the configuration. First the hardware

• 1x Dell PowerEdge R720 server
• 2x Intel Xeon CPU E5-2690 v2 10-core @ 3.00GHz [so that’s 2 sockets, 20 cores, 40 threads for this server]
• 128GB DRAM
• 1x Violin Memory 6616 (SLC) flash memory array [the one that did this]
• 8GB fibre-channel

And the software:

• Hypervisor: VMware ESXi 5.5.1
• Hypervisor: Oracle VM for x86 3.3.1
• VM: Oracle Linux 6 Update 5 (with the Unbreakable Enterprise v3 Kernel 3.6.18)
• Oracle Grid Infrastructure 11.2.0.4 (for Automatic Storage Management)
• Oracle Database Enterprise Edition 11.2.0.4

Each VM is configured with 20 vCPUs and is using Linux Device Mapper Multipath and Oracle ASMLib. ASM is configured to use one single +DATA disgroup comprising 8 ASM disks (LUNs from Violin) with external redundancy. The database parameters and SLOB settings are all listed on the SLOB sustained throughput test page.

Results: Bare Metal (Baseline)

First let’s see what happens when we don’t use a hypervisor at all and just run OL6.5 on bare metal:

Ok so we’re looking at 1519 MB/sec of read throughput and 320 MB/sec of write throughput. Crucially, the lines are nice and consistent – with very little deviation from the mean. By dividing the amount of time spent waiting on db file sequential read(i.e. random physical reads) with the number of waits, we can calculate that the average latency for random reads was 438 microseconds.

Results: VMware vSphere

VMware is configured to use Raw Device Mapping (RDM) which essentially gives the benefits of raw devices… read here for more details on that. Here are the test results:

Average read throughput for this test was 1133 MB/sec and write throughput averaged at 237 MB/sec. Average read latency was 596 microseconds. That’s an increase of 36%.

In comparison to the bare metal test, we see that total bandwidth dropped by around 25%. That might seem like a lot but remember, we are absolutely hammering this system. A real database is unlikely to ever create this level of sustained I/O. In my role at Violin I’ve been privileged to work on some of the busiest databases in Europe – nothing is ever this crazy (although a few do come close).

Results: Oracle VM

Oracle VM is based on the Xen hypervisor and therefore uses Xen virtual disks to present block devices. For this test I downloaded the Oracle Linux 6 Update 5 template from Oracle’s eDelivery site. You can see more about the way this VM was configured here. Here are the test results:

This time we see average read bandwidth of 1052MB/sec and average write bandwidth of 222MB/sec, with the average read latency at 607 microseconds, which is 39% higher than the baseline test.

Meanwhile, total bandwidth dropped by 31%. That’s slightly worse than VMware, but what’s really interesting is the deviation. Look at how ragged the lines are on the OVM test! There is a much higher degree of variance exhibited here than on the VMware test.

Conclusion

This is only one test so I’m not claiming it’s conclusive. VMware does appear to deliver slightly better performance than OVM in my tests, but it’s not a huge difference. However, I am very much concerned by the variance of the OVM test in comparison to VMware. Look, for example, at the wait event histograms for db file sequential read:

Wait Event Histogram
-> Units for Total Waits column: K is 1000, M is 1000000, G is 1000000000
-> % of Waits: value of .0 indicates value was <.05%; value of null is truly 0
-> % of Waits: column heading of <=1s is truly <1024ms, >1s is truly >=1024ms
-> Ordered by Event (idle events last)

% of Waits

The OVM tests show occasional results in the two highest buckets, meaning once or twice there were waits in excess of 1 second! However, to be fair, OVM also had more millisecond waits than VMware.

Anyway, for now – and for this setup at least – I’m sticking with VMware. You should of course test your own workloads before choosing which hypervisor works for you…

Thanks as always to Kevin for bringing Oracle SLOB to the community.

Valuable Features:

Room for Improvement:

Valuable Features:

Room for Improvement:

Other Advice: