Hi Scott,
It is very late here so this will be brief based on first impressions.
This :
Opening /dev/sg/c0tw500110a0008c72fal1
user command failed, may be timeout, scsi_pkt.us_reason = 3
user command failed, may be timeout, scsi_pkt.us_reason = 3
mode_sense ioctl() failed: Error 0
Shows that that there is an issue connecting to the robot on path /dev/sg/c0tw500110a0008c72fal1, either a connectivity issue, or the robot is not responding:
Is it possible the path has changed somehow ?
This is almost certainly not a NBU issue, though, if the path has changed reconfig on NBU would be required.
Step to troubleshoot.
1. Prove that the OS can see the library.
cfadm -al -o show_FCP_dev
Do you see the changer listed ?
(Sometimes cfgadm won'y show anything, if so you'll need to find another command to show the devices that are san connected. HBA vendors usually provide a utility, luxadm is another solaris command that can be used).
If not, this proves the issue is between the library and the OS.
If you can see the library in this step, then scan should see it and a rebuild of the SG driver will fix (*)
This should work ...
modunload -i $(echo $(modinfo |grep "sg (SCSA" |awk '{print $1}'))
mv /kernel/drv/sg.conf /kernel/drv/sg.conf.old
cd /usr/openv/volmgr/bin/driver
mv sg.links sg.links.safe
mv sg.conf sg.conf.safe
../sg.build all
/usr/openv/volmgr/bin/driver/sg.install
(*) If it still doesn't work, looks like a library issue, it is perfectly possible to get visibility from the OS, but the library fails to respond to other commands.
Note. When you run scan, providing the sg driver is correct all that it does is send a scsi command to the library. If this fails, the issue will be between the library and the OS - NBU is not involved (scan does not run any NBU commands). I've seen san issues cause symptoms like this, faulty HBAs or HBA drivers/ firmware and robot faults. I've never seen NBU cause this.
A good test is this :
/usr/openv/volmgr/bin/scsi_command -d <path to library>
So
/usr/openv/volmgr/bin/scsi_command -d /dev/sg/c0tw500110a0008c72fal1
This should return the model.
Again, we provide the scsi_command, but this is only sending a scsi_command, absolutley no NBU involved which helps to show where the issue is.
Hope this helps,
Martin