Patching Job - Independent Solaris LDoms can be patched simultaneously
In versions earlier than BMC Server Automation version 8.2, administrators needed to patch primary and guest Oracle Solaris Logical Domains (LDoms) separately. If they added primary and guest LDoms to the same Patch Analysis Job, the Deploy Jobs conflicted with the patch installation on the guest LDoms that occurred during primary LDom patching. Starting with BMC Server Automation version 8.2, administrators can add primary and guest Solaris LDoms to the same Patching Analysis Job, and remediate both LDoms simultaneously. If the Analysis or Remediation Job contains both primary and guest LDoms, then patching proceeds by first creating separate Batch Jobs for the primary and guest LDoms, and then by creating a master Batch Job that patches the guest LDoms before the primary LDoms. Creating a master Batch Job avoids Deploy Job conflicts with installation of patches on the guest LDoms.
The following topics provide information about how to set up Solaris LDom patches and known issues for these patches.
Analyzing and deploying Solaris LDom patches
Starting with BMC Server Automation version 8.2, administrators can
- Create Batch Jobs for primary and guest LDoms
- Create a Master Batch Job to patch the guest LDoms before the primary LDoms
Stop and restart the guest LDoms before and after the patch deployment on the primary LDoms
- You cannot use the existing Deploy Jobs or BLPackages for patching Solaris LDoms.
- The primary and guest LDom Deploy jobs must not be scheduled to run in parallel, because changes to the primary LDom during execution (such as the primary LDom being rebooted) impact the guest LDom patching. To ensure that the primary LDom Deploy Jobs are executed after the guest LDom Deploy Jobs finish execution, execute only the Master Batch Job. The Master Batch Job ensures that the primary and guest LDom Deploy Jobs are correctly sequenced.
Setting up Patch Global Configuration to stop and restart LDoms
The Solaris tab on the Patch Global Configuration panel contains a new item, Ldom option, which allows the following values:
- None (default value): This option ignores the LDoms and treats the targets as physical installations of Solaris. Use this option if you want to ignore the LDoms even if LDom packages are installed on your computer.
- Stop Ldoms using ldm stop: This option stops the LDoms using the
ldm stopcommand (however, the guest LDoms are not gracefully shutdown).
Shutdown Ldoms using ldm-names as hostname: This option executes the
shutdowncommand on the guests using the nexec parameter, using ldm-name as the hostname for nexec.
The guest LDoms whose status is Active must have the agent installed and must be accessible from the BMC Server Automation Application Server by their ldm-name.
Stopping and restarting the guest LDoms before and after patch deployment
The Solaris LDom BLPackage contains a Stop LDoms ExternalCmd item, as shown in the following figure. This ExternalCmd item ensures that the guest LDoms are stopped before the primary LDoms are patched, and restarts the guest LDoms after the patching of primary LDoms is completed.
The Stop LDoms ExternalCmd maps to the ldom stop Patch Configuration Panel option.
Creating a Master Batch Job to patch the guest LDoms before the primary LDoms
The Master Batch Job contains the primary and guest LDom Deploy Jobs, which are executed in the following sequence (as shown in the following figure):
- The guest LDom Deploy Job is executed, which deploys the patches on the guest LDoms.
- The primary LDom Deploy Job is executed, which deploys the patches on the primary LDoms.
The following figure shows the Master Deploy Job, which contains the primary and guest LDom Deploy Jobs.
LDom patching workflow
The Master Deploy Job executes LDom patching in the following sequence:
- The guest LDoms Deploy Job is executed.
- An NSH Script Job to shutdown the guest LDoms from the Application Server using the
shutdowncommand is executed.
- The primary LDoms Deploy Job is executed.
To use the Solaris LDom patching functionality, administrators must have NSH Script create and read permissions, and NSH Script Job create, read, and execute permissions.
The NSH Script Job contains an associated NSH script in the Depot in the same location as the BlPackage. When the Shutdown Ldoms using ldm-names as hostname option is selected, the NSH Script Job and the NSH script ensure graceful shutdown of the guest LDoms.
Known issues in Solaris LDom patching
The following known issues remain in Solaris LDom patching:
- Selecting the Stop Ldoms using ldom stop option in the Patch Global Configuration tab stops the guest LDoms (before patching the primary LDoms) without gracefully shutting down the guest LDoms.
- The Shutdown Ldoms using ldm-names as hostname option in the Patch Global Configuration tab assumes that the ldm-name is the same as the hostname used by the nexec parameter to shutdown the guest LDoms gracefully.
Guidelines for Solaris LDom patching
BMC specifies the following guidelines for Solaris LDom patching:
- Add both a primary and its guest LDoms to the same Patching Analysis Job.
BMC does not recommend patching a primary LDom and its guest LDoms using different Patching Analysis Jobs, because patching the primary and LDoms separately might incorrectly sequence the primary and guest LDom Deploy Jobs, leading to the problems noted in the Analyzing and deploying Solaris LDom patches section.
- Administrators see Batch Jobs corresponding to the primary and guest LDom Deploy Jobs on the BMC Server Automation Console, but they must not execute those Batch Jobs manually.