When running inq or syminq, you'll see a column titled Ser Num. This column has quite a bit of information hiding in it.

An example syminq output is below. Your output will differ slightly as I'm creating a table from a book to show this; I don't currently have access to a system where I can get the actual output just yet.

Device
Product Device
------------------------ ---------- ---------------------- ----------------------
Name Type Vendor ID Rev Ser Num Cap(KB)
---------------- ----- -------- --------- ------- --------- --------
/dev/dsk/c1t0d0
EMC SYMMETRIX 5265 73009150 459840
/dev/dsk/c1t4d0 BCV EMC SYMMETRIX 5265 73010150 459840
/dev/dsk/c1t5d0 GK EMC SYMMETRIX 5265 73019150 2880
/dev/dsk/c2t6d0 GK EMC SYMMETRIX 5265 7301A281 2880

Using the first and last serial numbers as examples, the serial number is broken out as follows:

73 Last two digits of the Symmetrix serial number
009 Symmetrix device number
15 Symmetrix director number. If <= 16, using the A processor
0 Port number on the director


73 Last two digits of the Symmetrix serial number
01A Symmetrix device number
28 Symmetrix director number. If > 16, using the B proccessor on board: (${brd}-16).
0 Port number on the director

So, the first example, device 009 is mapped to director 15, processor A, port 0 while the second example has device 01A mapped to director 12, processor B, port 0.



Even if you don't buy any of the EMC software, you can get the inq command from their web site. Understanding the serial numbers will help you get a better understanding of which ports are going to which hosts. Understanding this and documenting it will circumvent hours of rapturous cable tracings.

SYMCLI BASE Commands

symapierr - Used to translate SYMAPI error code numbers into SYMAPI error messages.
symaudit - List records from a symmetrix audit log file.
symbcv - Perform BCV support operations on Symmetrix BCV devices.
symcfg - Discover or display Symmetrix configuration information. Refresh the
host's Symmetrix database file or remove Symmetrix info from the file. Can also
be used to view or release a 'hanging' Symmetrix exclusive lock.
symchg - Monitor changes to Symmetrix devices or to logical objects stored on Symmetrix
devices.
symcli - Provides the version number and a brief description of the commands included in
the Symmetrix Command Line
symdev - Perform operations on a device given the device's Symmetrix name. Can also be
used to view Symmetrix device locks.
symdg - Perform operations on a device group (dg).
symdisk - Display information about the disks within a Symmetrix.
symdrv - List DRV devices on a Symmetrix.
symevent - Monitor or inspect the history of events within a Symmetri
symgate - Perform operations on a gatekeeper device.
symhost - Display host configuration information and performance statistics.
syminq - Issues a SCSI Inquiry command on one or all devices. Interface.
symlabel - Perform label support operations on a Symmetrix device.
symld - Perform operations on a device in a device group (dg).
symlmf - Registers SYMAPI license keys.
sympd - Perform operations on a device given the device's physical name.
symstat - Display statistics information about a Symmetrix, a Director, a device group, or a
device.
symreturn - Used for supplying return codes in pre-action and post-action script files.

SYMCLI CONTROL Commands

symacl - Administer symmetrix access control information.
symauth - Administer symmetrix user authorization information.
symcg - Perform operations on an composite group (cg).
symchksum - Administer checksum checks when an Oracle database writes
data files on Symmetrix devices.
symclone - Perform Clone control operations on a device group or on a
device within the device group.
symconfigure - Perform modifications on the Symmetrix configuration.
symconnect - Setup or Modify Symmetrix Connection Security functionalit
symmask - Setup or Modify Symmetrix Device Masking functionality.
symmaskdb - Backup, Restore, Initialize or Show the contents of
the device masking database.
symmir - Perform BCV control operations on a device group or on a
device within the device group.
symoptmz - Perform Symmetrix Optimizer control operations.
symqos - Perform Quality of Service operations on Symmetrix Devices
symrdf - Perform RDF control operations on a device group or on a
device within the device group.
symreplicate - Perform automated, consistent replication of data given
a pre-configured SRDF/Timefinder setup.
symsnap - Perform Symmetrix Snap control operations on a device
group or on devices in a device file.
symstar - Perform SRDF STAR management operations.
symrcopy - Perform Symmetrix Rcopy control operations on devices in
a device file.

SYMCLI SRM(Mapping) Commands

symhostfs - Display information about a host File, Directory,
or host File System.
symioctl - Send IO control commands to a specified application.
symlv - Display information about a volume in Logical Volume
Group (vg).
sympart - Display partition information about a host device.
symrdb - Display information about a third-party Relational
Database.
symrslv - Display detailed Logical to Physical mapping information
about a logical object stored on Symmetrix devices.
symvg - Display information about a Logical Volume Group (vg).

MDS Interoperability Mode Limitations

When a VSAN is configured for the default interoperability mode, the MDS 9000 Family of switches is limited in the following areas when interoperating with non-MDS switches:

• Interop mode only affects the specified VSAN. The MDS 9000 switch can still operate with full functionality in other non-interop mode VSANs. All switches that partake in the interoperable VSAN should have that VSAN set to interop mode, even if they do not have any end devices.

• Domain IDs are restricted to the 97 to 127 range, to accommodate McData's nominal restriction to this same range. Domain IDs can either be set up statically (the MDS 9000 switch will only accept one domain ID; if it does not get that domain ID, it isolates itself from the fabric), or preferred (if the MDS 9000 switch does not get the requested domain ID, it takes any other domain ID).

• TE ports and PortChannels cannot be used to connect an MDS 9000 switch to a non-MDS switch. Only E ports can be used to connect an MDS 9000 switch to a non-MDS switch. However, TE ports and PortChannels can still be used to connect an MDS 9000 switch to other MDS 9000 switches, even when in interop mode.

• Only the active zone set is distributed to other switches.

• In MDS SAN-OS Release 1.3(x), Fibre Channel timers can be set on a per VSAN basis. Modifying the times, however, requires the VSAN to be suspended. Prior to SAN-OS Release 1.3, modifying timers required all VSANs across the switch to be put into the suspended state.

• The MDS 9000 switch still supports the following zoning limits per switch across all VSANs:

– 2000 zones (as of SAN-OS 3.0, 8000 zones)

– 20000 aliases

– 1000 zone sets

– 20000 members

– 8000 LUN members

– 256 LUN members per zone/alias

Brocade Interoperability Mode Limitations

When interoperability mode is set, the Brocade switch has the following limitations:

• All Brocade switches should be in Fabric OS 2.4 or later.

• Interop mode affects the entire switch. All switches in the fabric must have interop mode enabled.

Msplmgmtdeactivate must be run prior to connecting the Brocade switch to either an MDS 9000 switch or a McData switch. This command uses Brocade proprietary frames to exchange platform information. The MDS 9000 switch and McData switches do not understand these proprietary frames, and rejection of these frames causes the common E ports to become isolated.

• Enabling interoperability mode is a disruptive process to the entire switch. It requires the switch to be rebooted.

• If there are no zones defined in the effective configuration, the default behavior of the fabric is to allow no traffic to flow. If a device is not in a zone, it is isolated from other devices.

• Zoning can only be done with pWWNs. You cannot zone by port numbers or nWWNs.

• To manage the fabric from a Brocade switch, all Brocade switches must be interconnected. This interconnection facilitates the forwarding of the inactive zone configuration.

Domain IDs are restricted to the 97 to 127 range to accommodate McData's nominal restriction to this same range.

• Brocade WebTools will show a McData switch or an MDS 9000 switch as an anonymous switch. Only a zoning configuration of the McData switch or the MDS 9000 switch is possible.

• Private loop targets will automatically be registered in the fabric using translative mode.

• Fabric watch is restricted to Brocade switches only.

• The full zone set (configuration) is distributed to all switches in the fabric. However, the full zone set is distributed in a proprietary format, which only Brocade switches accept. Other vendors reject these frames, and accept only the active zone set (configuration).

• The following services are not supported:

– The Alias Server


What are the CLARiiON SAN fan-in and fan-out configuration rules?"

Fan-In Rule: A server can be zoned to a maximum of four storage systems.

Fan-Out Rule:

  • For FC5300 with Access Logix software - 1 - 4 servers (eight initiators) to 1 storage system.
  • For FC4500 with Access Logix - 15 servers to 1 storage system; each server with a maximum of one (single) path to an SP.
  • For FC4700 with Base or Access Logix software 8.42.xx or higher - 32 initiators per SP port for a maximum of 128 initiators per FC4700. Each port on each SP supports 32 initiators. Ports 0 and 1 on each SP in a FC4700 handles server connections. Port 1 on each SP in a FC4700 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP A port 1 on one storage system and SP A port 1 on another storage system counts as one initiator for each port 1. Likewise, each path between SP B port 1 on one storage system and SP B port 1 on another storage system counts as one initiator for each port 1.
  • For FC4700 with Base or Access Logix software 8.41.xx or lower - 15 servers to 1 storage system; each server with a maximum of one (single) path to an SP.
  • For CX200 - 15 initiators per SP, each with a maximum of one (single) path to an SP; maximum of 15 servers.
  • Fan-Out for CX300 - 64 initiators per SP for a maximum of 128 initiators per storage system.
  • For CX400 - 32 initiators per SP port for a maximum of 128 initiators per CX400. Each port on each SP supports 32 initiators. Ports 0 and 1 on each SP in a CX400 handles server connections. Port 1 on each SP in a CX400 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP A port 1 on one storage system and SP A port 1 on another storage system counts as one initiator for each port 1. Likewise, each path between SP B port 1 on one storage system and SP B port 1 on another storage system counts as one initiator for each port 1.
  • Fan-Out CX500 - 128 initiators per SP and maximum of 256 initiators per CX500 available for server connections. Ports 0 and 1 on each SP handle server connections. Port 1 on each SP in a CX500 with MirrorView/A or MirrorView/S enabled also handles remote mirror connections. Each path used in a MirrorView or SAN Copy relationship between two storage system counts as an initiator for both storage systems.
  • For CX600 - 32 initiators per SP port and maximum of 256 initiators per CX600 available for server connections. Ports 0, 1, 2, and 3 on each SP in any CX600 handle server connections. Port 3 on each SP in a CX600 with MirrorView also handles remote mirror connections. In a remote mirror configuration, each path between SP-A port 3 on one storage system and SP-A port 3 on another storage system counts as one initiator for each port 3. Likewise, each path between SP-B port 3 on one storage system and SP-B port 3 on another storage system counts as one initiator for each port 3.
  • Fan-Out CX700 - 256 initiators per SP and maximum of 512 initiators per CX700 available for server connections. Ports 0, 1, 2, and 3 on each SP in any CX700 handle server connections. Port 3 on each SP in a CX700 with MirrorView/A or MirrorView/S enabled also handles remote mirror connections. Each path used in a MirrorView or SAN Copy relationship between two storage system counts as an initiator for both storage systems
  • An initiator is any device with access to an SP port. Each port on each SP supports 32 initiators. Check with your support provider to confirm that the above rules are still in effect.

Save Set Staging:

Save set staging is a process of transferring data from one storage medium to another. Staging reduces the time it takes to complete a backup by directing the initial backup to a high performance file type or adv_file device. The data can then be staged to a storage medium, freeing up the disk space. Any volume type, such as Default, Index Archive, or Default Clone, can be staged. Staging is particularly well suited for data that has been backed up on file type or adv_file devices. Staging allows the occupied disk space on file type or adv_file devices to be reclaimed so that the disk space can be used for other purposes. Use staging to move the data to more permanent storage, such as an optical or tape volume, or even another, lower-priority device. Staging also allows data to be moved off the device outside the backup period, ensuring that sufficient disk space is available for the next backup session. Additional licencing may be required.

You can create, edit, and delete staging policies as you can for other NetWorker resources. As part of the client setup, the use of a staging device can be selected for each pool (or set of pools) for backup, archive, and migration. The files are retained for the specified time in the disk staging pool before being moved to a tape device or optical disk. Any number of devices can be in the staging pool, and a save set can be staged as many times as required, for example to disk, to optical disk, to a local tape device, and to a remote tape device. Also, a volume can be staged to a second volume, and then that data on the second volume can be staged back to the first volume.

The staging process is driven by one of the following events:

- As part of an automatic process, such as keeping the save set for 30 days on the staging device before staging the data to the next device.

- As part of an event driven process, such as when available space in the staging pool drops below a set threshold. When this happens, the oldest save sets are moved first, until available space reaches the upper threshold that has been set.

- As part of an administrator initiated process, such as allowing the administrator to either reset the threshold and kick off staging or manually select save sets to stage.

When you enable a staging policy, the NetWorker server creates a clone of the save set you specify on a clone volume of the medium you specify. After the save set is staged, the save set is deleted from the filesystem to free the space.

The NetWorker server tracks the location of the save set in the media database. The retention policy for the save set does not change when the data is staged. If the file type volume is on a storage node that is running NetWorker software 6.1 or earlier, the tape is not automatically marked appendable after the staging operation.

There is available WWN decoder tool for EMC but I am going to discuss how to decode manually?
Each Symmetrix SAF port, RAF port, EF ficon port or DAF port (DMX only) has a unique worldwide name (WWN). The WWN is associated with the Tachyon chip on the director. It was intended to remain unique per director so that the director can be accessed on a storage area network. The Symmetrix SAF/RAF/DAF/EF WWN is dependent on the Symmetrix serial number, the director number, the processor letter, and the port on the processor. When the SAF/RAF/DAF is inserted into the Symmetrix, it discovers the Symmetrix serial number and slot number and the WWNs are set for the ports on the director.

Symm 4/4.8/5 (2-port or 4-port) Fibre Channel front directors, the WWN breakdown are as follows:

The director WWN (50060482B82F9654) can be broken down (in binary) as follows:

First 28 Bits (from the left, bits 63-36, binary) of WWN are assigned by the IEEE (5006048, the vendor ID for EMC Symmetrix)

5006048 2 B 8 2 F 9 6 5 4
0010 1011 1000 0010 1111 1001 0110 0101 0100

0 A E 0 B E 5 9 -----------------------> AE0BE59 hex = 182500953 Symm S/N

Bits 36 through 6 represent the Symmetrix serial number; the decode starts at bit 6 and works up to 36 to create the serial number. This is broken down as illustrated above.

The least signifigant 6 bits (bits 5 through 0) can be decoded to obtain the Symmetrix director number, processor and port. Bit 5 is used to designate the port on the processor (0 for A, 1 for B). Bit 4, known as the side bit, is used to designate the processor (0 for A, 1 for B). The least signifigant 4 bits, 3 through 0, represent the Symm slot number.


01 0100 = 14 hex -----> director 5b port A

In review, this WWN represents EMC Symmetrix serial number 182500953, director 5b port A

For Symm DMX product family (DMX-1/2/3), the WWN breakdown are as follows:

The director WWN (5006048ACCC86A32) can be broken down (in binary) as follows:

Again, like Symm 4/5, the first 28 bits (63-36) are assigned by the IEEE

5006048 A C C C 8 6 A 3 2

1010 1100 1100 1100 1000 0110 1010 0011 0010

B 3 3 2 1 A 8 ----------------------> B3321A8 hex = 187900328 Symm S/N

Bit 35 is now known as the 'Half' bit and is now used to decode which half the processor/port lie on the board.

Bits 34 through 6 represent the serial number; the decode starts at bit 6 and works up to bit 34 to create the serial number. This is broken down as illustrated above.

In conjunction with bit 35, the last 6 bits of the WWN represent the director number, processor and port. Bit 35, the 'Half' bit, represents either processor A and B, or C and D (0 for A and B, 1 for C and D). Bit 5 again represents the port on the processor (0 for A, 1 for B). Bit 4, the side bit, again represents the processor but with a slight change (if 0 then port A or C, if 1 then port B or D, depending on what the half bit is set to). The last 4 bits, 3 through 0, represent the Symm slot number.

1 11 0010 -------> half bit = 1 (either processor C or D), port bit = 1 (port B), side bit = 1 (because half = 1, looking at C and D processors only, side = 1 now means processor D)
0010 hex = 2 decimal (slot 2 or director 3)

In review, the WWN of 5006048ACCC86A32 represents EMC Symmetrix serial number 187900328, director 3d port B


Generally we never give thought about VCMDB database once we initialize first time. It does make sense when you messup or did some thing disaster. This database is most impppppportaaaaaaant for DMX. Once you loose this database means you can't get DMX configuration back at any cost. So, I am discussing different type of VCMDB on DMX.

We can now support up to 16,000/64000 addressable devices enginuity 5771 onward and therefore the Volume Control Manager Database needs to be physically larger. At 5670, as per EMC recommend CE's were encouraged to create 96 cylinder (minimum) VCMDB during new installs. This was to cater for future upgrades to 5671.

To summarize the VCMDB type applicable to DMX :

Type 3 - this can cater for 32 fibre or iSCSI initiators per port. Introduced with Enginuity 5669 and requires a 24 cylinder (minimum) VCMDB and Solutions Enabler v5.2.

Type 4 - this can cater for 64 fibre or 128 iSCSI initiators per port. Introduced with Enginuity 5670 and requires a 48 cylinder (minimum) VCMDB and Solutions Enabler v5.3.

• Type 5 - this can support 64 fibre or 128 iSCSI initiators per port AND cater for 16,000 devices. Introduced with Enginuity 5671 and requires a 96 cylinder (minimum) VCMDB and Solutions Enabler v6.0. (Note: without a type 5 96cyl VCMDB and SE 6.0 you will be restricted to 8192 logical volumes as in 5670).

Type 6 - this can support 128 fibre or 256 iSCSI initiators per port AND cater for 32,000 devices available on DMX-3 with Enginuity 5771 (at GA release). Currently the Type 6 database (at latest Enginuity 5771 with Solution Enabler 6.0 and above) will cater for 256 fibre or 512 iSCSI initiators and 64,000 logical devices.

What is requirement for Type 5:

The three requirements for a Type 5 VCM database on DMX (and support for up to 16,000 customer addressable volumes) is a correctly configured 96 cylinder VCMDB device, Enginuity 5671 and Solutions Enabler v6.0 or above. Note that the VCMBD “type” reflects the internal data structure of the Volume Control Manager Database. Therefore a 96 cylinder VCMDB size does NOT mean that you have a Type 5 VCMDB.

Note:
• At 5670 with a 48 cylinder VCMDB it is still type 4.
• At 5670 with a 96 cylinder VCMDB it is still type 4.
• At 5670 with a 96 cylinder VCMDB and SE 6.0 it is still type 4 - do not try to convert the database using the SYMCLI (EMC do not support more than 8192 logical volumes at 5670).
• At 5671 with a 48 cylinder VCMDB and SE 6.0 it is still type 4 - the VCMDB is NOT physically large enough.
• At 5671 with a 96 cylinder VCMDB and SE 5.5 it is still type 4 - the VCMDB is large enough but SE 5.5 does not support the Type 5 database.
• At 5671 with a 96 cylinder VCMDB and SE 6.0 it is a type 5 database - if you have run the “symmaskdb convert -vcm_type 5” command. Be aware that if you convert from a lower type database to a higher type, any hosts running a Solutions Enabler version that does not support the higher VCMDB type will NOT be able to access the "new" database.
• At 5771 (DMX-3) the VCMDB data now resides in the SFS volumes. At 5771 the VCMDB should be configured the SAME size as a standard FBA gatekeeper (this can be 3 cylinders due to the 64KB track size but 6 cylinder, as recommended in some guides, is also perfectly acceptable) but it must still be assigned the VCM fibre gatekeeper status. Note that the VCMDB "gatekeeper" on DMX-3 is no longer shown as "write disabled" (it is now a "gatekeeper" rather than a physical volume used for physical storage - the Volume Control Manager data is protected and stored on the internal SFS volumes).
• Note that Enginuity 5771 will ONLY support a Type 6 VCM database (again the data is resident on the SFS volumes). This re-location of the physical database to the SFS volumes caters for the increased host connectivity AND the increase in logical volumes supported with DMX-3.

About Me

My photo
Sr. Solutions Architect; Expertise: - Cloud Design & Architect - Data Center Consolidation - DC/Storage Virtualization - Technology Refresh - Data Migration - SAN Refresh - Data Center Architecture More info:- diwakar@emcstorageinfo.com
Blog Disclaimer: “The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC.”
EMC Storage Product Knowledge Sharing