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:
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 184.108.40.206 and 220.127.116.11 deployments using OEDA. If you prefer to have GIMR configured, please open the file .
/properties/es.propertiesand change the property “ENABLEMGMTDBCONFIG” from
truebefore 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 18.104.22.168.0.170606 so if you run into this similar problem, the best thing is to contact Oracle support.
As always, questions, remarks? find me on twitter @vanpupi