This content has been marked as final. Show 6 replies
I'm sorry if my answer is obvious or not helpful, but if I have correctly understood your problem you basically need to enable HighAvailability on production VMs, this means that in case of server failure these VMs will be automatically restarted on another VM server.
For Virtual Machines that are NOT in production you could just disable HA so in case of server failure they will not be started automatically.
Hope this could help.
I'd like to push it a bit further (and that's actually my question). I'm fine with the production VM to be restarted by the HA feature. What I would like to get is "some of the development VM to be STOPPED automatically in the event we loose a server. This is to make sure those production VM that should fail over can be actually be restarted, even if the development server is over provisioned".
This would allow us (1) to provision one server for dev AND (2) rely on the HA feature, not only to failover the VM but also to reclaim memory/cpu of the dev server, in this case. If it doesn't exist, could we hook a script in the HA process somehow ? Or maybe, the anti-affinity groups could somehow be useful. Any idea ?
You could script this with the OVM_UTILs package.
Check every 5 minutes ( or faster ), if there is a server down.
If it is
- Stop the dev vms
- Check if Production vm's that have HA were not able to failover
- If there were
- else nothing
ovm_utils is very powerfull ( search for it on metalink ).
I wish it could really be out-of-the-box or at least hooked into the failover process. Any other idea if its somehow feasible and supported other than by polling VM state ?
As far as I know, there is no way in the current version to have the ovm behave as you described. I hope it's in the roadmap. Hopefully we'll know more after openworld ;)
Your scenario is very specific to your use case, so finding a supported out-of-box solution isn't going to happen. This is why the brains at oracle created ovm_utils, so it allows you to make your own processes.
Most shops would size their environment accordingly, so there's enough capacity to absorb a HA event, and completely avoid the "HA shuffle" procedure. Obviously that's the right way to do it, but can be more costly.