How to display service tag and resolve service tag issues on x86 systems

Asset ID:	1-71-1360133.1
Update Date:	2011-09-22
Keywords:

Solution Type Technical Instruction Sure

Solution 1360133.1 : How to display service tag and resolve service tag issues on x86 systems

Applies to:

Sun Blade X8450 Server Module - Version: Not Applicable and later   [Release: N/A and later ]
Sun Fire X2270 Server - Version: Not Applicable and later    [Release: N/A and later]
Sun Fire X4140 Server - Version: Not Applicable and later    [Release: N/A and later]
Sun Fire X4600 Server - Version: Not Applicable and later    [Release: N/A and later]
Sun Blade X6270 Server Module - Version: Not Applicable and later    [Release: N/A and later]
Information in this document applies to any platform.

Goal

The purpose of this document is to show you how to display the service tag and resolve service tag issues on x86 systems

Solution

Service tag is a mechanism to store and report serial number and other important product data from the x86 system. A service tag enables automatic discovery of systems, software, and services (gear). A service tag uniquely identifies each tagged piece of gear, and allows information about the gear to be shared over a local network in a standard XML format.

Service tag is used by applications such as ASR (Auto Service Request) to get information about the x86 system. ASR uses the ILOM (Integrated Lights Out Management) service tag to retrieve the entitlement serial number as well as the product type. The product type is contained in the product_name field of the service tag. The ILOM software on x86 systems sends a SNMP trap to a host running the ASR Manager, and in turn that host sends the trap to Oracle's backend for processing and case generation as required.

Sun Service Tags:

Do not run in the background and are only used when queried
Have a small footprint (about 100 kilobytes)
Do not contain any personal information
Do not automatically collect or send any information to Oracle
Can be configured for discovery per gear, TCP listener or be disabled altogether
Can be used by the system administrator to help register new equipment with Oracle
Can, with the system administrator's permission, be used by Oracle service to aid in troubleshooting

The service tag information shared with Oracle is used solely to identify Oracle gear and better
support Oracle customers. Registration data is only collected when the system administrator
requests gear discovery.

More information about service tags can be found at:
Service Tag Wiki.

To troubleshoot Service tag issues, look at the [email protected] file that is collected in the ILOM snapshot. If there are duplicate entries in the XML file, the can cause the port on which the Service tag daemon is running on the ILOM to malfunction. ASR consequently may not be able to reach the port if it indicates that the service tag port is unavailable.

The stlistener and stdiscover processes running on the ILOM are involved in retrieving the service tag information for the asset. These processes should be running on the ILOM service processor. If you notice duplicate entries in the servicetag.xml file, no or bad data will be pulled up and ASR activation will fail no matter how many times you disable and re-enable service tags. It is therefore important to ensure that the information shown in the servicetag.xml file is correct and free of any malformed entries.

If you notice malformed entries in the servicetag.xml file, engage Oracle Service. An Oracle Service Engineer can log into the Service Processor using the 'sunservice' account and:

"rm /conf/servicetag.xml" (in ILOM 2.0 releases)
"rm /persist/servicetag.xml" (in ILOM 3.0 releases)

followed by:

"reset /SP"

and Service tag will be recreated upon boot up.

If the SP does not restart, then "/etc/init.d/stlistener restart" maybe necessary as well.

A properly defined servicetag.xml file would look like the one below.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE registry SYSTEM "/usr/local/lib/servicetags/servicetag.dtd">
<registry urn="urn:st:0c647c26-1dd2-11b2-b5a7-000020017f00" version="1.0">
<service_tag>
<instance_urn>urn:st:0ca806b2-1dd2-11b2-b923-000020017f00</instance_urn>
<product_name>SUN FIRE X4640</product_name>
<product_version/>
<product_urn>602-4891-01-Q6</product_urn>
<product_parent_urn>none</product_parent_urn><
product_parent>none</product_parent>
<product_defined_inst_id>0942AMP012</product_defined_inst_id>
<product_vendor>Sun</product_vendor>
<platform_arch>X64</platform_arch>
<timestamp>1970-01-01 00:21:17 GMT</timestamp>
<container>0942AMP012</container>
<source>ILOM 3.0.3.31</source>
<installer_uid>0</installer_uid>
</service_tag>

For Service Tags retrieved from ILOM, the ASR Manager extracts the serial number from the <product_defined_inst_id>. Prior to ILOM 3.0, the ILOM Service Tag contained no other field that included the serial number. Beginning with ILOM 3.0, a <serial_number> field was added to the ILOM Service Tag that also contains the serial number.

It is therefore important to ensure that the Service tag <product_defined_inst_id> matches the /SYS product_serial_number seen on the ILOM using the relevant 'show' command for the platform.

On a Sun Blade 6000 chassis, the product serial number can be obtained by:

-> show /SYS/MIDPLANE/

/SYS/MIDPLANE
   Targets:

   Properties:
       type = Chassis
       ipmi_name = MIDPLANE
       product_name = SUN BLADE 6000 MODULAR SYSTEM
       product_part_number = 541-1983-07
       product_serial_number = 0914ALEA97
       product_manufacturer = Oracle Corporation
       fru_name = SUN BLADE 6000 MODULAR SYSTEM
       fru_part_number = 501-7376-03
       fru_serial_number = 1005LCB-0907YB09RF

-> show /SYS
..
Properties:
      type = Host System
      product_name = SUN FIRE X4170/X4270/X4275 SERVER
      product_part_number = 602-4726-01
      product_serial_number = 0851CNG011
      product_version = (none)
      product_manufacturer = SUN MICROSYSTEMS
      fault_state = OK
      clear_fault_action = (none)
      power_state = On

Not having the correct product_serial_number in the <product_defined_inst_id> will break ASR (Automated Service Request). To "activate" an asset, the ASR Manager retrieves the Service Tag and extracts the serial number which is automatically compared to the entitled serial numbers in Oracle's database. If there is no match, the activation fails.

Running:

show /SP/services/servicetag

on the ILOM will display Service Tag configured on the ILOM.

-> show /SP/services/servicetag
   Targets:

   Properties:
    product_urn = urn:uuid:c15f7881-216e-11db-a023-080020a9ed93
    state = enabled

-> show /CMM/services/servicetag servicetag_urn

   /CMM/services/servicetag
   Properties:
    servicetag_urn = urn:uuid:f2ef019c-d283-11db-9135-080020a9ed93

Service Tags may be configured and enabled on host O/Ses like OEL (Oracle Enterprise Linux), Solaris, and Windows by following the instructions in the Oracle Hardware Installation Assistant User's Guide for x86 Servers.

On Solaris, we would install Service Tools Bundle (STB) which is a tool set that helps ASR obtain required information from each ASR system.

Download the latest Oracle Service Tool Bundle (STB) software ( see <Document: 1153444.1> ).

To confirm that STB is installed correctly on your host OS, and that it is reporting your system’s
serial number correctly, run:

/opt/SUNWsneep/bin/sneep -a

If the serial number for your system is not displayed, run the command below to
set the serial number. Keep in mind that the definitive source for the actual serial
number is on the chassis of your system. It should also be the same in the My
Oracle Support database, as described in "Review Assets in My Oracle Support"
on page 2-2.

/opt/SUNWsneep/bin/sneep -s [serial_number]

More information on sneep can be found at Sneep Wiki as well as the Sun Auto Service Request for Systems User Guide.

Run the following command on your host O/S to be sure that Service Tools Bundle (STB) is reporting your system attributes correctly: stclient -E. You can view the serial number in the following URL:

http://<Agent ipAddress>:6481/stv1/agent/

Be sure that the following attributes are reporting as indicated on your host:

<agent_version> must be 5.2 or above
<system> must be SunOS (For Solaris)
<platform> must be your platform type
<serial_number> must be the serial number of your system
<product_name> must be Solaris Operating System

If unable to contact Service Tags on the asset, please check if Service Tags is installed, running, and network accessible. This problem means that ASR activation will fail during Service Tags discovery. The issue can be either Service Tags is not installed on the ASR asset or is installed but not running. Also the issue can be network connectivity between ASR and the ASR asset.

Action: Do the following checks:

Check if Service Tags is installed and running on an ASR asset; use the following command:

# stclient -x

This command should return the Service Tags in xml format. If you cannot run this
command, either Service Tags is not installed or not online.

Check if the Service Tags services are installed and online, use the following command:

# svcs | grep reg

The results should be similar to the following example:

online Aug_23 svc:/application/stosreg:default
online Aug_23 svc:/application/sthwreg:default

If you cannot find these services, it means Service Tags is not installed on the ASR asset.

If the Service Tags services are online, check if psncollector is online; use the following command:

# svcs | grep psncollector

The results should be similar to the following example:

online Sep_09 svc:/application/psncollector:default

Make sure that there are no TCP Wrappers installed on the ASR asset to prevent any service tags discovery issues run:

wget http://<>:6481/stv1/agent/

from the SASM machine to verify any connectivity issues.

If there are TCP wrappers installed on the ASR asset, edit /etc/hosts.allowon the asset by adding: in.stlisten:<SASM host name>

If you have Service Tags correctly configured enabled on the host O/S, your system attributes will be identified correctly and the monitoring infrastructure can detect and report issues on the host O/S accurately to Oracle.

Attachments

This solution has no attachment