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
Verifying the metered or forecasted values for CPU, Mem, and Swap
This section lists commands for verifying or troubleshooting the metered and forecast data for the parameters metered, such as CPU, Mem, and Swap.
The VCS HostMonitor agent stores metered available capacity values for CPU, Mem, and Swap in absolute values in MHz, MB, and MB units respectively in a respective statlog database. The database files are present in /opt/VRTSvcs/stats. The primary database files are .vcs_host_stats.data and .vcs_host_stats.index. The other files present are used for archival purposes.
The HostMonitor agent uses statlog to get the forecast of available capacity and updates the system attribute HostAvailableForecast in the local system.
To gather the data when VCS is running, perform the following steps:
- Stop the HostMonitor agent and restart it after you complete troubleshooting, thus letting you verify the auto-populated value for the system attribute HostAvailableForecast.
- Copy the following statlog database files to a different location.
/var/VRTSvcs/stats/.vcs_host_stats.data
/var/VRTSvcs/stats/.vcs_host_stats.index
- Save the HostAvailableForecast values for comparison.
- Now you can restart the HostMonitor agent.
- Gather the data as follows:
To view the metered data, run the following command
# /opt/VRTSvcs/bin/vcsstatlog --dump /var/VRTSvcs/stats/copied_vcs_host_stats
To get the forecasted available capacity for CPU, Mem, and Swap for a system in cluster, run the following command on the system on which you copied the statlog database:
# /opt/VRTSvcs/bin/vcsstatlog --shell --load \ /var/VRTSvcs/stats/copied_vcs_host_stats --names CPU --holts \ --npred 1 --csv # /opt/VRTSvcs/bin/vcsstatlog --shell --load \ /var/VRTSvcs/stats/copied_vcs_host_stats --names Mem --holts \ --npred 1 --csv # /opt/VRTSvcs/bin/vcsstatlog --shell --load \ /var/VRTSvcs/stats/copied_vcs_host_stats --names Swap --holts \ --npred 1 --csv