If you read our previous blog post about Oracle in VMware and the Mars case, you may be tempted to assume that running Oracle software in VMware is easy, risk free and straightforward. After all, there is a court case that supports this assumption. This assumption, however, is incorrect and fraught with risks. There are several important things to keep in mind as you navigate the licensing minefield of running Oracle software in VMware.
Firstly, the specifics vary. The details of the Mars case may not apply to you. Mars had a combination of VMware settings in place that clearly limited VMotion capabilities. While the court filings don’t dive into the technical details as to what settings/configurations were in place, Mars did declare the following in the court filings (for further details, refer to this document, pages 2-3):
“The VMware clusters are configured such that a virtual machine that is hosted in one VMware cluster cannot readily be moved to a different cluster… The ‘live migration’ feature cannot be used to move virtual machines from a VMware cluster running Oracle Enterprise Edition database software to a VMware cluster not running Oracle Enterprise Edition database software – and the ‘live migration’ feature cannot be used to to move a virtual machine between two VMware clusters that both run Oracle Enterprise Edition database software”
The filing goes on to state that moving VMs from cluster to cluster would be time consuming and would require taking multiple servers offline. Furthermore, per the filing, the clusters with Oracle software have dedicated storage.
These details make it very difficult for Oracle to argue its point. Any customer looking to deploy Oracle in VMware should ensure that the combinations of settings and configurations should yield a level of control and restrictions that at least match what Mars had in place.
Secondly, it appears that outside of the VMware issue, Mars had a license surplus – this could have made Oracle more desperate to hang on to whatever findings it could get its hands on. Perhaps if there were other significant compliance issues, Oracle may have been less aggressive with its VMware approach, preferring to focus elsewhere, and Mars may have been less likely to go to court.
Thirdly, and finally, if you do decide to run Oracle software in VMware, be prepared for an Oracle license audit! Just because Mars got its way does not mean Oracle has conceded and changed its VMware approach – there are plenty of naive customers out there. Also, just because you may be able to defend your VMware position in the event of an Oracle audit does not mean they will not find other compliance gaps like use of unlicensed Database Options/Packs or excessive number of Named Users.
In summary, you can run Oracle software in VMware with the correct configurations, and it will be defensible in an Oracle audit. But this will also enhance the likelihood of an audit from Oracle in the first place, and the audit could well uncover other compliance issues. It’s best to do a full internal audit of Oracle licensing to make sure you are audit-ready and running a tight ship.