Exalogic 18.104.22.168.0 Virtual System doesn't work as expected after migrating a Control Stack VM to a different compute node
Last updated on JUNE 26, 2013
Applies to:Oracle Exalogic Elastic Cloud Software - Version 22.214.171.124.0 and later
Information in this document applies to any platform.
You have an Oracle Exalogic System deployed in a Virtual configuration running Exalogic Enterprise Cloud Software Release 126.96.36.199.0 (Gemini) where the vServers for the Exalogic Control Stack have not been distributed across the nodes that are expected (as shown in the following table):
|Exalogic Control Stack vServer||Expected Location|
|ExalogicControlDB||Compute Node 1|
|ExalogicControlOVMM||Compute Node 1|
|ExalogicControlOpsCenterPC1||Compute Node 3|
|ExalogicControlOpsCenterPC2||Compute Node 2|
|ExalogicControlOpsCenterEC1||Compute Node 4|
However, on Gemini (EECS 188.8.131.52.0) when you stop one of the vServers of the Exalogic Control Stack on one node to bring it up on the node it is expected to run on, one or more of the components encounter unexpected issues communicating with one another which can give rise to a variety of different symptoms.
For a vServer that is running on one of the components of the Exalogic Control Stack you have stopped the vServer running on one of the compute nodes in Server Pool 1 and restarted the vServer on a different compute node within the vStack, where it is expected to run to achieve the expected distribution across compute nodes.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms