Lesson learned: How to kill an Oracle Virtual Compute Appliance

If you’re having a rather dull afternoon at the office, and you happen to have an OVCA as your personal playground, you can always try this little trick to spice up your day: Point your browser to the Oracle VM Manager, look for the the network configuration tab and attempt to make the storage and heartbeat network available to virtual machines. I can virtually promise you that your day will be more interesting. Much more. Almost instantly.
ovca_network.png

Without spoiling all of the little surprises, I can disclose that you will have some enlightening moments watching the first compute node (typically ovcacn07r1) head for a rapid reboot, just as soon as the cluster watchdog sees that the OCFS2 voting drive is no longer responding. Granted, it may take a few moments for it to notice, but I can assure you that it’s worth waiting for. You see, it will leave behind an inconsistent Oracle VM Pool, which in turn will trigger dozens of interesting events.

If and when you manage to start any of the lost guest machines, the fun increases as you can watch the pool balancer continuously migrating machines from one compute node to the next. Personally I found this last bit absolutely fascinating. For an additional kick, try having an open ssh session to one such machine.

I will leave the rest for you to figure out. Tons of fun!

Now, if on the other hand, you have an OVCA running, say, a production workload, I strongly suggest you keep your VMs very much isolated from the 192.168.40.0 network.

Well, unless you are you are really, really, really bored and you, preferably, get paid by the hour.

This entry was posted in General, Oracle. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *