VTL - SAN Client Cannot See Virtual Library or Drives (Client Connectivity)

Asset ID:	1-72-1133104.1
Update Date:	2011-08-02
Keywords:

Solution Type Problem Resolution Sure

Solution 1133104.1 : VTL - SAN Client Cannot See Virtual Library or Drives (Client Connectivity)

Applies to:

Sun StorageTek VTL Value System - Version: 1.0 - Build 1323 to 1.0 - Build 1323 - Release: 1.0 to 1.0
Sun StorageTek VTL Storage Appliance - Version: 4.0 - Build 1221 to 4.0 - Build 1221   [Release: 4.0 to 4.0]
Sun StorageTek VTL Plus Storage Appliance - Version: 1.0 - Build 1323 to 2.0 - Build 1656   [Release: 1.0 to 2.0]
Sun StorageTek VTL Prime System - Version: 1.0 - Build 1813 to 1.1 - Build 2076   [Release: 1.0 to 1.0]
Information in this document applies to any platform.
.
***Checked for relevance on 29-07-2011*** (dd-mm-yyyy)

Symptoms

SAN Client can not see or discover new virtual drives
SAN Client can not see or discover new virtual library
SAN Client lost visibility to virtual drives
Troubleshooting SAN Client connectivity issues

Cause

Most common causes:

Client not defined in VTL console.
Client not zoned to VTL
SAN connection between VTL and switch failed
SAN connection between Client and switch failed.

Solution

There are multiple reasons that a VTL SAN client (backup application server) cannot see it's virtual drives and/or library. The following are some steps to check/verify:

1. Has anything has been changed in the environment recently?
instead of using the shotgun approach and checking everything, the answer here may lead you in the right direction and resolve the issue quickly.

2. Check SAN Client configuration
Make sure the backup application client (SAN Client) has been defined in VTL console under SAN Clients, and that the client has been assigned the virtual library and drives. For details on creating and assigning SAN Client systems, see the VTL User Guide.

3. Check VTL to SAN switch connectivity.
In the VTL Console, check the SNS table (Physical resources>Storage HBAs). The VTL Target ports are the ones with the small green "T" icon.
If there are not any entries you have a failure between the VTL and the switch.
- Have customer/local field support check if they can see the VTL from the switch. And check the switch logs, cables, SFPs.
- Check the VTL messages log for scsi errors which may indicate a faulty SFP, cable or HBA.

4. Check SAN Client to SAN switch connectivity
In the VTL Console, check the SNS table. If you only see one entry (the VTL port) you have a failure between the switch and the client, or the switch is not properly zoned to the VTL. Have the customer diagnose diagnose this from the switch.

Many times the client has logged out of the switch for various reasons, and doing a rescan/discover of virtual devices on the client, resetting the switch port, or rebooting the client server, will force a the client to log back into the switch.

5. Check for stale connections
If there are two entries listed (one for VTL port and one for client port), but the date/time stamp under Adapter/Client Info is stale (old), then may just need to reset the target port (force log in to switch). Contact VTL Level2 support for assistance with this. Reboot of VTL and the client will accomplish this as well.

Internal support see doc id 1344772.11 for port reset commands

6. Check with client server and/or backup application vendor for configuration, compatibility issues
If problem is not resolved by any of the above and is determined to be a client side issue, have customer escalate/open support case with server and/or backup application vendor.

References

<NOTE:1344772.1> - VTL - How to re-establish or reset (force lip) VTL target ports via commandline

Attachments

This solution has no attachment