step5 patching psu july ge

8/17/2019 Step5 Patching PSU JULY GE

1/5

1 Restart the Exalogic Control Stack and Refresh the Oracle VM Manager Data1.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 right-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 vServersThis is applicable to Exalogic machines that are at version earlier than 2.0.6.2.1 of the Exalogic infrastructure.

2.1 PrerequisitesBack 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 vServersPatch 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 following command on the first compute node:

[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a patch ectemplatesIf 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 described in the ExaPatch User's Guide. If authentication is enabled, the HTTP URI must be explicitly specified with the -u option, as follows:

-u http://:@/shares/export/common/exalogic-lcdata/patches/Virtual/20383732/InfrastructurePatching each vServer template can take at least 25 minutes. The total durationfor this step is at least 75 minutes. During the patching process, the progresscan 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 Template 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.logINFO: vServer-EC-OVMM xx.xx.xx.121 successfully completed all pre-patch checksUpgrading Base Template on vServer-EC-OVMM host xx.xx.xx.121 from version: 2.0.6.0.0Completed upgrade of Base Template on vServer-EC-OVMM host xx.xx.xx.121 new vers


2/5

ion: 2.0.6.2.1INFO: vServer-EC-OVMM xx.xx.xx.121 successfully completed all post-patch checksCompleted patching VM template vServer-EC-OVMM xx.xx.xx.121INFO: vServer-EC-EMOC-PC xx.xx.xx.150 successfully completed all pre-patch checksStarting to patch VM template vServer-EC-EMOC-PC xx.xx.xx.150Upgrading Base Template on vServer-EC-EMOC-PC host xx.xx.xx.150 from version: 2.0.6.0.0Completed upgrade of Base Template on vServer-EC-EMOC-PC host xx.xx.xx.150 new version: 2.0.6.2.1INFO: vServer-EC-EMOC-PC xx.xx.xx.150 successfully completed all post-patch checksCompleted patching VM template vServer-EC-EMOC-PC xx.xx.xx.150INFO: vServer-EC-EMOC-PC xx.xx.xx.151 successfully completed all pre-patch checksStarting to patch VM template vServer-EC-EMOC-PC xx.xx.xx.151Upgrading Base Template on vServer-EC-EMOC-PC host xx.xx.xx.151 from version: 2.0.6.0.0Completed upgrade of Base Template on vServer-EC-EMOC-PC host xx.xx.xx.151 new version: 2.0.6.2.1INFO: vServer-EC-EMOC-PC xx.xx.xx.151 successfully completed all post-patch chec

ksCompleted patching VM template vServer-EC-EMOC-PC xx.xx.xx.151

3 (optional) Patch Guest vServers3.1 PrerequisitesThe following prerequisites must be fulfilled on all guest vServers before theycan 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 system. 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 procedure 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 ofyum 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 conflict/missing dependency issues during RPM YUM update initiated by Exapatch. For example an error message may appear in exapatch logs like:

Error: Missing Dependency: = is needed by package (installed).Example:Error: libstdc++ = 4.1.2-50.el5 is needed by package libstdc++-devel-4.1.2-50.el5.i386 (installed)YUM update has encountered issues. Inspect logs, resolve any conflicts or other


3/5

issues manually, and RERUN this scriptSolution:To overcome/avoid such dependency issues, you can make use of the Custom RPM Repo. Follow the steps:1.The Custom Repo directory is located at:/exalogic-lcdata/patches/Virtual/20383732/Infrastructure/BaseTemplateOEL5Supplementary/OracleLinux_5.8/Custom/2.Obtain the dependent package of the revised version. For example, install thelibstdc++-devel RPM of the same version as libstdc++ v4.1.2-50.el53.Copy over the rpm to the 'Custom' Repo. For example:# cp libstdc++-devel-4.1.2-54.el5.i386.rpm /exalogic-lcdata/patches/Virtual/20383732/Infrastructure/BaseTemplateOEL5Supplementary/OracleLinux_5.8/Custom/4.Create YUM Repo metadata:# cd /exalogic-lcdata/patches/Virtual/20383732/Infrastructure/BaseTemplateOEL5Supplementary/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 vServerTo 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 [-h ]In this command, is the IP address of the vServer that should be upgraded. To patch multiple guest vServers, you can specify 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 described in the ExaPatch User's Guide. If authentication is enabled, the HTTP URI must be explicitly specified with the -u option, as follows:

-u http://:@/shares/export/common/exalogic-lcdata/patches/Virtual/20383732/Infrastructure

NOTE:

1) During the patching process, the RPMs on the vServer will be upgraded. Priorto the actual upgrade any YUM dependency conflict is checked and patching is aborted. 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 console of the vServer being patched. After each reboot, you should run xm console again to reconnect to the vServer.

3) Do not interrupt the script. Interrupting it may leave the node in an inconsistent state.

4) Exapatch runs disk space check before patching. In case there is not enough disk 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.


4/5

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.logEnter root password for guest vServers:INFO: vServer-Generic xx.xx.xx.xx successfully completed all pre-patch checksUpgrading Base Template on vServer-Generic host xx.xx.xx.xx from version: 2.0.6.0.0Completed upgrade of Base Template on vServer-Generic host xx.xx.xx.xx new version: 2.0.6.2.1INFO: vServer-Generic xx.xx.xx.xx successfully completed all post-patch checksCompleted patching VM templates.

4 Appendix A: Starting the Exalogic Control vServersTo start the Exalogic Control vServers, log in to the first compute node and run the following command:

[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a ecvserversstartupThis process takes approximately 25 minutes.Manually verify that you can log in to both the Oracle VM Manager BUI and the Exalogic Control BUI.

5 Appendix B: Stopping the Exalogic Control vServersTo shutdown the Exalogic Control vServers, log in to the first compute node andrun the following command:

[root@ogeld01cn01]# /exalogic-lctools/bin/exapatch -a ecvserversshutdown

6 Appendix C: Backing up Exalogic vServers1.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 virtualmachines, as shown in the following example: [root@computenode VirtualMachines]# grep -i ExalogicControl */vm.cfg 0004fb000006000086fc4245ba13b356/vm.cfg:OVM_simple_name = 'ExalogicControl' 0004fb0000060000d53ff52b57583f6e/vm.cfg:OVM_simple_name = 'ExalogicControlOpsCenterPC1' 0004fb0000060000e65e470080d24f60/vm.cfg:OVM_simple_name = 'ExalogicControlOpsCenterPC2'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 component of the Exalogic Control stack.

You can identify the location and name of the virtual-disk image file from the disk parameter in the vm.cfg file, as shown in the following example:

cat 0004fb000006000086fc4245ba13b356/vm.cfg | grep filedisk = ['file:/OVS/Repositories/0004fb00000300007d5117500d92ae54/VirtualDisks/0004fb00001200003d3b8b4058ee7682.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


5/5

/*/backup_vms directory.

7.Start the control vServers as mentioned in Appendix A. In the case of guest vServers, start them after logging into Exalogic Control BUI.

7 Appendix D: Restoring Exalogic vServers1.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 - AppendixC)

3.Start the control vServers as mentioned in Appendix A. In the case of guest vServers, start them after logging into Exalogic Control BUI.

step5 patching psu july ge

Documents