How to resize Memory and CPU of Exadata Virtual Machines

The OEDA tool used to create Virtual Machines on Exadata will limit your VM type
selection to a set template. As such the VMs that come up will carry a fixed amount of cpu and memory as per the template selected.

Sometimes to match the license requirement or performance requirement you may need to
increase or decrease the CPU core count. The licensing cost is based on CPU cores.
The rule of thumb is that 1 Core = 2 VCPUs


## Find the name of the VM whose memory or VCPU you need to modify ##

Remember - 1 core = 2vcpu

[root@tdbadm02 cellos]# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 16384     4     r----- 324182.0
tadm02vm01           1 65536     6     -b---- 160676.0
tadm02vm02           2 16384     2     -b---- 189596.6



## GOTO THE VM CONFIGURATION FILE OF VM02 ##

cd /EXAVMIMAGES/GuestImages/tadm02vm02/vm.cfg

#### contents of vm.cfg ####

memory = '16384'
maxmem = '16384'
OVM_simple_name = 'Exadata VM'
name = 'tadm02vm02'
OVM_os_type = 'Oracle Linux 6'
vcpus = 2
maxvcpus = 2
uuid = '499c4f55c33242e9b71318e4457f46b76'
on_crash = 'restart'
on_reboot = 'restart'

Modify the memory and vcpus count as required and save the vm.cfg file


## Now to restart the VM ##

a. Make sure you shut down the databases riding in it first.

b. from root # xm shutdown -w tadm02vm02
 (This will stop the VM and prompt will be returned once operation is over)

c. from root # xm create /EXAVMIMAGES/GuestImages/tadm02vm02/vm.cfg
   (This will start the VM. Here create=start)

d. login to VM and ensure db and other services are up.

India's First Exadata - Oracle Virtual Environment Setup.

After a long hiatus finally found something exciting to crib about. Just completed India's first Exadata Oracle Virtual Environment (OVM) setup.

It's a departure from the traditional Exadata Setup where you directly utilized the entire capacity of the two (or more) compute nodes and created RAC databases on it.

With this new setup here is a list of new possibilities and the basic architecture.

More stuff coming up shortly........

1. something called as DOM 0 or domain zero virtual machines comes up on BOTH the compute nodes of Exadata when you first configure the RACK.

2. Hence forth you will always login to the IP assigned to DOM 0 on node 1 and node 2 to carry out all future setups.

3. DOM 0 is the mother or controller of all user defined virtual machines that will come up on the compute nodes.

4. It is using the XEN Hypervisor virtualization engine.

5. Currently if you want to configure virtual machines. OEDA i.e. ORACLE EXADATA DEPLOYMENT ASSISTANT is the only tool. You configure your entire setup i.e. assigning IP address defining cluster names, diskgroup names and size etc in this tool. FTP the generated files on
/EXAVMIMAGES/linux-x86/ folder on dom 0 of compute node 1 and run ./install.sh -cf setup.xml -s 3

6. You fire up the step 3 of install.sh for any further vm creation.

7. Multiple IP segments can be created . i.e you can have one VM running ip segment 172.16. and other vm running 172.18.....

8. All VMs in a cluster should be under the same IP segment.

9. VLAN tagging is required at customer data center switch level to allow multiple IP segment.

10. Gateway of IP segment to be created must be pingable from the defined IP addresses. If your customer uses firewall at data center switch, ensure that he allows ping to gateway IP from the configured IP addresses.

BASIC ARCHITECTURE

How to force configuration changes in Weblogic

At a recent client deployment. I faced the issue that the datasource properties were not getting configured from the Weblogic Admin Console.

Symptoms - 
Activate changes button click hangs in-definately.
JDBC_datasource.xml file on node 2 of weblogic cluster is zero bytes.
Weblogic Version 10.3.6

The downtime was limited and there was no scope of troubleshooting the console.

This is what you do in the above scenario and force the changes from the background instead of the console.

Solution -

1. Shut down the admin server. Make sure you don't have any applications running in the admin server.

2. Backup or tar the config directory in the domain_home

3. Go inside the DOMAIN_HOME/pending folder. There you can see the config.xml and other changed configuration files like JDBC and JMS config files.
These are temporary config files which are cached with changes made from the console. Once you do activate changes, config.xml and other config files from here replaces the original config.xml and other configuration files inside the DOMAIN_HOME/config folder.

4. Move (do not copy) config.xml and all other config files from DOMAIN_HOME/pending folder to DOMAIN_HOME/config folder and replace the ones which are there.

5. Delete edit.lok inside DOMAIN_HOME and config.lok inside DOMAIN_HOME/config folder and restart Admin Server.

6. Log into the console and verify that the changes have taken effect.

This issue usually occurs with the admin console running in https mode rather than http mode.