OEDA does more than you would expect

The title summaries this complete blogpost, the OEDA (oracle exadata deployment assistant) does a lot more than you would expect.
Therefor it is pretty important that you should use a recent version every time when fiddling around with virtual machines on the exadata.

A simple example I just discovered and did not know about. In my previous blogpost about the bond_eth issue (find it here: http://vanpupi.stepi.net/index.php/2017/06/09/exadata-ovm-creation-second-argument-is-not-defined-bondeth_mode/ ) you could read that there was a problem while I invoked domU maker manually to create a non-db / non-gi virtual machine. Oracle support did a great job and provided me another OEDA which I should use to create this domain, but stop at the first step, so only the domain is created. Why? And why shouldn’t I just invoke domU maker? But I’m pretty conscious if they ask me to do something, so I obeyed and did it their way and … hey it worked! But again … why?

Digging a little, just beneath the surface so really not difficult, I discovered that if you use a new version of OEDA, it also upgrades some of the rpm’s on the system. Until now I isolated already 3 important ones:

ovmwatch-1.0-168.el6.30.5.x86_64

ovm-consoled-0.1-20.el6.2.noarch

exadata-ovmutils-12.2.1.2.0.170606-1.noarch

Probably there will be more, but if you see that ovm utils is upgraded, this explains why it works. What I could not try, because of time limits, was to destroy the domain and invoke domumaker manually again to check if it now succeeds. Basically I think it will just work, but still needs confirmation. Anyone?

At the time of this writing, the june version has been released. They skipped may for some reason *confused*. One of the remarkable things in that readme is:

“Grid Infrastructure Management Repository (GIMR) will not be configured by default with 12.1.0.2 and 12.2.0.1 deployments using OEDA. If you prefer to have GIMR configured, please open the file ../<unzipped_location>/properties/es.properties and change the property “ENABLEMGMTDBCONFIG” from false to true before starting the deployment.”

I will keep this post short, but when we check the bug they created. That one is still not fixed. So yes I have received a very early OEDA version 12.2.1.2.0.170606 so if you run into this similar problem, the best thing is to contact Oracle support.