1 Restart the Exalogic Control Stack and Refresh the Oracle VM Manager Data

1.If the vServers were stopped as part of the ILOM and/or Compute Node upgrade,
restart the Exalogic Control vServers as described in Appendix A.
2.In the Oracle VM Manager console, select the Servers and VMs tab, select and r
ight-click Server Pools, and click Refresh all.
3.If a warning icon () is displayed for the compute node icon in the left panel,
select the compute node, right click on the name and click Rediscover Server.

2 Patch the OVMM, PC1, and PC2 vServers

This is applicable to Exalogic machines that are at version earlier than 2.0.6.2
.1 of the Exalogic infrastructure.
2.1 Prerequisites
Back up the Exalogic Control Stack as mentioned in Appendix C
All Exalogic Control vServers must be running when the patching procedure starts.

2.2 Upgrade the Exalogic Control vServers

Patch the OVMM, PC1, and PC2 vServers using the following procedure:
1.Verify that the OVMM, PC1, and PC2 vServers are running.
2.Upgrade the base template for the OVMM, PC1, and PC2 vServers by running the f
ollowing command on the first compute node:
[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a patch ectemplates
If the -l logfilename option is not used, ExaPatch displays a message Logging
to file with the name of the log file.
This command assumes the default HTTP-based URI without authentication, as descr
ibed in the ExaPatch User's Guide. If authentication is enabled, the HTTP URI mu
st be explicitly specified with the -u option, as follows:
-u http://<username>:<password>@<host-ip>/shares/export/common/exalogic
-lcdata/patches/Virtual/20383732/Infrastructure
Patching each vServer template can take at least 25 minutes. The total duration
for this step is at least 75 minutes. During the patching process, the progress
can be tracked by using xm console to log in to the console of the vServer being
patched. If you are tracking the progress, after each vServer reboot you should
run xm console again to reconnect to the vServer console.
3.Verify that the console output displays the upgraded version of the Base Templ
ate as 2.0.6.2.1 for the OVMM, PC1, and PC2 vServers. If the template version is
not correct, resolve the issues and rerun the patch command above.
The following is a sample output displayed on the console:
Logging to file /var/log/exapatch_20141127140359.log
INFO: vServer-EC-OVMM xx.xx.xx.121 successfully completed all pre-patch checks
Upgrading Base Template on vServer-EC-OVMM host xx.xx.xx.121 from version:
2.0.6.0.0
Completed upgrade of Base Template on vServer-EC-OVMM host xx.xx.xx.121 new vers

ion:
2.0.6.2.1
INFO: vServer-EC-OVMM xx.xx.xx.121 successfully completed all post-patch checks
Completed patching VM template vServer-EC-OVMM xx.xx.xx.121
INFO: vServer-EC-EMOC-PC xx.xx.xx.150 successfully completed all pre-patch check
s
Starting to patch VM template vServer-EC-EMOC-PC xx.xx.xx.150
Upgrading Base Template on vServer-EC-EMOC-PC host xx.xx.xx.150 from version:
2.0.6.0.0
Completed upgrade of Base Template on vServer-EC-EMOC-PC host xx.xx.xx.150 new v
ersion:
2.0.6.2.1
INFO: vServer-EC-EMOC-PC xx.xx.xx.150 successfully completed all post-patch chec
ks
Completed patching VM template vServer-EC-EMOC-PC xx.xx.xx.150
INFO: vServer-EC-EMOC-PC xx.xx.xx.151 successfully completed all pre-patch check
s
Starting to patch VM template vServer-EC-EMOC-PC xx.xx.xx.151
Upgrading Base Template on vServer-EC-EMOC-PC host xx.xx.xx.151 from version:
2.0.6.0.0
Completed upgrade of Base Template on vServer-EC-EMOC-PC host xx.xx.xx.151 new v
ersion:
2.0.6.2.1
INFO: vServer-EC-EMOC-PC xx.xx.xx.151 successfully completed all post-patch chec
ks
Completed patching VM template vServer-EC-EMOC-PC xx.xx.xx.151
3 (optional) Patch Guest vServers
3.1 Prerequisites
The following prerequisites must be fulfilled on all guest vServers before they
can be upgraded to 2.0.6.2.1:
At least 1.1 GB of free space must exist on each guest vServer in the root file s
ystem. You can use yum clean all to free up disk space.
Back up the guest vServers as mentioned in Appendix C
All guest vServers that you are patching must be running when the patching proced
ure starts.
Custom Repo Setup:
Skip this step if there are no custom installed RPMs on the node being upgraded.
This step generally helps resolve any potential YUM update failures in case of
yum dependency issues.
If the node being upgraded contain custom RPMs, ie. additional RPMs installed by
end user (other than the standard set of rpms installed from BaseImage and PSU)
, these extra RPMs may have dependency on some of the Exalogic standard rpms tha
t will get updated by the Patch application. Due to which, there can be a confli
ct/missing dependency issues during RPM YUM update initiated by Exapatch. For ex
ample an error message may appear in exapatch logs like:
Error: Missing Dependency: <pkg-name> = <pkg-version> is needed by package <depe
ndent-pkg-name> (installed).
Example:
Error: libstdc++ = 4.1.2-50.el5 is needed by package libstdc++-devel-4.1.2-50.el
5.i386 (installed)
YUM update has encountered issues. Inspect logs, resolve any conflicts or other

issues manually, and RERUN this script

Solution:
To overcome/avoid such dependency issues, you can make use of the Custom RPM Rep
o. Follow the steps:
1.The Custom Repo directory is located at:
/exalogic-lcdata/patches/Virtual/20383732/Infrastructure/BaseTemplateOEL5Supplem
entary/OracleLinux_5.8/Custom/
2.Obtain the dependent package of the revised version. For example, install the
libstdc++-devel RPM of the same version as libstdc++ v4.1.2-50.el5
3.Copy over the rpm to the 'Custom' Repo. For example:
# cp libstdc++-devel-4.1.2-54.el5.i386.rpm /exalogic-lcdata/patches/Virtual/2038
3732/Infrastructure/BaseTemplateOEL5Supplementary/OracleLinux_5.8/Custom/
4.Create YUM Repo metadata:
# cd /exalogic-lcdata/patches/Virtual/20383732/Infrastructure/BaseTemplateOEL5Su
pplementary/OracleLinux_5.8/Custom/
# createrepo .
(Notice the "." along with the command, meant for current directory)
Proceed to upgrade the vServer.
3.2 Upgrade the Guest vServer
To upgrade the guest vServers, do the following:
1.Log in to the first compute node and run the following command:
[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a patch vserver -h <vs
erverIP1> [-h <vServerIPn>]In this command, <vserverIPn> is the IP address of th
e vServer that should be upgraded. To patch multiple guest vServers, you can spe
cify multiple -h vserverIP options.
If the -l logfilename option is not used, ExaPatch displays a message Logging to
file with the name of the log file.
This command assumes the default HTTP-based URI without authentication, as descr
ibed in the ExaPatch User's Guide. If authentication is enabled, the HTTP URI mu
st be explicitly specified with the -u option, as follows:
-u http://<username>:<password>@<host-ip>/shares/export/common/exalogic
-lcdata/patches/Virtual/20383732/Infrastructure
NOTE:
1) During the patching process, the RPMs on the vServer will be upgraded. Prior
to the actual upgrade any YUM dependency conflict is checked and patching is abo
rted. In this case, resolve as explained in above Prerequisite section on Custom
Repo setup. And re-attempt the vServer patching.
2) The guest vServer will reboot during the upgrade process. During the patching
process, the progress can be tracked by using the xm console to log in to the c
onsole of the vServer being patched. After each reboot, you should run xm consol
e again to reconnect to the vServer.
3) Do not interrupt the script. Interrupting it may leave the node in an inconsi
stent state.
4) Exapatch runs disk space check before patching. In case there is not enough d
isk space to apply the patch, then prepatch checks will fail. If prepatch checks
fail due to insufficient disk space, then additional disk space can be added to
the vServer by following the procedure Section F.1, "Increasing the Size of the
Root Partition" of Oracle Exalogic Elastic Cloud Administrator's Guide.

The following is a sample output displayed on the console while patching from 2.
0.6.0.0 :
Logging to file /var/log/exapatch_20141124132351.log
Enter root password for guest vServers:
INFO: vServer-Generic xx.xx.xx.xx successfully completed all pre-patch checks
Upgrading Base Template on vServer-Generic host xx.xx.xx.xx from version:
2.0.6.0.0
Completed upgrade of Base Template on vServer-Generic host xx.xx.xx.xx new versi
on:
2.0.6.2.1
INFO: vServer-Generic xx.xx.xx.xx successfully completed all post-patch checks
Completed patching VM templates.
4 Appendix A: Starting the Exalogic Control vServers
To start the Exalogic Control vServers, log in to the first compute node and run
the following command:
[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a ecvserversstartup
This process takes approximately 25 minutes.
Manually verify that you can log in to both the Oracle VM Manager BUI and the Ex
alogic Control BUI.
5 Appendix B: Stopping the Exalogic Control vServers
To shutdown the Exalogic Control vServers, log in to the first compute node and
run the following command:
[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a ecvserversshutdown
6 Appendix C: Backing up Exalogic vServers
1.Shutdown the control vServers as mentioned in Appendix B. In the case of guest
vServers, shutdown the guest VM after logging into Exalogic Control BUI.
2.Go to the /OVS/Repositories/*/VirtualMachines directory.
3.Find the virtual-machine configuration files for the Exalogic Control virtual
machines, as shown in the following example:
[root@computenode VirtualMachines]# grep -i ExalogicControl */vm.cfg
0004fb000006000086fc4245ba13b356/vm.cfg:OVM_simple_name = 'ExalogicContr
ol'
0004fb0000060000d53ff52b57583f6e/vm.cfg:OVM_simple_name = 'ExalogicContr
olOpsCenterPC1'
0004fb0000060000e65e470080d24f60/vm.cfg:OVM_simple_name = 'ExalogicContr
olOpsCenterPC2'In the case of guest vServers, grep for the name of VM instead of
'ExalogicControl'.
4.Identify the location and name of the virtual-disk image file for each compone
nt of the Exalogic Control stack.
You can identify the location and name of the virtual-disk image file from the d
isk parameter in the vm.cfg file, as shown in the following example:
cat 0004fb000006000086fc4245ba13b356/vm.cfg | grep file
disk = ['file:/OVS/Repositories/0004fb00000300007d5117500d92ae54/VirtualDisks/00
04fb00001200003d3b8b4058ee7682.img,hda,w'
5.Make a backup directory /OVS/Repositories/*/backup_vms .
6.Create a copy of the virtual-disk image files from step 4 in /OVS/Repositories

/*/backup_vms directory.
7.Start the control vServers as mentioned in Appendix A. In the case of guest vS
ervers, start them after logging into Exalogic Control BUI.
7 Appendix D: Restoring Exalogic vServers
1.Shutdown the control vServers as mentioned in Appendix B. In the case of guest
vServers, shutdown the guest VM after logging into Exalogic Control BUI.
2.Replace the existing .img files in /OVS/Repositories/*/VirtualDisks with those
from the backed up directory /OVS/Repositories/*/backup_vms (Step 6 - Appendix
C)
3.Start the control vServers as mentioned in Appendix A. In the case of guest vS
ervers, start them after logging into Exalogic Control BUI.