Tuesday Dec 23, 2014

The vServers were migrated to another Compute Node... Oh My!

Recently I was working 2 similar SRs, both related to this behavior of Exalogic.

When for some reason a compute node is rebooted, the vServers running on it are automatically moved to other compute nodes. Why does this happen? This will occur if the HA flag is enabled on a vServer, which can verified by looking at vm.cfg file of that VM.

After the compute node that was rebooted is back up and running, you may probably want those migrated vServers to be located where they were before the outage (that is, on the previously failed compute node). Unfortunately, "Live Migration" or the ability to migrate running vServers is not yet supported in Exalogic. By design, migration is not exposed at the vDC level, a vDC cloud user does not care about where his vServer runs, it runs in the cloud. So, you need to use "Cold Migration" instead.

Basically, cold migration may be executed manually by admin with "root" privileges on OVS node:
- stop a vServer, it will be detached from OVS
- start a vServer on the OVS node you want your vServer to run, making sure you do not switch server pools

Wednesday Aug 21, 2013

Resource allocation on vServers

A few facts to keep in mind.

The number of vCPUs to existent vServer cannot be modified. Currently vDC resource management (changing vCPU, memory, etc.) after a vServer has been created is not supported in Exalogic Virtual environments. However, a customer vServer type with required memory can be created and used instead of the default VM types.

Note that the Server pool management is handled by Exalogic, manual management of it is not available. Also, keep in mind that there is no way to control which physical host is assigned a given vServer. The scheduler algorithms are sophisticated but it is fine-grained and there is no reason to assume that the scheduler will not be maximally efficient. EMOC will look at the resources allocated to the vServer that is being planned on creating (CPUs/memory), then look at what is available on each of the compute nodes and make a decision on where to place the vServer. System administrators can try to use Distribution groups and separate the vServers they have to run across different Oracle VM Servers.

If need to increase Root File System and Swap Space of an Exalogic Guest Virtual Machine, then the MOS Note 1575790.1 is useful for that purpose.
About


Principal Technical Support Engineer in the Engineered (Systems) Enterprise Support Team - EEST.
Former member of the Coherence and Java Technologies Support Teams.

Search

Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today