1. Patching Guide for Release 3.0.2
  2. Patching Individual Components

4 Patching Individual Components

The granular patching mechanism allows you to perform patching procedures for individual hardware and software components. Besides the components included in the management node patch, you can also patch different categories of firmware, the operating system and appliance-specific software on the compute nodes, and Oracle Cloud Infrastructure images.

When you are installing multiple patches at the same time perform the patching operations in this order:

  1. Compute nodes

  2. Management nodes

  3. MySQL cluster database

  4. EtcD

  5. Vault

  6. Kubernetes cluster

  7. Platform

  8. Firmware

Patching a Compute Node

The compute node patching is similar to the management node host operating system patching: it ensures that the latest Oracle Linux kernel and user space packages are installed, as well as the ovm-agent package with appliance-specific optimizations. Compute nodes must be provisioned and locked, then patched one at a time, concurrent patches are not supported. After a successful patch, when a compute node has rebooted, the administrator must manually remove the locks to allow the node to return to normal operation.

Ensure synchronization of the mirror on the shared storage is complete prior to compute node patching by issuing the syncUpstreamUlnMirror command. For more information, see Prepare for Patching.

Using the Service Web UI

  1. Set the provisioning and maintenance locks for the compute node you are about to patch.

    For more information, refer to "Performing Compute Node Operations" in the Hardware Administration section of the Oracle Private Cloud Appliance Administrator Guide.

    1. In the navigation menu, click Rack Units. In the Rack Units table, click the name of the compute node you want to patch to display its detail page.

    2. In the top-right corner of the compute node detail page, click Controls and select the Provisioning Lock command.

    3. When the provisioning lock is set, click Controls again and select the Maintenance Lock command.

  2. In the navigation menu, click Upgrade & Patching.

  3. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  4. Select the appropriate patch request type: Patch CN.

  5. If required, fill out the request parameters:

    • Host IP: Enter the compute node's assigned IP address in the internal administration network. This is an IP address in the internal 100.96.2.0/23 range.

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter: uln=https://host.example.com/yum.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

    • Advanced Options JSON: Not available.

  6. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

  7. When the compute node has been patched successfully, release the provisioning and maintenance locks.

    For more information, refer to "Performing Compute Node Operations" in Hardware Administration.

    1. Open the compute node detail page.

    2. In the top-right corner of the compute node detail page, click Controls and select the Maintenance Unlock command.

    3. When the maintenance lock has been released, click Controls again and select the Provisioning Unlock command.

Using the Service CLI

  1. Gather the information that you need to run the command:

    • the IP address of the compute node you intend to patch

    • the fully qualified domain name of the ULN mirror in your datacenter

  2. Set the provisioning and maintenance locks for the compute node you are about to patch.

    For more information, refer to "Performing Compute Node Operations" in the Hardware Administration section of the Oracle Private Cloud Appliance Administrator Guide. 

    PCA-ADMIN> list ComputeNode
Data:
  id                                     name       provisioningState   provisioningType
  --                                     ----       -----------------   ----------------
  363a26f4-fa34-4e4c-8e17-a1671a0b77d1   pcacn001   Provisioned         KVM
  9e8745c7-52e3-4aae-984c-e198869ee2cc   pcacn002   Provisioned         KVM
  56a9ecda-2402-427f-92d1-7f9be57dba36   pcacn003   Provisioned         KVM

PCA-ADMIN> provisioningLock id=363a26f4-fa34-4e4c-8e17-a1671a0b77d1

PCA-ADMIN> maintenanceLock id=363a26f4-fa34-4e4c-8e17-a1671a0b77d1

  3. Enter the patch command.

    Syntax (entered on a single line):

    patchCN 
hostIp=<compute-node-ip>
uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchCN hostIp=100.96.2.64 ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchCN hostIp=<compute-node-ip>.

  4. Use the request ID and the job ID to check the status of the patching process.

    PCA-ADMIN> getUpgradeJobs

  5. When the compute node patch has completed successfully and the node has rebooted, release the locks.

    For more information, refer to "Performing Compute Node Operations" in the Hardware Administration section of the Oracle Private Cloud Appliance Administrator Guide. 

    PCA-ADMIN> maintenanceUnlock id=363a26f4-fa34-4e4c-8e17-a1671a0b77d1
PCA-ADMIN> provisioningUnlock id=363a26f4-fa34-4e4c-8e17-a1671a0b77d1

  6. Proceed to the next compute node and repeat this procedure.

Patching the Management Node Operating System

The Oracle Linux host operating system of the management nodes must be patched one node at a time; a rolling patch of all management nodes is not possible. This patching process, which involves updating the kernel and system packages, must always be initiated from the management node that holds the cluster virtual IP. Thus, in a three-management-node cluster, when you have patched two management nodes, you must reassign the cluster virtual IP to one of the patched management nodes and execute the final patch command from that node. Each management node must be rebooted after a patch is applied.

You must patch management nodes one at a time, using each one's internal IP address as a command parameter. To obtain the host IP addresses, use the Service CLI command show ManagementNode name=<pcamn01> and look for the Ip Address in the output.

You cannot complete all of the patching tasks required in the Service Web UI for this component. Use the Service CLI to patch the management nodes.

Using the Service CLI

  1. Gather the information that you need to run the command:

    • the IP address of the management node for which you intend to patch the host operating system

    • the fully qualified domain name of the ULN mirror in your datacenter

  2. Run the Service CLI from the management node that holds the management cluster virtual IP.

    1. Log on to one of the management nodes and check the status of the cluster.

      # ssh root@pcamn01
# pcs status
Cluster name: mncluster
Stack: corosync
Current DC: pcamn02 (version 1.1.23-1.0.1.el7-9acf116022) - partition with quorum

Online: [ pcamn01 pcamn02 pcamn03 ]

Full list of resources:

 scsi_fencing         (stonith:fence_scsi):          Stopped (disabled)
 Resource Group: mgmt-rg
     vip-mgmt-int     (ocf::heartbeat:IPaddr2):      Started    pcamn02
     vip-mgmt-host    (ocf::heartbeat:IPaddr2):      Started    pcamn02
     vip-mgmt-ilom    (ocf::heartbeat:IPaddr2):      Started    pcamn02
     vip-mgmt-lb      (ocf::heartbeat:IPaddr2):      Started    pcamn02
     vip-mgmt-ext     (ocf::heartbeat:IPaddr2):      Started    pcamn02
     l1api            (systemd:l1api):               Started    pcamn02
     haproxy          (ocf::heartbeat:haproxy):      Started    pcamn02
     pca-node-state   (systemd:pca_node_state):      Started    pcamn02
     dhcp             (ocf::heartbeat:dhcpd):        Started    pcamn02
     hw-monitor       (systemd:hw_monitor):          Started    pcamn02

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

      In this example, the command output indicates that the node with host name pcamn02 currently holds the cluster virtual IP.

  3. Log in to the management node virtual IP and launch the Service CLI. 

    # ssh -l admin 100.96.2.32 -p 30006

  4. Enter the patch command.

    Choose one of the management nodes that is not currently hosting the virtual IP. In the prior example, pcamn02 holds the cluster virtual IP, so choose either pcamn01 or pcamn03 as your patch target.

    Syntax (entered on a single line):

    patchHost 
ULN=<http|https>://<hostname.domainname>/<sub-directories>
hostIp=<management-node-ip>

    Example:

    PCA-ADMIN> patchHost ULN=http://host.example.com/yum \
patchHost hostIp=100.96.2.33 \
Command: patchHost ULN=http://host.example.com/yum hostIp=100.96.2.33
Status: Success
Time: 2022-01-01 21:06:56.849 UTC
Data: Service request has been submitted.  Upgrade Job ID = 1632990827394-host-56156 \
Upgrade Request ID = UWS-1a97a8d9-54ef-478d-a0c0-348a17ba6755

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchHost hostIp=<management-node-ip>.

  5. Use the job ID to check the status of the patch process. The job ID is listed in the output of the patch command.

    PCA-ADMIN> getUpgradeJob upgradeJobId=1632990827394-host-56156

  6. At the end of the patching process, the management node is rebooted automatically.

    Wait approximately 5 minutes until the management node restarts.

  7. When the first management node host operating system patch has completed successfully, execute the same command for the next management node.

    PCA-ADMIN> patchHost hostIp=100.96.2.35 \
ULN=http://host.example.com/yum \

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchHost hostIp=<management-node-ip>.

  8. At the end of the patching process, the management node is rebooted automatically.

    Wait approximately 5 minutes until the management node restarts.

  9. When the second management node host operating system patch has completed successfully, move the cluster virtual IP to one of the upgraded management nodes.

    # ssh root@pcamn01
root@pcamn01's password:
Last login: Mon Jan 10 20:50:28 2022
# pcs resource move mgmt-rg pcamn01
# pcs status
Cluster name: mncluster
Stack: corosync
[...]
 scsi_fencing   (stonith:fence_scsi):   Stopped (disabled)
 Resource Group: mgmt-rg
     vip-mgmt-int       (ocf::heartbeat:IPaddr2):       Started pcamn01
     vip-mgmt-host      (ocf::heartbeat:IPaddr2):       Started pcamn01
[...]

    Moving the cluster virtual IP to another management node should only take a number of seconds and will close your current connection.

  10. Log in to the management node virtual IP and launch the Service CLI to execute the host operating system patch for the final management node. 

    # ssh -l admin 100.96.2.32 -p 30006
PCA-ADMIN> patchHost hostIp=100.96.2.34 \
ULN=http://host.example.com/yum \

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchHost hostIp=<management-node-ip>.

  11. At the end of the patching process, the management node is rebooted automatically.

    Wait approximately 5 minutes until the management node restarts.

    When this patch has completed successfully, the operating system on all management nodes is up-to-date.

Patching the MySQL Cluster Database

The MySQL Cluster database is patched independently of the management node host operating system; the MySQL packages are deliberately kept separate from the Oracle Linux upgrade.

Ensure you perform a system backup before you apply a patch. See the Backup and Restore section of the Oracle Private Cloud Appliance Administrator Guide.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch MySQL.

  4. If required, fill out the patch request parameters:

    • ULN: the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. If you have not previously followed the instructions to prepare the patching environment, gather the information that you need to run the command:

    • the fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchMySQL 
ULN=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchMySQL ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchMySQL.

  3. Use the request ID and the job ID to check the status of the patch process.

    PCA-ADMIN> getupgradejobs
Command: getupgradejobs
Status: Success
Time: 2022-01-24 18:53:22,117 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1642593347925-mysql-40566        UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   mysql         Passed

PCA-ADMIN> getupgradejobs requestid=UWS-1ee38895-dedf-41c5-ab77-eebe294707ed
Command: getupgradejobs requestid=UWS-1ee38895-dedf-41c5-ab77-eebe294707ed
Status: Success
Time: 2022-01-24 18:54:05,408 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1642593347925-mysql-40566        UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   mysql         Passed

Patching Etcd and Vault

The secret service contains two components that need to be patched separately: Etcd and Vault. The order in which you patch them is not relevant.

The Etcd and Vault patches are rolling patches: each patch is executed on all three management nodes with one command.

Ensure you perform a system backup before you apply a patch. See the Backup and Restore section of the Oracle Private Cloud Appliance Administrator Guide.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch Etcd.

  4. If required, fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

  6. When the Etcd patch has completed successfully, repeat this procedure to create a patch for Vault.

Using the Service CLI

  1. If you have not previously followed the instructions to prepare the patching environment, gather the information that you need to run the command:

    • The fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchVault
uln=<http|https>://<hostname.domainname>/<sub-directories>

patchEtcd 
uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchVault ULN=http://host.example.com/yum

PCA-ADMIN> patchEtcd ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchVault, patchEtcd.

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getupgradejobs
Command: getupgradejobs
Status: Success
Time: 2022-01-24 18:53:22,117 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1642594274785-vault-29202        UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   vault         Passed
  1642593966208-etcd-6066          UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   etcd          Passed

PCA-ADMIN> getupgradejobs requestid=UWS-1ee38895-dedf-41c5-ab77-eebe294707ed
Command: getupgradejobs requestid=UWS-1ee38895-dedf-41c5-ab77-eebe294707ed
Status: Success
Time: 2022-01-24 18:54:05,408 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------  
  1642594274785-vault-29202        UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   vault         Passed
  1642593966208-etcd-6066          UWS-1ee38895-dedf-41c5-ab77-eebe294707ed   etcd          Passed

Patching the Kubernetes Cluster

The Kubernetes container orchestration environment patching is also kept separate from the operating system. With a single command, all Kubernetes packages, such as kubeadm, kubectl and kubelet, are patched on the three management nodes and all the compute nodes. Note that this patching does not include the microservices running in Kubernetes containers.

Ensure synchronization of the mirror on the shared storage is complete prior to Kubernetes patching by issuing the syncUpstreamUlnMirror command. For more information, see Prepare for Patching.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch Kubernetes.

  4. If required, fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. If you have not previously followed the instructions to prepare the patching environment, gather the information that you need to run the command:

    • The fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchKubernetes 
uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchKubernetes ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchKubernetes.

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getupgradejobs
Command: getupgradejobs
Status: Success
Time: 2022-01-18 20:11:16,398 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1642509549088-kubernetes-51898   UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5   kubernetes    Passed
  1642492793827-oci-12162          UWS-6e06bbb7-16b8-49ba-9c33-f42fffbe1323   oci           Failed
PCA-ADMIN> getupgradejobs requestid=UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5
Status: Success
Time: 2022-01-18 20:12:52,760 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1642509549088-kubernetes-51898   UWS-4f0d9e99-a515-4170-ab35-9f8bdcbdb2b5   kubernetes    Passed
PCA-ADMIN>

Patching the Platform

The platform patching covers both the internal services of the platform layer, and the administrative and user-level services exposed through the infrastructure services layer.

The containerized microservices have their own separate patching mechanism. A service is patched if a new Helm deployment chart and container image are found in the pca302_containers ULN channel. When a new deployment chart is detected during the patching process, the pods running the services are restarted with the new container image.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch Platform.

  4. If required, fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. If you have not previously followed the instructions to prepare the patching environment, gather the information that you need to run the command:

    • The fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchPlatform uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchPlatform ULN=http://host.example.com/yum
Command: patchPlatform ULN=http://host.example.com/yum
Status: Success
Time: 2021-12-08 17:36:12,217 UTC
Data:
  Service request has been submitted. Upgrade Job Id = 1638984971208-platform-79257 \
Upgrade Request Id = UWS-39f3f08f-b2d1-4804-8185-2dd3af60dd41

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchPlatform.

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getupgradejobs
Command: getupgradejobs
Status: Success
Time: 2021-12-08 17:36:34,657 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1638984971208-platform-79257     UWS-39f3f08f-b2d1-4804-8185-2dd3af60dd41   platform      None

PCA-ADMIN> getupgradejob upgradeJobId=1638984971208-platform-79257
Command: getupgradejob upgradeJobId=1638984971208-platform-79257
Status: Success
Time: 2021-12-08 17:36:19,385 UTC
Data:
  Upgrade Request Id = UWS-39f3f08f-b2d1-4804-8185-2dd3af60dd41
  Name = platform
  Start Time = 2021-12-08T17:36:11
  Pid = 79257
  Host = pcamn02
  Log File = /nfs/shared_storage/pca_upgrader/log/pca-upgrader_platform_services_2021_12_08-17.36.11.log
  Arguments = {"component_names":null,"diagnostics":false,"display_task_plan":false,"dry_run_tasks":false, \
  "expected_iso_checksum":null,"fail_halt":false,"fail_upgrade":null,"image_location":null, \
[...]
  Process = alive
  Tasks 1 - Name = Validate ULN Channel URL
  Tasks 1 - Description = Verify that the ULN channel URL is accessible
  Tasks 1 - Time = 2021-12-08T17:36:12
[...]

Patching Firmware

Firmware is included in the ISO image for all component ILOMs, for the Oracle ZFS Storage Appliance, and for the switches. Select the instructions below for the component type you want to patch.

Obtaining an ILOM IP Address

Using the Service Web UI

  1. In the navigation menu, click Rack Units.

  2. Click on the name of the component you are patching.

  3. Select the Rack Unit Information tab.

  4. Record the IP Address listed under ILOM IPs.

Using the Service CLI

  1. Find the component ID:

    Syntax (entered on a single line):

    list <component>

    Example:

    PCA-ADMIN> list computeNode
Command: list computeNode
Status: Success
Time: 2021-12-17 21:30:41,064 UTC
Data:
  id                                     name       provisioningState   provisioningType
  --                                     ----       -----------------   ----------------
  03111396-bb33-4249-9561-b921387c6f3a   pcacn003   Provisioned         KVM
  1600443b-00f3-4424-946d-bd52df778aaf   pcacn001   Provisioned         KVM
  69e4e3b7-9390-4283-b246-49ebedccac95   pcacn002   Provisioned         KVM

  2. Use the component ID to show the details of that component.

    PCA-ADMIN> show computeNode id=03111396-bb33-4249-9561-b921387c6f3a
Command: show computeNode id=03111396-bb33-4249-9561-b921387c6f3a
Status: Success
Time: 2021-12-17 21:42:47,724 UTC
Data:
  Id = 03111396-bb33-4249-9561-b921387c6f3a
  Type = ComputeNode
  Provisioning State = Provisioned
[...]
  Ip Address = 100.96.2.64
  ILOM Ip Address = 100.96.0.64
  Hostname = pcacn001
[...]

Patching ILOMs

ILOM patches can be applied to management nodes and compute nodes. Firmware packages may be different per component type, so make sure you select the correct one from the firmware directory. You must patch ILOMs one at a time, using each one's internal IP address as a command parameter.

Caution:

You must NOT patch the ILOM of the management node that holds the management virtual IP address, and thus the primary role in the cluster. To patch its ILOM, first reboot the management node in question so that another node in the cluster takes over the primary role. Once the node has rebooted completely, you can proceed with the ILOM patch.

To determine which management node has the primary role in the cluster, log in to any management node and run the command pcs status.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch ILOM.

  4. Fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Host IP: Enter the component's assigned IP address in the ILOM network.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. Gather the information that you need to run the command:

    • the IP address of the ILOM for which you intend to patch the firmware

    • the fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchIlom
hostIp=<ilom-ip>
uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchIlom hostIp=100.96.4.62 \
ULN=http://host.example.com/yum \

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchIlom hostIp=<ilom-ip>.

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getUpgradeJobs
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1620921089806-ilom-21480         UWS-732d6fce-9f06-4329-b972-d093bee40010   ilom          Passed

PCA-ADMIN> getupgradejobs requestid=UWS-732d6fce-9f06-4329-b972-d093bee40010
Command: getupgradejobs requestid=UWS-732d6fce-9f06-4329-b972-d093bee40010
Status: Success
Time: 2022-01-24 18:23:39,690 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1620921089806-ilom-21480         UWS-732d6fce-9f06-4329-b972-d093bee40010   ilom          Passed

  4. Use the syncHardwareData command to update the hardware attributes in the system hardware database.

    Note:

    The syncHardwareData command is also used for internal automated system tasks. If this automated task is running when you issue the syncHardwareData command manually, a lock will prevent your command from running and you could see this error:
    This command cannot be performed at this time. Please try again.
    Wait a few moments, then re-issue the syncHardwareData command.

At the end of the patch, the ILOM itself is rebooted automatically. However, the server component also needs to be rebooted for all changes to take effect.

Patching the ZFS Storage Appliance Operating Software

To patch the operating software of the system's ZFS Storage Appliance, you only need to provide the path to the ULN mirror. The IP addresses of the storage controllers are known, and a single command initiates a rolling patch of both controllers.

Caution:

Ensure users are not logged in to the ZFS Storage Appliance or the ZFS Storage Appliance ILOM during the upgrade process.

Caution:

Do not make storage configuration changes while an upgrade is in progress. While controllers are running different software versions, configuration changes made to one controller are not propagated to its peer controller.

Note:

ZFS Storage Appliance updates may include ILOM and or BIOS firmware. If an update to the BIOS firmware is required, there will be a note in the Upgrader log indicating that the BIOS will be updated the next time the storage head is shut down.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch Zfssa.

  4. Fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. Gather the information that you need to run the command: the path to the AK-NAS firmware package in the ULN mirror.

  2. Enter the patch command.

    Syntax:

    patchZfssa uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchZfssa ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchZfssa.

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getUpgradeJobs
Status: Success
Time: 2022-01-24 18:19:29,731 UTC
Data:
  id                               upgradeRequestId                           commandName   result
  --                               ----------------                           -----------   ------
  1643035466051-zfssa-62915        UWS-831fd008-cc32-428d-8e76-91c43081f6e7   zfssa         Passed
 
PCA-ADMIN> getupgradejobs requestid=UWS-831fd008-cc32-428d-8e76-91c43081f6e7
Command: getupgradejobs requestid=UWS-831fd008-cc32-428d-8e76-91c43081f6e7
Status: Success
Time: 2022-01-24 18:27:52,083 UTC
Data:
  id                          upgradeRequestId                           commandName   result
  --                          ----------------                           -----------   ------
  1643035466051-zfssa-62915   UWS-831fd008-cc32-428d-8e76-91c43081f6e7   zfssa         Passed

Patching the Switch Software

The appliance rack contains three categories of Cisco Nexus switches: a management switch, two leaf switches, and two spine switches. They all run the same Cisco NX-OS network operating software. There is no preferred patching order for the switches.

When patching their firmware, use the same binary file with each patch command. Only one command per switch category is required, meaning that the leaf switches and the spine switches are patched in pairs.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch Switch.

  4. Fill out the patch parameters:

    • ULN: Enter the fully qualified domain name of the ULN mirror in your datacenter.

      This parameter is optional if you followed the instructions to prepare the patching environment.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

    • Switch Type: Select the switch type you intend to patch. The preferred order is as follows: leaf switches first, then spine switches, and finally the management switch.

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

  6. When the patch has completed successfully, but other switches in the system still need to be patched, repeat this procedure for any other type of switch that requires patching.

Using the Service CLI

  1. Gather the information that you need to run the command:

    • the type of switch to patch (spine, leaf, management)

    • the fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchSwitch 
switchType=[MGMT, SPINE, LEAF] 
imageLocation=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchSwitch switchType=LEAF \
imageLocation=http://host.example.com/yum \

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchSwitch switchType=[MGMT, SPINE, LEAF].

  3. Use the request ID and the job ID to check the status of the upgrade process.

    PCA-ADMIN> getUpgradeJobs

  4. Use the syncHardwareData command to update the hardware attributes in the system hardware database.

    Note:

    The syncHardwareData command is also used for internal automated system tasks. If this automated task is running when you issue the syncHardwareData command manually, a lock will prevent your command from running and you could see this error:
    This command cannot be performed at this time. Please try again.
    Wait a few moments, then re-issue the syncHardwareData command.

Patching Oracle Cloud Infrastructure Images

When new Oracle Cloud Infrastructure Images become available and supported for Oracle Private Cloud Appliance between major releases, you can pick up these images using the patching process.

Oracle Cloud Infrastructure Images installed using the patching method are stored in the /nfs/shared_storage/oci_compute_images directory on the ZFS storage appliance.

Using the Service Web UI

  1. In the navigation menu, click Upgrade & Patching.

  2. In the top-right corner of the Upgrade Jobs page, click Create Upgrade or Patch.

    The Create Request window appears. Choose Patch as the Request Type.

  3. Select the appropriate patch request type: Patch OCIImages.

  4. If required, fill out the request parameters:

    • ULN: Enter the path to the shared storage.

    • Advanced Options JSON: Not available.

    • Log Level: Optionally, select a specific log level for the upgrade log file. The default log level is "Information". For maximum detail, select "Debug".

  5. Click Create Request.

    The new patch request appears in the Upgrade Jobs table.

Using the Service CLI

  1. If you have not previously followed the instructions to prepare the patching environment, gather the information that you need to run the command:

    • The fully qualified domain name of the ULN mirror in your datacenter

  2. Enter the patch command.

    Syntax (entered on a single line):

    patchOCIimages 
uln=<http|https>://<hostname.domainname>/<sub-directories>

    Example:

    PCA-ADMIN> patchOCIimages ULN=http://host.example.com/yum

    If you followed the instructions to prepare the patching environment, simply enter the command without the ULN parameter: patchOCIimages.

  3. Use the request ID and the job ID to check the status of the patching process.

    PCA-ADMIN> getupgradejobs
Command: getupgradejobs
Status: Success
Time: 2022-01-18 19:58:34,745 UTC
Data:
  id                             upgradeRequestId                           commandName   result
  --                             ----------------                           -----------   ------
  1641839285475-oci-94665        UWS-778b08bc-f579-492b-993d-915dcf581374   oci           Passed
  1641838937541-platform-56313   UWS-bc4372ae-8f51-4b40-9306-992fb6459878   platform      Failed
  
PCA-ADMIN> getupgradejobs requestid=UWS-778b08bc-f579-492b-993d-915dcf581374
Command: getupgradejobs requestid=UWS-778b08bc-f579-492b-993d-915dcf581374
Status: Success
Time: 2022-01-18 20:00:43,804 UTC
Data:
  id                        upgradeRequestId                           commandName   result
  --                        ----------------                           -----------   ------
  1641839285475-oci-94665   UWS-778b08bc-f579-492b-993d-915dcf581374   oci           Passed
PCA-ADMIN>