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
- About recovery from hardware failure
- Listing unstartable volumes
- Displaying volume and plex states
- The plex state cycle
- Recovering an unstartable mirrored volume
- Recovering an unstartable volume with a disabled plex in the RECOVER state
- Forcibly restarting a disabled volume
- Clearing the failing flag on a disk
- Reattaching failed disks
- Recovering from a failed plex attach or synchronization operation
- Failures on RAID-5 volumes
- Recovering from an incomplete disk group move
- Restarting volumes after recovery when some nodes in the cluster become unavailable
- Recovery from failure of a DCO volume
- Recovering from instant snapshot failure
- Recovering from the failure of vxsnap prepare
- Recovering from the failure of vxsnap make for full-sized instant snapshots
- Recovering from the failure of vxsnap make for break-off instant snapshots
- Recovering from the failure of vxsnap make for space-optimized instant snapshots
- Recovering from the failure of vxsnap restore
- Recovering from the failure of vxsnap refresh
- Recovering from copy-on-write failure
- Recovering from I/O errors during resynchronization
- Recovering from I/O failure on a DCO volume
- Recovering from failure of vxsnap upgrade of instant snap data change objects (DCOs)
- Recovering from failed vxresize operation
- Recovering from boot disk failure
- VxVM and boot disk failure
- Possible root, swap, and usr configurations
- Booting from an alternate boot disk on Solaris SPARC systems
- The boot process on Solaris SPARC systems
- 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 RLINK connect problems
- Recovery from configuration errors
- Errors during an RLINK attach
- Errors during modification of an RVG
- Recovery on the Primary or Secondary
- About recovery from a Primary-host crash
- Recovering from Primary data volume error
- Primary SRL volume error cleanup and restart
- Primary SRL volume error at reboot
- Primary SRL volume overflow recovery
- Primary SRL header error cleanup and recovery
- Secondary data volume error cleanup and recovery
- Secondary SRL volume error cleanup and recovery
- Secondary SRL header error cleanup and recovery
- Secondary SRL header error at reboot
- 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
- About troubleshooting Storage Foundation Cluster File System High Availability
- Troubleshooting CFS
- Troubleshooting fenced configurations
- Troubleshooting Cluster Volume Manager in Veritas InfoScale products clusters
- CVM group is not online after adding a node to the Veritas InfoScale products cluster
- Shared disk group cannot be imported in Veritas InfoScale products cluster
- Unable to start CVM in Veritas InfoScale products cluster
- Removing preexisting keys
- CVMVolDg not online even though CVMCluster is online in Veritas InfoScale products cluster
- Shared disks not visible in Veritas InfoScale products cluster
- Troubleshooting Storage Foundation Cluster File System High Availability
- Section V. Troubleshooting Cluster Server
- Troubleshooting and recovery for VCS
- VCS message logging
- Log unification of VCS agent's entry points
- Enhancing First Failure Data Capture (FFDC) to troubleshoot VCS resource's unexpected behavior
- GAB message logging
- Enabling debug logs for agents
- Enabling debug logs for IMF
- Enabling debug logs for the VCS engine
- About debug log tags usage
- Gathering VCS information for support analysis
- Gathering LLT and GAB information for support analysis
- Gathering IMF information for support analysis
- Message catalogs
- Troubleshooting the VCS engine
- Troubleshooting Low Latency Transport (LLT)
- Troubleshooting Group Membership Services/Atomic Broadcast (GAB)
- Troubleshooting VCS startup
- Troubleshooting Intelligent Monitoring Framework (IMF)
- Troubleshooting service groups
- VCS does not automatically start service group
- System is not in RUNNING state
- Service group not configured to run on the system
- Service group not configured to autostart
- Service group is frozen
- Failover service group is online on another system
- A critical resource faulted
- Service group autodisabled
- Service group is waiting for the resource to be brought online/taken offline
- Service group is waiting for a dependency to be met.
- Service group not fully probed.
- Service group does not fail over to the forecasted system
- Service group does not fail over to the BiggestAvailable system even if FailOverPolicy is set to BiggestAvailable
- Restoring metering database from backup taken by VCS
- Initialization of metering database fails
- Troubleshooting resources
- Troubleshooting I/O fencing
- Node is unable to join cluster while another node is being ejected
- The vxfentsthdw utility fails when SCSI TEST UNIT READY command fails
- Manually removing existing keys from SCSI-3 disks
- System panics to prevent potential data corruption
- Cluster ID on the I/O fencing key of coordinator disk does not match the local cluster's ID
- Fencing startup reports preexisting split-brain
- Registered keys are lost on the coordinator disks
- Replacing defective disks when the cluster is offline
- The vxfenswap utility exits if rcp or scp commands are not functional
- 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 the steward process
- Troubleshooting licensing
- Validating license keys
- Licensing error messages
- [Licensing] Insufficient memory to perform operation
- [Licensing] No valid VCS license keys were found
- [Licensing] Unable to find a valid base VCS license key
- [Licensing] License key cannot be used on this OS platform
- [Licensing] VCS evaluation period has expired
- [Licensing] License key can not be used on this system
- [Licensing] Unable to initialize the licensing framework
- [Licensing] QuickStart is not supported in this release
- [Licensing] Your evaluation period for the feature has expired. This feature will not be enabled the next time VCS starts
- Verifying the metered or forecasted values for CPU, Mem, and Swap
- VCS message logging
- Troubleshooting and recovery for VCS
- Section VI. Troubleshooting SFDB
In an Azure environment, exporting a disk for Flexible Storage Sharing (FSS) may fail with "Disk not supported for FSS operation" error
For Flexible Storage Sharing, you must first export all the non-shared disks for network sharing. If your deployment setup involves JBOD type of disks, you may notice the following while exporting the non-shared disks:
The disk export operation fails with the "Disk not supported for FSS operation" error
# vxdisk export DiskName
VxVM vxdisk ERROR V-5-1-531 Device DiskName: export failed: Disk not supported for FSS operations
The checkfss disk command fails with the "Disk not valid for FSS operation" error
# vxddladm checkfss DiskName
VxVM vxddladm INFO V-5-1-18714 DiskName is not a valid disk for FSS operation
This issue occurs if a JBOD definition is not added to the disks.
Workaround:
Before exporting a disk for network sharing, add a JBOD definition on the disk.
Note:
You can add a JBOD definition to a disk only if the disk SCSI inquiry supports a unique serial number. You cannot export a disk for network sharing, if the disk's SCSI inquiry fails to have a unique serial number.
To add a JBOD definition to a disk, perform the following steps:
- Run a query on the standard disk pages (0, 0x80, and 0x83) to find the available unique serial number.
For page 0:
# /etc/vx/diag.d/vxscsiinq -d /dev/vx/rdmp/DiskName
For page 0x80:
# /etc/vx/diag.d/vxscsiinq -d -e 1 -p 0x80 /dev/vx/rdmp/DiskName
For page 0x83
# /etc/vx/diag.d/vxscsiinq -d -e 1 -p 0x83 /dev/vx/rdmp/DiskName
Following is a sample output of the command for page number 0x83 that contains the unique serial number.
------- Identifier Descriptor 1 ------- ID type : 0x1 (T10 vendor ID based) Protocol Identifier : 0x0 Code set : 0x1 PIV : 0x0 Association : 0x0 Length : 0x18 Data : 4d5346542020202069c0ae2f82ab294b834866ff... /dev/vx/rdmp/DiskName: Raw data size 32 Bytes: 0 - 7 0x00 0x83 0x00 0x1c 0x01 0x01 0x00 0x18 ........ Bytes: 8 - 15 0x4d 0x53 0x46 0x54 0x20 0x20 0x20 0x20 MSFT Bytes: 16 - 23 0x69 0xc0 0xae 0x2f 0x82 0xab 0x29 0x4b i../..)K Bytes: 24 - 31 0x83 0x48 0x66 0xff 0x1d 0xd3 0xf5 0xcb .Hf..... - Note the following values from the command output in step 1:
opcode= 0x12 (18) (This is a standard opcode)
pagecode= page number that contains the unique serial number (for example, 083)
offset= byte offset where the serial number starts (For example, in the output here the offset value is 8)
length= length of the unique serial number that is provided in the Length field (24 or 0x18)
- Add JBOD definition.
# vxddladm addjbod vid=vendorid serialnum=opcode/pagecode/offset/length
For example, # vxddladm addjbod vid=MSFT serialnum=18/083/8/0x18
- Scan disks.
# vxdisk scandisks
- Verify if the JBOD definition has been added sucessfully.
# vxddladm checkfss DiskName
The command output displays a confirmation message.