Veritas InfoScale™ 7.3.1 Troubleshooting Guide - Solaris
- Introduction
- Section I. Troubleshooting Veritas File System
- Section II. Troubleshooting Veritas Volume Manager
- Recovering from hardware failure
- Failures on RAID-5 volumes
- Recovery from failure of a DCO volume
- Recovering from instant snapshot failure
- Recovering from failed vxresize operation
- Recovering from boot disk failure
- Hot-relocation and boot disk failure
- Recovery from boot failure
- Repair of root or /usr file systems on mirrored volumes
- Replacement of boot disks
- Recovery by reinstallation
- Managing commands, tasks, and transactions
- Backing up and restoring disk group configurations
- Troubleshooting issues with importing disk groups
- Recovering from CDS errors
- Logging and error messages
- Troubleshooting Veritas Volume Replicator
- Recovery from configuration errors
- Errors during an RLINK attach
- Errors during modification of an RVG
- Recovery on the Primary or Secondary
- Recovering from Primary data volume error
- Primary SRL volume error cleanup and restart
- Primary SRL header error cleanup and recovery
- Secondary data volume error cleanup and recovery
- Troubleshooting issues in cloud deployments
- Recovering from hardware failure
- Section III. Troubleshooting Dynamic Multi-Pathing
- Section IV. Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting CFS
- Troubleshooting fenced configurations
- Troubleshooting Cluster Volume Manager in Veritas InfoScale products clusters
- Troubleshooting Storage Foundation Cluster File System High Availability
- Section V. Troubleshooting Cluster Server
- Troubleshooting and recovery for VCS
- VCS message logging
- Gathering VCS information for support analysis
- Troubleshooting the VCS engine
- Troubleshooting Low Latency Transport (LLT)
- Troubleshooting Group Membership Services/Atomic Broadcast (GAB)
- Troubleshooting VCS startup
- Troubleshooting service groups
- Troubleshooting resources
- Troubleshooting I/O fencing
- System panics to prevent potential data corruption
- Fencing startup reports preexisting split-brain
- Troubleshooting CP server
- Troubleshooting server-based fencing on the Veritas InfoScale products cluster nodes
- Issues during online migration of coordination points
- Troubleshooting notification
- Troubleshooting and recovery for global clusters
- Troubleshooting licensing
- Licensing error messages
- VCS message logging
- Troubleshooting and recovery for VCS
- Section VI. Troubleshooting SFDB
About collecting application and daemon core data for debugging
If a Storage Foundation application or daemon encounters a problem, it may produce a core file. The vxgetcore script lets you efficiently collect the core file, binary file, library files, and any related debugging information and generate a tar file. You can then send the tar file to Veritas Technical Support for analysis.
You can run vxgetcore in the following ways:
The easiest way to run vxgetcore is with the -a (auto-find) option. You do not need to know the location of the core file or related data. vxgetcore locates the latest core file in the current directory. If there is no core file in the current directory, vxgetcore searches for a list of probable directories.
See Letting vxgetcore find debugging data automatically (the easiest method).
If you know the path to the core file (and optionally the binary file), you can specify them on the command line.
See Running vxgetcore when you know the location of the core file.
You can run vxgetcore without any options, and the script prompts you for all the information it needs.
When you work with vxgetcore, keep in mind the following:
vxgetcore is contained in the VRTSspt support package, which is a collection of tools to analyze and troubleshoot systems. When you install VRTSspt, the vxgetcore script is installed on the path /
opt/VRTSspt/vxgetcore/
.Before you run vxgetcore, contact Veritas Technical Support and get a case ID for your issue.
If you know the case number before you run the script, you can specify it on the command line. Getting the case ID first saves you time later. When you send the tar file to Veritas for analysis, the tar file name includes a case number. This approach is faster than generating the file, getting the case ID, and renaming the file later.
You do not have to analyze or work with the tar file vxgetcore generates.
Make sure that the file name includes the case ID, and FTP the file to your local FTP site.
For the latest information on vxgetcore, see the
README.vxgetcore
file at/opt/VRTSspt/vxgetcore/
.