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
Replacing a failed boot disk
The replacement disk for a failed boot disk must have at least as much storage capacity as was in use on the disk being replaced. It must be large enough to accommodate all subdisks of the original disk at their current disk offsets.
To estimate the size of the replacement disk, use this command:
# vxprint [-g diskgroup] -st -e 'sd_disk="diskname"'
where diskname is the name of the disk that failed or the name of one of its mirrors.
The following is sample output from running this command:
# vxprint -g rtdg -st -e 'sd_disk="rtdg01"' Disk group: rtdg SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE ... sd rtdg01-01 swapvol-01 rtdg01 0 1045296 0 c0t0d0 ENA sd rtdg01-02 rootvol-01 rtdg01 1045296 16751952 0 c0t0d0 ENA
From the resulting output, add the DISKOFFS and LENGTH values for the last subdisk listed for the disk. This size is in 512-byte sectors. Divide this number by 2 for the size in kilobytes. In this example, the DISKOFFS and LENGTH values for the subdisk rtdg01-02 are 1,045,296 and 16,751,952, so the disk size is (1,045,296 + 16,751,952)/2, which equals 8,898,624 kilobytes or approximately 8.5 gigabytes.
Note:
Disk sizes reported by manufacturers usually represent the unformatted capacity of disks. Also, most manufacturers use the terms megabyte and gigabyte to mean a million (1,000,000) and a billion (1,000,000,000) bytes respectively, rather than the usual meaning of 1,048,576 and1,073,741,824 bytes.
To replace a failed boot disk:
- Boot the system from an alternate boot disk.
- Remove the association between the failing device and its disk name using the "Remove a disk for replacement" function of vxdiskadm.
See the vxdiskadm (1M) manual page.
- Shut down the system and replace the failed hardware.
- After rebooting from the alternate boot disk, use the vxdiskadm "Replace a failed or removed disk" menu item to notify VxVM that you have replaced the failed disk.
Warning:
If the replacement disk was previously an encapsulated root disk under VxVM control, select to reorganize the disk when prompted. Otherwise, the disk is left with an invalid VTOC that renders the system unbootable. Ensure that you have made at least one valid copy of any existing data on the disk.
- Use vxdiskadm to mirror the alternate boot disk to the replacement boot disk.
- When the volumes on the boot disk have been restored, shut down the system, and test that the system can be booted from the replacement boot disk.