Asset ID: |
1-75-1638577.1 |
Update Date: | 2018-01-11 |
Keywords: | |
Solution Type
Troubleshooting Sure
Solution
1638577.1
:
ODA Troubleshooting ODA Core Key Generation and Application Problems
Related Items |
- Oracle Database Appliance X4-2
- Oracle Database Appliance
- Oracle Database Appliance X5-2
- Oracle Database Appliance X3-2
- Oracle Database Appliance X6-2 HA Hardware
- Oracle Database Appliance Software
|
Related Categories |
- PLA-Support>Sun Systems>x86>Engineered Systems HW>SN-x64: ORA-DATA-APP
|
The ODA ( Oracle Database Appliance) also known as the ODA HA (high availability) uses a Capacity On-Demand CPU software licensing feature. ODA Capacity On-Demand allows you to easily scale up to 48 processor cores without incurring the costs and downtime usually associated with hardware upgrades as ALL cores already exist within the ODA HW. Each ODA server (2 servers per ODA) uses a Core Key to set the proper licensed count. This note provides guidance on common questions and problems regarding the ODA Core Key generation and application process. This note does not apply to the ODA Lite series which includes Small, Medium and Large single server versions (e.g. X6-2S , X6-2M, X6-2L)
In this Document
Applies to:
Oracle Database Appliance X5-2 - Version All Versions to All Versions [Release All Releases]
Oracle Database Appliance X3-2 - Version All Versions to All Versions [Release All Releases]
Oracle Database Appliance - Version All Versions to All Versions [Release All Releases]
Oracle Database Appliance X6-2 HA Hardware - Version All Versions to All Versions [Release All Releases]
Oracle Database Appliance Software - Version 2.1.0.1 to 12.1.2.9 [Release 2.1 to 12.1]
Information in this document applies to any platform.
ODA, Oracle Database Appliance, OAK, oakcli , Core Key, Core Count, Core Key generation,
Purpose
The Oracle Database Appliance (ODA) also known as the ODA HA (High Availability) uses a Capacity On-Demand CPU software licensing feature. ODA Capacity On-Demand allows you to easily scale up to 48 processor cores without incurring the costs and downtime usually associated with hardware upgrades as ALL cores already exist within the ODA hardware. Each ODA server (2 servers per ODA) uses a Core Key to set the proper licensed count.
This document provides guidance on common questions and problems regarding the ODA Core Key generation and application process. This note does not apply to the ODA Lite series which includes Small, Medium and Large (S/M/L) single server versions.
Troubleshooting Steps
Note:
Always check your HW Type and version when troubleshooting ODA Core Key Issues.
There are no less than three different methods available to alter (increase) core counts depending on the ODA HW type
- Legacy ODA: X5-2; X4-2; X3-2; V1 oakcli apply core_config_key </FullPath/Key_filename>
- ODA HA ( X6-2 ) oakcli update-cpucore --cores ##
- ODA 'Lite' X6-2 S/M/L ( small / medium and large) odacli update-cpucore -c ##
Recently added X7-2*
- ODA HA X7-2
- ODA X7-2 S/M
NOTE: As of X6-2 ODA products no longer need ODA Core Keys Generated from My Oracle Support:
X6-2 L , X6-2 M and X6-2 S use a non-MOS local core key application method.
ODA: X6-2 Capacity-On-Demand : How To Change & Register CPU Cores For Single-Node ODA Lite X6-2(S,M,L) or the Dual-Node ODA HA X6-2 (Doc ID 2220572.1)
ODA Lite
odacli update-cpucore -c ##
e.g. odacli update-cpucore -c 4
ODA HA
oakcli update-cpucore --cores ## -- Always apply from the first node
e.g. oakcli update-cpucore --cores 10 < where 10 is for each individual server = the 2-node ODA will be 2x this --cores count:
OS commands will show 2x PER server as hyperthreading is enabled
The same information can be used to search for answers in MOS or as needed as the initial context for defining your problem should you need a SR with Oracle Support Services.
What is the current Core Key Count
# oakcli show core_config_key
# odacli describe-cpucore
Describing the Core Key Problem
There is a specific process flow to generating an ODA Core Key.
This section helps you break down the ODA Core Key problem definition which can improve searching for known solutions.
If you cannot find the solution this information will provide the context of the problem which should be used if creating a SR with Oracle Support Services
Core Key Diagnostic Data Collection
In order to quickly identify the problem you will need a basic but essential set of information:
- ODA Configuration information - This includes the ODA Serial Number(s), HW and Platform information
- MOS information - Login, CSI, Account, Asset and Serial Number verification
- Core Key Information - How many Cores per server? Per ODA?
NOTE: Once created ODA CORE KEY COUNTS CAN ONLY BE INCREASED VIA MOS *
* ODA LITE X6-2L X6-2M and X6-2S
* New Rules for X6-2L X6-2M and X6-2S allow one-time reductions of Core Keys
* If for some reason you need to decrease the count of the total CPUs please Create a SR
Examples of Core Key Diagnostic Collection
This section provides Examples of commands used to collect Diagnostic information
Supplemental Core Key Symptom Quick Reference Matrix
This last section provides some tips based on symptoms pointing to potential problem sources.
While not exhaustive, this section is useful to understand factors involved with Core Key Problem Issues.
Issue Clarification for ODM
Describe the problem as related to only ONE of the following categories
The following section helps you break down the ODA Core Key problem definition which can improve searching for known solutions.
Please review the following problem types for tips to more quickly lead to problem types, potential sources and problem resolutions.
- MOS Account issues
If you can log into MOS, then is the problem...
- Unable to find ODA as my Asset via MOS
If you are able to find the ODA as an Asset in your MOS Account and see the serial number, then is the problem...
- Unable to generate a Core Key via MOS
If you are able to generate the Core Key via MOS, then is the problem...
- Unable to apply the Core Key on the ODA once generated via MOS
This can include applying a first time key or applying an upgraded Core Count Key.
MOS account issues
- Unable to login to MOS
- Able to login to MOS but unable to find ODA as an asset
- Unable to register using the CSI
- Unable to see asset under the CSI
- Unable to see Core Key Generation option
Unable to find ODA as my Asset via MOS
- Make sure an account created on MOS for the ODA HW CSI
- Check if using the wrong CSI
- Confirm you have a MOS login under the ODA HW CSI
- While you are able to log into MOS using the correct ODA HW CSI you fail to see the Core Key generation prompt
- Confirm you have privs to see the ODA HW , serial numbers and have CSI admin privs to create a key
Unable to generate a Core Key via MOS
- I do not see a choice for the number of Cores I want to apply
- I can not create a key for a smaller number of Cores
- I get the message "Unable to Generate..." or "Try Again Later"
- I get the message "Wrong HW type"
Confirm the following
- Do you have the Admin privileges for the HW CSI associated with the ODA
- Check if you purchased the ODA but did not apply a Core Key within the first year
- Confirm you are using the SYSTEM serial number vs. the single server serial number (X3-2 and higher)
- Confirm that you have the proper CSI for the ODA - Do not use your database or SW license
- Confirm the HW type in MOS matches the one purchased.
- Confirm you have the correct ODA serial number ff you purchased or received more than one ODA at the same time
- If you have multiple ODAs confirm you are using correct ODA serial number and HW
- Was there a mistake made when manually entering a serial number or HW type during MOS registration?
- If you are trying to generate a smaller Core Key via MOS - This is not supported!
Unable to apply the Core Key on the ODA once generated via MOS
- The ILOM system_identifier is not completely populated on one or both nodes
- The ILOM system_identifier was altered or deleted on one or both nodes
- The Key was generated against the wrong HW type
- One or both of the ODA servers do not have a serial number
- One or both of the ODA servers have an incorrect serial number
The serial number problem was entered at the factory
The serial number was entered at MOS during registration
Additional Quick Tips
- Always copy to and apply the Core Key from the first node
- Set the permissions of the directory where the key will be applied to 777 - /tmp is a common location
- Give the key file a short name, generally no more than eight characters.
- Check the byte size of the key when created and after transferring to the first node of the ODA
- The byte size of the key should be 176 or 180 bytes
- The core key is created based on the SYSTEM identifier which must match on each of the two ODA servers (with the exception of V1)
Core Key Diagnostic Data Collection
-- What is needed to diagnose and fix the problem:
ODA Configuration information
What is the System Identifier on both nodes - Must match on both nodes*
# oakcli show server
# ipmitool -I open sunoem getval /X/system_identifier
# ipmitool -I open sunoem getval /System/serial_number
* Except for ODA V1
HW and Installation type: BM vs. Virtualization
# oakcli show env_hw -If 2.8 and higher
- or -
# fwupdate list sp_bios -If pre-2.8 but also ask if the problem is on a Bare Metal or Virtualization installation
Serial Number (HW dependent) used for CSI registration and Core Key Generation
BOTH servers must have the same shared System Identifier Serial number
and the values must match the expected format
ODA V2 and higher: X3-2, X4-2 or X5-2 HW
oakcli show server -- both nodes - This command may require a newer oakcli version than what you have and if so use the ipmitool
Better Details if you are having problems based on the serial_number which appears to be the same on both nodes
ipmitool sunoem cli "show /System" -- both nodes - You will want to review the following under Properties
...
serial_number -- Should match both nodes
component_model -- Should exist and be the same as the description in the 'system_identifier' field
component_serial_number -- This is unique for EACH node, but NOT used by MOS for generating the CORE Key
system_identifier -- This must exist AND match on both nodes AND must follow the EXACT format of Oracle Database Appliance + <HW Version> + System (shared) <serial number#>
e.g. system_identifier = Oracle Database Appliance X5-2 1234ABC007
Other methods to collect the same information BOTH nodes:
# ipmitool -I open sunoem getval /X/system_identifier
# /usr/sbin/dmidecode -t1
From ILOM
-> show /SP
-> show /System
ODA V1 -- HW X4370 M3
# /usr/sbin/dmidecode -t1 |grep Serial
MOS and Account Information
Screen shots of CSI#, Asset information, MOS information and MOS core key generation steps We need to confirm the CSI#, MOS account number, if the accounts show the ODA as assets and asset information
Screen shots of MOS steps
- CSI used
- Logging into MOS is successful (Skip to #2 if this succeeds) - if not add screenshot of error
- Once in MOS: confirm that Asset includes serial# and HW type - if not add screenshots of MOS steps #1 & #2, otherwise move to 3
- Key Generator is viewable and useable but broken during CORE count - Screenshot of #2 Plus the error while attempting to enter CORE count
- Key Generation allows Core Count but errors attempting to generate Key - Screenshot of error while attempting to generate the Key
- POST Key Generation
ODA MOS Core Count and Key Generation
Screen Shots of Key Application failures on the ODA MOS KEY GENERATION
- How many Cores are you trying to generate of _each_ of the two ODA servers?
- Are you able to generate the key, but failing when attempting to apply the key
- - if not add screenshots of MOS 3 & 4
- - Include the oakcli syntax used
- Key applies on one Server but not the other
- Key states wrong HW type or states Serial# is incorrect
- Other errors
Examples Of Data Collection
1) ODA Version Information
oakcli show version -detail -- Verifies ODA Version Used
-- Executed as root on both Nodes
Node 1
[root@oda1 ~]# oakcli show version -detail
Reading the metadata. It takes a while...
System Version Component Name Installed Version Supported Version
-------------- --------------- ------------------ -----------------
2.8.0.0.0
Controller 11.05.03.00 Up-to-date
Expander 0342 Up-to-date
SSD_SHARED E12B Up-to-date
HDD_LOCAL SA03 Up-to-date
HDD_SHARED 0B25 Up-to-date
ILOM 3.0.16.22.d r83408 Up-to-date
BIOS 12010311 Up-to-date
IPMI 1.8.10.5 Up-to-date
HMP 2.2.6.4 Up-to-date
OAK 2.8.0.0.0 Up-to-date
OEL 5.9 Up-to-date
GI_HOME 11.2.0.4.0 Up-to-date
DB_HOME {
[ OraDb11204_home3,O 11.2.0.4.0 Up-to-date
raDb11204_home1,OraD
b11204_home2 ]
[ OraDb11203_home1 ] 11.2.0.3.8(16902043, Up-to-date
17076717)
[ OraDb11203_home3,O 11.2.0.3.7(16619892, 11.2.0.3.8(16902043,
raDb11203_home4,OraD 16742216) 17076717)
b11203_home2,OraDb11
203_home5 ]
}
ASR 4.5 Up-to-date
Always run the same command on the Second Node
[root@oda2 ~]# oakcli show version -detail
Reading the metadata. It takes a while...
System Version Component Name Installed Version Supported Version
-------------- --------------- ------------------ -----------------
2.8.0.0.0
Controller 11.05.03.00 Up-to-date
Expander 0342 Up-to-date
SSD_SHARED E12B Up-to-date
HDD_LOCAL SA03 Up-to-date
HDD_SHARED 0B25 Up-to-date
ILOM 3.0.16.22.d r83408 Up-to-date
BIOS 12010311 Up-to-date
IPMI 1.8.10.5 Up-to-date
HMP 2.2.6.4 Up-to-date
OAK 2.8.0.0.0 Up-to-date
OEL 5.9 Up-to-date
GI_HOME 11.2.0.4.0 Up-to-date
DB_HOME {
[ OraDb11204_home3,O 11.2.0.4.0 Up-to-date
raDb11204_home1,OraD
b11204_home2 ]
[ OraDb11203_home3,O 11.2.0.3.7(16619892, 11.2.0.3.8(16902043,
raDb11203_home4,OraD 16742216) 17076717)
b11203_home2,OraDb11
203_home5 ]
[ OraDb11203_home1 ] 11.2.0.3.8(16902043, Up-to-date
17076717)
The Current ODA Core Count
How to determine if a Core Key exists or confirm the current core count
- Case 1 - No Key applied ( Default )
oakcli show core_config_key
Optional core_config_key is not applied on this machine yet!
- The above means that all physical cores are available until a Key is applied
Case 2 - The Key has been applied
oakcli show core_config_key
Host's serialnumber = 1234FMW123
Configured Cores = 16
Note: For virtualized configurations you do not create and apply a Core Key (default)
You can assign CPU Core counts within the VM Templates
If you are currently moving from a Bare Metal ODA configuration to a Virtualized configuation please refer to:
Doc ID 1559091.1 ODA (Oracle Database Appliance): How To Reset the license core keys before re-image to the Virtualized Platform option
2) ODA Hardware Information
oakcli show hw_env -- Both Nodes -- Only Usable for ODA version 2.8 and higher
-- Verifies HW type and Bare Metal if Virtualized
Example: ODA X3-2 using Virtualization
[root@oda1 ~]# oakcli show env_hw
VM-DOM0 ODA X3-2 -- VM indicates that this installation uses the Oracle Database Appliance Virtual Platform (ODAVP)
-- X3-2 confirms the HW platform version
Example: ODA V1 and Bare Metal
[root@oda2 ~]# oakcli show env_hw
BM ODA -- BM stands for Bare Metal
-- ODA with no other identifier implicitely confirms that this is the ODA HW Version V1
Helpful: fwupdate list sp_bios -- Both Nodes
-- Provides better HW detail
Example
V2 - X3-2 X4170 M3 (X4-2 has the same format)
[root@odax1 ~]# fwupdate list sp_bios
==================================================
SP + BIOS
==================================================
ID Product Name ILOM Version BIOS/OBP Version XML Support
--------------------------------- ------------------------------------------------------------------------
sp_bios SUN FIRE X4170 M3 v3.1.2.10.d r83372 17050100 N/A
V1 - X4370 M2 SERVER
[root@oda1 ~]# fwupdate list sp_bios
==================================================
SP + BIOS
==================================================
ID Product Name ILOM Version BIOS/OBP Version XML Support
----------------------------------------------------------------------------------------------------------
sp_bios SUN FIRE X4370 M2 SERVER v3.0.16.22.d r83408 12010311 N/A
3) SERIAL NUMBER
The CORE KEY is generated using the Serial Number for the ODA used.
There are two different types of serial numbers for the ODA: The SYSTEM serial number (one per ODA) and the individual Blade Serial numbers
There are unique methods to collect the serial number dependent on the HW platform used.
X3-2,X4-2 and higher use the SYSTEM serial Number which should always be the same on EACH server / blade.
For: X4-2 or X3-2 ONLY
Use the following ipmitool command exclusively on X4-2 X3-2
to get the SYSTEM (TLI) serial number for current HW:
Newer Non-V1 systems can use
oakcli show server
ipmitool -I open sunoem getval /X/system_identifier
On Node1
[root@oda1 ~]# ipmitool -I open sunoem getval /X/system_identifier
Target Value: Oracle Database Appliance X3-2 1234FM6789
On Node 2
[root@oda2 ~]# ipmitool -I open sunoem getval /X/system_identifier
Target Value: Oracle Database Appliance X3-2 1234FM6789
For: V1 ONLY
Use the following ipmitool command exclusively on the original ODA V1
to get each server serial number for V1 HW
On Node1
[root@oda1 ~]# /usr/sbin/dmidecode -t1 |grep Serial
Serial Number: 1234FMW4321
On Node 2
[root@oda2 ~]# /usr/sbin/dmidecode -t1 |grep Serial
Serial Number: 1138FMW001
SUPPLEMENTAL
Core Key Problems Quick Reference Matrix
Key Problem Source
MOS Account |
Key Generation |
ODA Key Application |
|
Symptom |
Possible Source |
Corrective Action |
HW Version |
For Support
|
Mos Account |
Key Generation |
ODA Key Application |
No |
Maybe |
Maybe |
|
Oakcli command fails |
- Using ODA Lite
- Deployment is not completed
- Using ODAVP and attempting from wrong domain
|
- ODA Lite uses odacli or odaadmcli commands
- Wait until ODA has been deployed before trying to set the Core Key
|
- ODA X6-2S X6-2MX6-2L
- Any ODA ha any version
|
|
MOS |
Generation |
Application |
Yes |
-- N / A -- |
-- N / A -- |
|
Unable to log into MOS |
- Are you using the proper Account?
- Confirm that the CSI has been registered for the ODA
- Confirm you are using the proper HW ODA CSI
- If you just purchased the ODA new confirm the account has been registered and it has been no more than 24-48 hours
- The CSI admin has not registered you yet for this CSI
- Data Entry or Password error during login
|
- Contact the Admin for the ODA HW account - Make sure the account is active
- Make sure you are using the proper CSI
especially if you have more than one ODA or multiple CSIs
- If this is a brand new purchase there is a potential latency of up to 48 Hours:
- Contact HUB via voice or SR to request assistance if over one business day to verify the registration is in progress
|
Any Version |
relatively rare - Most typically seen when
- Consultants attempt to register a key without the proper account privs.
- new MOS Oracle shops / users
Get screen shots plus mandatory diag Confirm ODA CSI via SR
|
MOS |
Generation |
Application |
Yes |
-- N / A -- |
-- N / A -- |
|
You are able to log into MOS
- but not finding the ODA as an asset
|
- Your are logged into the wrong CSI
- The CSI admin has not properly registered the ODA product
- The backend registration had a problem
- The account is new or has been recently transfered from a VAR
|
Confirm you MOS CSI and account Login information is correct
- Contact the Admin for the ODA HW account - Make sure the account is active
- Make sure you are using the proper CSI
especially if you have more than one ODA or multiple CSIs
- If this is a brand new purchase there is a potential latency of up to 48 Hours:
- Contact HUB via voice or SR to request assistance if over one business day to verify the registration is in progress
|
Any Version |
Very rare, | Usually not using the proper CSI |
MOS |
Generation |
Application |
Yes |
Yes |
-- N / A -- |
|
Logged into MOS Can see the ODA as an Asset
- The Key Generation Icon is missing or Greyed out
|
- The Account you have currently used to log into MOS does not have Admin privs
Intermittent problems with MOS Key generation
|
Logging into MOS does not give you the ability to create a Key
- Make sure you have or get ADMIN privs for this CSI / ODA (request this)
- Request that MOS CSI ADMIN generate the key if you cannot
- Contact HUB via voice or create a SR to request assistance if the problem continues to exist for more than one business day
- Some problems have been confirmed as MOS based
|
Any Version |
We have now seen this problem more than 2x with X4-2. It is difficult to determine of the problem is pure MOS or more unique to single accounts and ODAs Regardless--- Collect all diagnostic steps with screen shots being critical |
MOS |
Generation |
Application |
Yes |
Yes |
-- N / A -- |
|
Logged into MOS Can see the ODA as an Asset Key Generation is active Able to see the Core Key generation
- but nothing happens when attempting to create the Key (no error)
|
- The Core Key may have already been generated for the number of Cores specified
- Increase the number of Core Keys or as needed copy the existing key to use or reuse for the specific ODA asset
- Connection to tool has dropped
|
- Confirm the connection is still alive and has not timed out - Retry the connection and see if you fail before,during or after you attempt to create the key
- Retry the operation later (1 to 24 hrs)
- Error messages can be associated with known problems: Use this note to dig deeper
- if necessary collect all diagnostic information and open a SR
|
Any Version |
Farily rare, usually communications or MOS time outs|
|
MOS |
Generation |
Application |
Yes |
Yes |
-- N / A -- |
|
Logged into MOS Can see the ODA as an Asset Key Generation is active but shows the following error when attempting to generate the Key
|
|
Use the Diagnostic Collection local to the ODA and compare with the MOS CSI account information. Collect from both Nodes
- Confirm the HW was not incorrectly registered under the wrong HW type during the MOS account creation
- Confirm the correct serial Number for the product was used
- use ipmitool for X4-2 and X3-2 - use dmidecode for V1
- Contact HUB via voice or create a SR to request assistance if the problem continues to exist for more than one business day
|
Usually not a problem if using ODA V1
More likely to be found on X3-2
|
-Common problem due to certain time periods when HW defaulted to wrong HW type during MOS registration Including default HW being incorrect or Key Entry HW
-- These problem should all be fixed
|
MOS |
Generation |
Application |
Yes |
Yes |
-- N / A -- |
|
Logged into MOS Can see the ODA as an Asset Key Generation is active but shows the following error when attempting to generate the Key
- Unable to generate Key : Please try again later
|
- Confirm the connection to MOS is still alive and not timed out (possible client or MOS server problem)
- Confirm the MOS ODA core key tool is not offlined for updates or maintenance (Usually a HUB / MOS SR will confirm this if trying again later does not succeed)
|
If the problem is not obviously wrong due to verifiable HW / Account mismatches it may also be due to
- MOS information incorrect
- MOS site unavailable or being updated
- MOS outage or refresh
Use the Diagnostic Collection local to the ODA and compare with the MOS CSI account information. Collect from both Nodes ( Create SR with uploads )
|
Intermittent MOS problem independent of ODA Version
Fixed problem with X4-2
|
--- |
MOS |
Generation |
Application |
Maybe |
Maybe |
Yes |
|
Key Generated but error on ODA shows
- Errors "incorrect HW Type"
|
- Compare the HW information local to the box with MOS information to confirm that all matched. Check BOTH ODA servers
- Serial number proper and on both nodes
- System serial number used in X3-2 , X4-2
- oakcli show env_hw matches MOS
|
Usually due to problems with the MOS generated key not being correct If ALL checks appear as expected on BOTH nodes HW, serial number AND CSI information is the same for serial number, HW type then please create a SR with EEST / ODA appliance support |
Not likely with V1 |
These usually require internal interventionto Fix, However it may require HUB , ODA Dev or both --- Send an internal email to ODA groups |
MOS |
Generation |
Application |
No |
No |
Yes |
|
Key Generated Applies successfully on one Node
- Hangs On One or both nodes
|
- One node is down or communications are down
- OS Image or deployment was not completed on both nodes
- Patching / upgrade never completed on one node
- Password is not set properly for SSH
|
- Make sure both nodes are up and running
- Image was completed on both nodes
- No connectivity problems
- Password is set back to default for the operation
- SSH connection is possible between nodes (both ways)
|
Any Version |
--- |
MOS |
Generation |
Application |
No |
No |
Yes |
|
Key Generated
|
|
|
Any Version |
--- |
MOS |
Generation |
Application |
No |
No |
No |
|
Key generated and applied Confirmed Key and count using oakcli
- Core Count does not appear correct or functioning as expected
|
- Cores per Server confirmed using which query?
- Confused Cores per Server (s) vs. per ODA (2x)
- Instance Caging in place?
- Bios CPU cap in place
|
- See Docset for information on Core Count based on HW version. Queries will also be confirmed
- Check HW version and if Bare Metal or Virtualized
- Remove and BIOs or Instance caging Caps
|
Any Version |
--- |
|
Key generated but only applies on one of the two ODAs or fails during application. |
- Check for BANNER and SSH problems during Key Application
- Make sure that both nodes have the SAME SYSTEM identifier
- Confirm if more than one ODA was delivered or racked at the same time: ODAs are shipped in MATCHED Pairs = You can not mix and match ODA servers other than the specific matched pair
|
- Disable any banners for the duration of the core key application. Fix any SSH problems
- Compare serial numbers from oakcli show server commands for X3-2 and higher (except ODA lite)If a mother board was replaced on one of the nodes request HW confirm serial numbers are corrected to match.
|
|
|
- Unable to generate a Core Key Via MOS Actual underlying cause is 18189693 MOS 14.2: QA: ERROR WHEN GENERATING COREs KEY
The DBAppliance licensing feature now works with expired assets
INTERNAL PROBLEM DESCRIPTION:
The search for assets did not include expired assets
INTERNAL FIX DESCRIPTION:
Added parameter to include all derived_statuses to asset search
Fixed 1/2015
References
<NOTE:1559091.1> - ODA (Oracle Database Appliance): How To Reset the license core keys before re-image to the Virtualized Platform option
<BUG:18189693> - MOS 14.2: QA: ERROR WHEN GENERATING CORES KEY
<NOTE:1447093.1> - Oracle Database Appliance - Steps to Generate a Key via MOS to change your CORE Count and apply this Core Key
<BUG:20732508> - LNX64-121-CMT: SYSTEM_IDENTIFIER SHOULD BE NON-MODIFIABLE OR PROTECTED
<BUG:21417720> - ODA CORE KEY NOT APPLYING ON RE-IMAGED X4-2 12.1.2.3.0 SYSTEM_IDENTIFIER PROB
<BUG:20732508> - LNX64-121-CMT: SYSTEM_IDENTIFIER SHOULD BE NON-MODIFIABLE OR PROTECTED
<NOTE:2220572.1> - ODA: X6-2 Capacity-On-Demand : How To Change & Register CPU Cores For Single-Node ODA Lite X6-2(S,M,L) or the Dual-Node ODA HA X6-2
Attachments
This solution has no attachment