This document describes common data that Cisco TAC would request for investigation of UCS related Service Requests.
You can substantially reduce the time taken for initial identification of the issue by attaching such data to the Service Request when it is opened
The absence of data collected at the time of an issue may make it impossible for Cisco TAC to provide a definitive explanation of why a particular issue occurred
This document assumes you have admin level access to the appropriate UCS GUI/CLI to generate the required Tech Support bundles
Cisco recommends that you have knowledge of these topics:
Cisco Unified Computing System (UCS) Manager
Cisco Unified Computing System (UCS) Manager Command Line Interface (CLI)
Cisco Integrated Management Controller (CIMC)
When should data be collected
Cisco generally advises to generate relevant data as soon as it is suspected TAC engagement may be desired/requested.
This is to avoid critical log files no longer covering the time of interest, typically seen in larger or rapidly changing environments, including where reboots of Fabric Interconnects have occurred
Cisco TAC would typically advise in the case of multiple Tech Supports being required that UCSM Tech Support is generated prior to Chassis or other Tech Support files, as it is the most time critical and also is the most time consuming to generate.
If you are not able to provide certain UCS Tech Supports due to known software defects or open Service Requests, please advise Cisco TAC.
What data should be collected
Other than Tech Support bundles, critical data about the problem that should be collected may include:
- Date/Time of Issue
- Affected Servers or Service Profiles
- Any errors seen at the time of issue, especially screenshots of any PSOD/BSOD/Kernel Panic screens
- Any changes performed at the time or in the recent past
- What actions, if any, had been performed to troubleshoot the issue or recover service
- OS Type and version
- VIC Driver versions i.e. ENIC/NENIC/FNIC versions
- RAID Controller Driver versions
- Driver of any additional HBA/NIC's in use
- Information on any suspected trigger conditions such as load, nightly backup/maintenance tasks etc.
- Basic overview of Topology, such as upstream Ethernet or SAN switches, Storage Arrays etc.
- Upload any core files shown in UCS Manager around the time of the issue
However, any other data you believe is an important factor in the situation can also be included
What Tech Support bundles should be collected
Typically Cisco TAC would request the following Tech Support bundles as a starting point:
UCS B-Series and S-Series (Integrated)
UCSM Tech Support
Chassis Tech Support covering affected servers.
UCS HX-Series or C-Series (Integrated)
UCSM Tech Support
FEX Tech Support covering affected servers (if applicable)
Rack Server Tech Support
UCS C-Series (Standalone) or UCS S-Series (Standalone)
CIMC Tech Support
Providing Tech Supports from similar but unaffected servers may also be useful
Operating System Tech Support Data
In situations where you believe that OS Tech Support data may be useful for Cisco TAC analysis in the case of interoperability issues, the following can be provided as a starting point:
Red Hat Linux based products
SUSE Linux based products
Application and System Event Logs in evt or evtx file formats
Output of 'systeminfo' or similar
Other considerations when collecting UCS Tech Support bundles
Where possible you should not combine multiple Tech Support bundles into a single larger file
UCS Tech Supports are already extensively compressed, despite the .tar extension of the final file.
However, if other large data files are not compressed, compressing using standard formats (zip/gz/bz2/7z etc.) is recommended.
Unless explicitly instructed or absolutely required, please avoid usage of the 'Exclude Commands' option in Tech Support files or supplying ucsm-mgmt rather than full UCSM Tech Support bundles
If a blade or rack server has experienced a PSOD/BSOD/Kernel Panic, please reboot the server using the Reset options in UCSM/CIMC or KVM, not Shutdown then Boot of the server.
This causes extra information to be generated for troubleshooting which is then included in Tech Support bundles, whereas shutting down the server causes this data to be lost.