Feedback
Table Of Contents
Configuring a Zone for a Virtual Device
Configuring a Virtual Device with a Static FC ID
Linking a Virtual Device with a Physical Device
Configuring LUN Zone Members for SDV Devices
Real Initiator and SDV Virtual Target with LUN
SDV Virtual Initiator and Real Target with LUN
SDV Virtual Initiator and SDV Virtual Target with LUN.
Resolving Fabric Merge Conflicts
SDV Requirements and Guidelines
Guidelines for Downgrading SDV
Downgrading With Virtual Initiators Configured
Downgrading with SDV LUN Zoning Configured
SAN Device Virtualization
This chapter describes how to configure virtual devices to represent physical end devices for switches running Cisco MDS SAN-OS Release 3.1(2) and later.
Cisco SAN device virtualization (SDV) is a licensed feature included in the Cisco MDS 9000 Family Enterprise package (ENTERPRISE_PKG). See Chapter 3, "Obtaining and Installing Licenses," for details about acquiring licenses.
This chapter includes the following sections:
•
SDV Requirements and Guidelines
About SDV
As of Cisco SAN-OS Release 3.1(2) and later, you can use Cisco SDV to create virtual devices that represent physical end-devices. 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.
SAN devices that are virtualized can be either initiators or targets. You can virtualize targets to create a virtual target, and also virtualize initiators to create a virtual initiator. Such configurations do not distinguish between virtual initiators and virtual targets (see Figure 20-1 and Figure 20-2).
Figure 20-1 Target Virtualization
Figure 20-2 Initiator Virtualization
Note
Typically, today's deployments for handling device failures are designed for high availability (HA), with redundancy being a key part of this design. Let's consider the case where a target is designed to be redundant. Here, two arrays are deployed-a primary and secondary. Enterprises often use some type of consistency technology (such as EMF SRDF) between the primary and secondary arrays to ensure that the secondary is a mirrored copy of the production LUN. However, if the primary array fails, it must be replaced by the secondary, as all I/O must occur on the secondary. Problems can occur because the time required to bring the secondary array up and have it working often takes longer than most can afford (Figure 20-3 illustrates this dilemma).
Figure 20-3 Typical Deployment for Handling Device Failures Before SDV
If a storage array is replaced without using Cisco SDV, then it may require the following:
•
•
•
More specifically, without SDV you might experience the following:
•
•
•
SDV enables you to:
•
•
Figure 20-4 illustrates the benefits of SDV. In this configuration, disk array Y replaces disk array X. When disk array X was deployed, the user created virtual devices for all the Fibre Channel interfaces using SDV. After data replication from disk array X was completed, the user briefly pauses activity on the application server and re-linked disk array Y to the virtual devices used by the server, completing the swapout of disk array X. No zoning changes or host operating system configuration changes were required during the time-critical period when the swap was performed; this significantly minimized application downtime.
Note
Figure 20-4 SDV Example
Key Concepts
The following terms are used throughout this chapter:
•
The virtualized or proxy representation of the real device, which is registered with the name server and has a pWWN and FC ID. A virtual device exists as long as its real (physical) counterpart is online. The virtual device pWWN and FC ID must be unique and cannot clash with any real device pWWNs and FC IDs.•
Reserved by SDV to assign FC IDs to virtual devices. If the switch that reserved the domain goes down, another switch takes over its role using the same domain.Configuring SDV
SDV is a distributed service and uses CFS (Cisco Fabric Services) distribution to synchronize the databases. When you configure SDV it starts a CFS session and locks the fabric. When a fabric is locked, Cisco SAN-OS software does not allow any configuration changes from a switch-other than the switch holding the lock-and issues a message to inform users about the locked status. Configuration changes are held in a pending database for the application. You must perform a commit operation to make the configuration active and to release the lock for all switches. You can discard or stop changes from being distributed by issuing the abort/clear command.
See Chapter 6, "Using the CFS Infrastructure" for more details about CFS,
Note
The following sections describe how to configure SDV:
•
•
•
•
Configuring a Virtual Device
A virtual device is identified by an alphanumeric name of up to 32 characters and defines all the real devices (one primary and one or more secondary) that it represents. Upon the successful creation of a virtual device, the virtual device name is internally registered as the device alias name with the device alias database; the pWWN is automatically assigned by the system using Cisco OUI (Organizational Unique Identifier). A virtual device appears as a real, physical device. You can enumerate up to 128 devices for a virtual device. There is a limit of 4095 on the number of virtual devices that you can create in a single VSAN.
Note
Figure 20-5 shows a configuration that includes a new virtual device, vt1.
Figure 20-5 Creating a Virtual Device
To configure a virtual device and commit it to the fabric configuration, follow these steps:
Configuring a Zone for a Virtual Device
After configuring a virtual device, you must create a zone that includes all the other real devices and the virtual device as members, and add this zone to a zone set, which you can activate. You can add the virtual device to the zone using the configured name and member type as the device alias.
Note
Figure 20-6 shows a virtual device-name device alias (vt1) zoned with the real devices activated; the primary device is online.
Figure 20-6
Zoning the Virtual Device with Real Devices
To add the virtual device to a zone as a zone member, follow these steps:
Caution
For example, SDV is enabled on a switch and a virtual device is defined. SDV assigns a pWWN for the virtual device, and it is zoned based on the pWWN in a zone. If you later disable SDV, this configuration is lost. If you reenable SDV and create the virtual device using the same name, there is no guarantee that it will get the same pWWN again. Hence, you would have to rezone the pWWN-based zone. However, if you perform zoning based on the device-alias name, there are no configuration changes required if or when the pWWN changes.
Be sure you understand how device alias modes work before enabling them. Refer to Chapter 24, "Distributing Device Alias Services" for details and requirements about device alias modes.
Configuring a Virtual Device with a Static FC ID
Typically, the FC ID for the virtual device is assigned by the system. There is a virtual domain reserved and advertised for SDV devices and it is used when allocating the FC ID. The FC ID is registered with the name server and has the same FC4 properties as the primary device it represents.
When a fabric containing a virtual device configuration reboots, the virtual device's domain or FC ID may change; there is no guarantee that the virtual device FC ID will remain the same because it is not a part of the configuration. You can define the FC ID for a virtual device to be static. Configuring a device to have a static FC ID ensures that the same FC ID is used for the virtual device configuration across SAN-OS reboots, and it also provides the following benefits:
•
•
Note
If you are using SDV to virtualize devices for either AIX or HP-UX platforms, we recommend you create a static FC ID.To configure a static FC ID when creating a virtual device, follow these steps:
Linking a Virtual Device with a Physical Device
After creating a virtual device and configuring it as part of a zone, you can define the primary device for it using the link command, which is also used to fail over to the secondary device.
Note
Configuring LUN Zone Members for SDV Devices
You can configure LUN zone members for SDV devices. Following are the types of SDV LUN zone configurations for existing real devices and configured SDV devices:
•
•
•
•
Real Initiator and SDV Virtual Target with LUN
In Example 20-1 a real initiator is zoned with an SDV virtual target (including the LUN).
Example 20-1 Real Initiator and SDV Virtual Target with LUN
zoneset name zs1 vsan 2zone name z1 vsan 2member device-alias I1member device-alias VT1 lun 0member device-alias VT2 lun 1SDV Virtual Initiator and Real Target with LUN
In Example 20-2 an SDV virtual initiator is zoned with a real target (including the LUN).
Example 20-2 SDV Virtual Initiator and Real Target with LUN
zoneset name zs2 vsan 1zone name z2 vsan 1member device-alias VI1member device-alias T1 lun 0member device-alias T2 lun 1SDV Virtual Initiator and SDV Virtual Target with LUN.
In Example 20-3 an SDV virtual initiator is zoned with an SDV virtual target (including the LUN).
Example 20-3
zoneset name zs3 vsan 1zone name z3 vsan 1member device-alias VI1member device-alias VT1 lun 0member device-alias VT2 lun 1
Resolving Fabric Merge Conflicts
Whenever two fabrics merge SDV merges its database. A merge conflict can occur when there is a run-time information conflict or configuration mismatch. Run-time conflicts can occur do to:
•
•
•
A blank commit is a commit operation that does not contain configuration changes, and enforces the SDV configuration of the committing switch fabric-wide. A blank commit operation resolves merge conflicts by pushing the configuration from the committing switch throughout the fabric, thereby reinitializing the conflicting virtual devices. Exercise caution while performing this operation, as it can easily take some virtual devices offline.
Merge failures resulting from a pWWN conflict can cause a failure with the device alias as well. A blank commit operation on a merge-failed VSAN within SDV should resolve the merge failure in the device alias.
You can avoid merge conflicts due to configuration mismatch by ensuring that:
•
•
SDV Requirements and Guidelines
Be aware of the following requirements and guidelines as you plan and configure SDV:
•
•
•
•
•
•
•
•
•
For example, a user attempts to create a configuration with zone A, which consists of I, the initiator, and T, the target (I,T), and zone B, which consists of a virtual initiator, VI, and real target, T (zone VI, T). Such a configuration would fail. Likewise, an attempt to configure zone C, which consists of an initiator, I, and target T, with zone D, which consists of an initiator, I, and virtual target, VT (zone I, VT), would also fail.
Caution
Discarding Changes
At any time, you can discard the uncommitted changes to the running configuration and release the fabric lock (prior to issuing the sdv commit command). If you discard the pending changes, the configuration remains unaffected and the lock is released.
To discard uncommitted SDV configuration changes and release the lock follow these steps:
Step 1
switch# config t
switch(config)#
Enters configuration mode.
Step 2
switch(config)# sdv abort vsan 10
Discards the pending configuration changes.
Clearing SDV Changes
If you have performed a SDV task and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.
Tip
To use administrative privileges and release a locked SDV session, use the clear sdv session command in EXEC mode.
switch# clear sdv session vsan 2Guidelines for Downgrading SDV
Prior to SAN-OS Release 3.1(3), SDV did not support virtual initiators and LUN zoning. Consequently, in SAN-OS Releases 3.1(3) and later, if virtual initiators are configured or SDV devices are configured as LUN-based members of a zone, a configuration check will indicate that downgrading to SAN-OS Release 3.1(2) may be disruptive and is therefore not recommended.
Downgrading With Virtual Initiators Configured
If SDV virtual initiators are configured, you will be unable to downgrade to SAN-OS release 3.1(2)..
This incompatibility is a loose one-it will only warn users before a downgrade. It is recommended that you remove the virtual initiator configuration or shut down the initiator port so that there are no inconsistencies in the downgraded version.
Note
switch# discover scsi-target local os alldiscovery startedswitch# discover scsi-target remote os alldiscovery startedswitch#Downgrading with SDV LUN Zoning Configured
Following are the downgrade scenarios when SDV LUN zoning is configured:
•
•
•
In each of these cases, a configuration check is registered to prevent users from downgrading to SAN-OS Release 3.1(2). This incompatibility is a strict one (it will be disruptive if you proceed with the downgrade).
To avoid the configuration check, delete all the LUN zone members from SDV zones and then activate the zone set before the downgrade.
SDV Configuration Example
The following example shows all tasks (required and optional) associated with configuring SDV.
Step 1
switch# config tEnter configuration commands, one per line. End with CNTL/Z.Step 2
switch(config)# sdv enableStep 3
switch(config)# do show fcns database vsan 2VSAN 2:--------------------------------------------------------------------------FCID TYPE PWWN (VENDOR) FC4-TYPE:FEATURE--------------------------------------------------------------------------0x9f0201 NL 21:00:00:04:cf:cf:45:40 (Seagate) scsi-fcp0x9f0423 NL 21:00:00:04:cf:cf:38:d6 (Seagate) scsi-fcpTotal number of entries = 2Step 4
switch(config)# sdv virtual-device name vdev1 vsan 2switch(config-sdv-virt-dev)# pwwn 21:00:00:04:cf:cf:45:40 primaryswitch(config-sdv-virt-dev)# pwwn 21:00:00:04:cf:cf:38:d6Step 5
switch(config-sdv-virt-dev)# virtual-fcid 0x960001switch(config-sdv-virt-dev)# exitStep 6
switch(config)# sdv commit vsan 2switch(config)# exitStep 7
switch# show sdv database vsan 2virtual-device name vdev1 vsan 2[ WWN:50:00:53:00:00:d2:e0:01 FCID:0x960001 Real-FCID:0x9f0201 ]virtual-fcid 0x960001pwwn 21:00:00:04:cf:cf:45:40 primarypwwn 21:00:00:04:cf:cf:38:d6Step 8
switch# show device-alias databasedevice-alias name vdev1 pwwn 50:00:53:00:01:c9:70:01Total number of entries = 1Step 9
switch# config tEnter configuration commands, one per line. End with CNTL/Z.switch(config)# zoneset name zs1 vsan 2switch(config-zoneset)# zone name zzz1switch(config-zoneset-zone)# member device-alias vdev1switch(config-zoneset-zone)# member pwwn 21:00:03:04:55:cf:d6:40switch(config-zoneset-zone)# endswitch# show zonesetzoneset name zs1 vsan 2zone name zzz1 vsan 2pwwn 50:00:53:00:01:c9:70:01 [vdev1]pwwn 21:00:03:04:55:cf:d6:40Step 10
switch(config)# zoneset activate name zs1 vsan 2Zoneset activation initiated. check zone statusswitch(config)# exitStep 11
switch# show zoneset active vsan 2zoneset name zs1 vsan 2zone name zzz1 vsan 2* fcid 0x211324 [pwwn 50:00:53:00:01:c9:70:01] [vdev1]pwwn 21:00:03:04:55:cf:d6:40switch# show sdv database vsan 2virtual-device name vdev1 vsan 2[ WWN:50:00:53:00:00:d2:e0:01 FCID:0x960001 Real-FCID:0x9f0201 ]virtual-fcid 0x960001pwwn 21:00:00:04:cf:cf:45:40 primarypwwn 21:00:00:04:cf:cf:38:d6Step 12
switch# conf tswitch(config-sdv-virt-dev)# link pwwn 21:00:00:04:cf:cf:38:d6switch(config-sdv-virt-dev)# exitswitch(config)# sdv commit vsan 2switch(config)# do show sdv database vsan 2virtual-device name vdev1 vsan 2[ WWN:50:00:53:00:00:d2:e0:01 FCID:0x960001 Real-FCID:0x9f0423 ]virtual-fcid 0x960001pwwn 21:00:00:04:cf:cf:45:40pwwn 21:00:00:04:cf:cf:38:d6 primaryvirtual-device name vdev2 vsan 2[ WWN:50:00:53:00:00:0b:50:01 ]
Displaying SDV Information
To display the results of the last commit to the SDV database:
switch# show sdv session status vsan 1Session Parameters for VSAN: 1-------------------------------Last Action Time Stamp : Fri Feb 2 10:17:20 2007Last Action : CommitLast Action Result : SuccessLast Action Failure Reason : noneTo display the results of the last CFS SDV fabric merge for a VSAN:
switch# show sdv merge status vsan 1Merge Status for VSAN : 1-----------------------------Last Merge Time Stamp : NoneLast Merge State : NoneLast Merge Result : SUCCESSLast Merge Failure Reason: None [cfs_status: 0]To display details about the SDV database:
switch# show sdv database vsan 2virtual-device name vdev1 vsan 2[ WWN:50:00:53:00:00:d2:e0:01 FCID:0x960001 Real-FCID:0x9f0201 ]virtual-fcid 0x960001pwwn 21:00:00:04:cf:cf:45:40 primarypwwn 21:00:00:04:cf:cf:38:d6To display statistics about SDV for a VSAN:
switch# show sdv statistics vsan 1VSAN ELS-CMD Requests Accepts Rejects Drops-------------------------------------------------1 ELS_PLOGI 54 54 0 01 ELS_RRQ 2 2 0 01 ELS_PRLI 54 54 0 0Default Settings
Table 20-1 lists the default settings for SDV parameters.
