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
Unrelocation of subdisks to a replacement boot disk
When a boot disk is encapsulated, the root file system and other system areas, such as the swap partition, are made into volumes. VxVM creates a private region using part of the existing swap area, which is usually located in the middle of the disk. However, when a disk is initialized as a VM disk, VxVM creates the private region at the beginning of the disk.
If a mirrored encapsulated boot disk fails, hot-relocation creates new copies of its subdisks on a spare disk. The name of the disk that failed and the offsets of its component subdisks are stored in the subdisk records as part of this process. After the failed boot disk is replaced with one that has the same storage capacity, it is "initialized" and added back to the disk group. vxunreloc can be run to move all the subdisks back to the disk. However, the difference of the disk layout between an initialized disk and an encapsulated disk affects the way the offset into a disk is calculated for each unrelocated subdisk. Use the -f option to vxunreloc to move the subdisks to the disk, but not to the same offsets. For this to be successful, the replacement disk should be at least 2 megabytes larger than the original boot disk.
vxunreloc makes the new disk bootable after it moves all the subdisks to the disk.
The system dump device is usually configured to be the swap partition of the root disk. Whenever a swap subdisk is moved (by hot-relocation, or using vxunreloc) from one disk to another, the dump device must be re-configured on the new disk.
You can use the dumpadm command to view and set the dump device.
See the dumpadm(1M) manual page.