Table Of Contents

Troubleshooting SAN Device Virtualization

Overview

Initial Troubleshooting Checklist

Debugging and Verifying SDV Configuration Using the CLI

SDV Limitations and Restrictions

SDV Issues

SDV Commit Fails

SDV Commit Partially Fails

Host Cannot Locate Disk

SDV Merge Fails When ISL Comes Up

Zone Activation Fails in a SDV Zone

Troubleshooting SAN Device Virtualization

---

This chapter describes how to troubleshoot and resolve SAN device virtualization (SDV) configuration issues in the Cisco MDS 9000 Family of multilayer directors and fabric switches. It includes the following sections:

•Overview

•Initial Troubleshooting Checklist

•SDV Issues

Overview

With Cisco SDV, you can create virtual devices that represent physical end-devices. The SAN devices that are virtualized can be either initiators or targets. Virtualization of SAN devices accelerates swapout or failover to a replacement disk array, and it also minimizes downtime when replacing host bus adapters (HBAs) or when re-hosting an application on a different server.

Troubleshooting SDV involves checking the configuration of virtual devices, domain IDs, and zone sets. Configuration problems with SDV can prevent devices from communicating properly.

---

Note SDV is a distributed service and uses CFS (Cisco Fabric Services) distribution to synchronize the databases.

---

Initial Troubleshooting Checklist

Begin troubleshooting SDV issues by checking the following issues:

Checklist	Check off
Verify licensing requirements. See Cisco MDS 9000 Family Fabric Manager Configuration Guide.
Enable SDV on all the relevant switches.
Configure the virtual devices (with or without a persistent FC ID) in a VSAN.
Link the virtual device with the primary real device.
Commit the configuration in the VSAN and check the commit status.
Ensure that the SDV database is consistent on all switches.
Ensure that the virtual devices are zoned correctly.
Activate the zone set.
For a host/virtual device connected to a Cisco MDS 9124 Fabric Switch, ensure that there is a rewrite-capable SDV-enabled director switch in the path.

This section includes the following topics:

•Debugging and Verifying SDV Configuration Using the CLI

•SDV Limitations and Restrictions

•SDV Issues

Debugging and Verifying SDV Configuration Using the CLI

Several commands involving multiple configuration tasks can be used to debug and verify the SDV configuration. Table 12-1 lists debugging and verification CLI commands.

Table 12-1 CLI Commands for Debugging and Verification of SDV 

CLI Command	Description
show sdv database	Displays the SDV virtual device configuration that has been committed.
show sdv session status	Displays the status of the last CFS operation in the SDV configuration.
show sdv merge status	Displays the status of the last CFS merge.
show sdv internal acl-cache dump	Displays SDV ACL entries programmed on interfaces.
show sdv zone active	Displays the SDV zones in the active zone set.
debug sdv all-sdv	Configures all filters for SDV debugging.
show tech-support sdv	Displays most SDV-related debugging information.

SDV Limitations and Restrictions

Be aware of the following limitations and restrictions of SDV:

•All SDV devices, and the real devices accessing the SDV devices, must to be attached to SDV enabled switches.

•SDV does not work for devices connected to non-MDS switches.

•Broadcast zoning is not supported for a zone with a virtual device.

•IVR and SDV cannot be used for the same device. In other words, a SDV-virtualized device cannot be part of a IVR zone or zoneset.

•Virtual device names should be unique across VSANs because they are registered with the device alias server, which is unaware of VSANs. For example, if you have enabled SDV and have registered a name, vt1 in both VSAN 1 and VSAN 2, then the device alias server cannot store both entries because they have the same name.

•You cannot specify the same primary device for different virtual devices.

•SDV works in a hard zoning environment only. (Hard zoning is enforced using ACLs that are applied by the switch port ASIC to every Fibre Channel frame that is switched; hard zoning is also referred to as port zoning.) SDV does not work in the default zone, even if you set it to permit.

•The real device-virtual device zone cannot coexist with the real device-real device zone. If the real devices are not already zoned together, then you can configure the real device-virtual device zone with no negative impact. If these devices are already zoned, then adding the real device-virtual device zone may cause the zone activation to fail. If this occurs, then you must delete one of the zones before activation.

•There must be at least one rewrite-capable SDV-enabled MDS switch located between the server and the target that is being virtualized. The Cisco MDS 9124 Fabric Switch is not a rewrite-capable switch.

In other words, SDV does not work when real devices and primary virtual devices are connected to the same Cisco MDS 9124 Fabric Switch.

---

Caution When restoring a configuration file from an ASCII file (for example, when you issue the copy bootflash:saved-config running-config command), ensure that the pWWNs in the device alias configuration portion of the file are consistent with the current fabric state. If pWWNs in the saved configuration file do not match the current fabric state, then it can result in inconsistencies and merge failures of SDV (which can occur if the file being used to restore the configuration was saved at some earlier point, and subsequent changes have been made to the device alias database). If this occurs, edit the saved configuration file to make the device-alias pWWNs consistent with the device aliases currently used in the fabric.

---

SDV Issues

This section describes potential problems associated with SDV, and includes the following topics:

•SDV Commit Fails

•SDV Commit Partially FailsHost Cannot Locate Disk

•SDV Merge Fails When ISL Comes Up

•Zone Activation Fails in a SDV Zone

SDV Commit Fails

Table 12-2 describes measures to take when an SDV commit fails.

Symptom    SDV commit fails.

Table 12-2 SDV Commit Fails

Symptom	Possible Cause	Solution
SDV commit fails.	Failure to register with device alias because the device alias database is locked.	Clear the device alias CFS session and then reconfigure the SDV device.
	Failure to register with device alias because the same name is already in use.	Use a different name.
	CFS distribution failure.	Check CFS commands to determine the cause of failure.
	The session was created and is locked and in use by another user.	Use the same user credentials and issue the commit command.

SDV Commit Partially Fails

Table 12-3 describes measures to take when an SDV commit partially fails. A partial failure occurs when a commit operation fails beyond the rollback point. The commit operation will complete, but will have succeeded in one or more switches and failed in one or more.

Symptom    SDV commit partially fails.

Table 12-3 SDV Commit Partially Fails 

Symptom	Possible Cause	Solution
Partial failure of SDV commit.	FC ID cannot be assigned because the persistent domain or FC ID is already in use.	The failing switches produce a syslog identifying the reason for the failure. View the syslog and identify the reason for the failure; rectify the problem and reissue the commit command.
	FCID cannot be assigned because the domain cannot be reserved.
	CFS distribution failure.

Host Cannot Locate Disk

Table 12-4 describes measures to take when a host cannot locate a disk.

Symptom    SDV cannot locate disk.

Table 12-4 SDV Cannot Locate Disk 

Symptom	Possible Cause	Solution
Host cannot locate disk.	Host and virtual device are not zoned correctly; not all zone members are resolved.	Enter the show sdv zones active vsan command to identify whether or not zoning is configured and resolving correctly. If it is not, make the necessary corrections to the zone and reactivate zoning.
	Host or virtual device not connected to an SDV-enabled switch.	Enable SDV on those switches.
	Rewrite entries are not programmed correctly.	To confirm that the ACL rewrite and capture entries are programmed correctly for the host and virtual device, enter the show sdv internal acl-cache dump vsan command on switches where the host and virtual devices are connected. If the host or virtual device is connected to the Cisco MDS 9124 Fabric Switch, check the director at the next hop to confirm that the rewrite and capture entries are programmed correctly on all the trunk ports to the switch. Enter the show tech-support sdv command and collect the data returned.
	There are no rewrite-capable switches in either the host-to-virtual device or virtual device-to-host direction.	Make sure that the topology mirrors the supported topologies for SDV to work. Between the host, the SDV, and the real device, there must be at least one of the following switches in the path: •95xx •9216 •9216A •9216i •9120 •9140 SDV must also be enabled.

SDV Merge Fails When ISL Comes Up

Table 12-5 describes the measures to take when an SDV merge fails and ISL comes up.

Symptom    SDV merge fails when the ISL comes up.

Table 12-5 SDV Merge Fails When ISL Comes Up 

Symptom	Possible Cause	Solution
SDV merge fails when ISL comes up.	Configuration mismatch in the merging fabrics.	To forcefully recover from an SDV merge failure due to an ISL not coming up, perform an empty commit from one of the involved fabrics. Note This should not only remedy name and pWWN mismatches, but also a device alias failure.
	Virtual device name and pWWN mismatch in the merging fabrics.
	Virtual device name and FC ID mismatch in the merging fabrics.

Zone Activation Fails in a SDV Zone

Symptom    Zone activation fails in a SDV zone.

If a zone activation fails in a SDV zone, enter the show zone internal sdv-table command to view the physical-virtual mapping maintained in the zone server. Devices should be zoned so that they cannot communicate to both the real device and its virtual component.