what is a guid?

http://www.opensolaris.org http://www.sun.com 128 November 2007 version 1.5

What is a GUIDandWhy do I care?

James C. McPherson

[email protected]

http://www.opensolaris.org/


Agenda

● What is a GUID?● Why should I care?● Why do we need GUIDs?● Where do we find GUIDs? What sorts are there?● How do we find GUIDs?● What data do I get? How do I decode all that?● How do we use GUIDs in OpenSolaris?

● Resources● Questions



What is a GUID?

• GUID: Globally Unique IDentifier

• Uniquely identifies an object (device or software)

• Set by a device manufacture or software publisher

• Several different forms> SCSI and Fibre Channel (T10 and T11 standards

committees)> Microsoft> FireWire, iSCSI

No single organisation controls GUIDs

• This presentation is only about SCSI, SAS, iSCSI and Fibre Channel GUIDs



Why should I care?

• GUIDs provide software and hardware vendors witheasy hooks to facilitate features such as > licensing> configuration

• These features should make sysadmins' lives easier

• Solaris and OpenSolaris make use of GUIDs in

Solaris Logical Volume Manager (LVM),ZFS, andMPxIO aka Solaris MultiPlexed I/O



Why do we need GUIDs?

• Problem: many storage devices attached to a hostWhat if the target ID/number changes?

• Problem: multiple paths from host to storageHow do I uniquely identify this device, evenif the controller number changes?

• Problem: multiple hosts accessing same storage

• Problem: dynamic visibility of devices(remember that SAN cloud diagram?)



Somewhere in the cloud is a path to your data

What happens if or when the path throughthe cloud changes?

How do you get to your data?

How do you identify which lun is yours?

These are all questions which GUIDs can help you resolve



Where do we find GUIDs?

• Storage devices which use the SCSI standard,or which encapsulate SCSI data (FCP)

> Disk drives> Tape drives > Tape library changer devices> iSCSI devices

• FireWire devices



What sort of GUIDs will I see in Solaris?

• We see four basic types of GUIDs in (Open)Solaris:

> IEEE Extended (eg 20030003BA27D517)direct-attach FC luns: T3/T4, A5x00, SE3510

> IEEE Registered (eg 500000E011460730), andSAS, SATA, FC luns attached via SAN

> IEEE Registered Extended(eg 600A0B8000254D3E00000A0845E4F906)MPxIO-enabled SAS, SATA and FC luns

> iSCSI format(eg 010000144F3A645200002A004674C1EB)MPxIO-enabled by default



Where is this GUID info stored?

• Stored as a “Designator” record in the device

• SCSI Primary Commands standards define what these “Designator” fields contain

• “Designator” fields require parsing to be of use

• Fortunately this is fairly easy – the formats are well defined in section 7.6 of SPC-3 and SPC-4

• The standard refers to OUIs in the Designators

OUI == Organisation Unique Identifier



What does an IEEE Extended GUID look like?

• SPC4: 7.6.3.6.2 NAA IEEE Extended designator format

• The IEEE COMPANY_ID field contains a 24 bit canonical form OUI(see SPC4 3.1.75) assigned by the IEEE.

• The VENDOR SPECIFIC IDENTIFIER A contains a 12 bit numeric value that is uniquely assigned by the organization associated with the IEEE Company_ID.

Byte / Bit 7 6 5 4 3 2 1 00 NAA (2h) MSB1 Vendor-specific Identifier A LSB2 MSB3 IEEE Company_ID4 LSB5 MSB6 Vendor-specific Identifier B7 LSB



What does an IEEE Registered GUID look like?

• SPC4: 7.6.3.6.3 NAA IEEE Registered designator format

• The IEEE COMPANY_ID field contains a 24 bit canonical form OUI(see SPC4 3.1.75) assigned by the IEEE.

• The VENDOR SPECIFIC IDENTIFIER a 36 bit numeric value that is uniquely assigned by the organization associated with the IEEE Company_ID.

Byte / Bit 7 6 5 4 3 2 1 00 NAA (5h) MSB12 IEEE Company_ID3 LSB MSB456 Vendor-specific Identifier7 LSB



What does an IEEE Registered Extended GUID look like?

Byte / Bit 7 6 5 4 3 2 1 00 NAA (6h) MSB12 IEEE Company_ID3 LSB MSB456 Vendor-specific Identifier7 LSB8 MSB15 Vendor-specific Identifier Extension LSB

• SPC4: 7.6.3.6.4 NAA IEEE Registered Extended designator format

• The IEEE COMPANY_ID field contains a 24 bit canonical form OUI (see SPC4 3.1.75) assigned by the IEEE.

• The VENDOR SPECIFIC IDENTIFIER a 36 bit numeric value that is uniquely assigned by the organization associated with the IEEE Company_ID.

• The VENDOR SPECIFIC IDENTIFIER EXTENSION is a 64 bit numeric value that is assigned to make the DESIGNATOR field unique



Show me some example OUIs

• From http://standards.ieee.org/regauth/oui/index.shtml

08-00-20 (hex) SUN MICROSYSTEMS INC.080020 (base 16) SUN MICROSYSTEMS INC. 4200 Network Circle Santa Clara CA 95054 UNITED STATES

00-20-37 (hex) SEAGATE TECHNOLOGY002037 (base 16) SEAGATE TECHNOLOGY 8001 E. BLOOMINGTON FWY M/S - MPS043 BLOOMINGTON MN 55420 UNITED STATES

00-A0-B8 (hex) SYMBIOS LOGIC INC.00A0B8 (base 16) SYMBIOS LOGIC INC. 2001 Danfield Ct. Fort Collins CO 80525 UNITED STATES

• Companies may request the allocation of more than one OUI.Sun has 3 entries, Fujitsu has 8, Seagate has 6 ....


http://standards.ieee.org/regauth/oui/index.shtml


How do we find GUIDs? (1)

• We use SCSI INQUIRY(6) and requestVital Product Data Page83

huh? Wazzat?

• Use the Solaris USCSI(7D) user-level SCSI interfaceto send an INQUIRY request, and specify

> Enable Vital Product Data = 1 (EVPD), and> Page Code = 0x83 (Device Identification page)

• I still don't quite understand.....



How do we find GUIDs? (2)

• Sample C code:inqcmd = (struct uscsi_cmd *)malloc(sizeof (struct uscsi_cmd)); bzero(inqcmd, sizeof (struct uscsi_cmd));inqcmd->uscsi_cdb = (caddr_t)malloc(CDB_GROUP0 * sizeof (caddr_t));bzero(inqbuf, INQBUFLEN);bzero(rqbuf, RQBUFLEN);bzero(inqcmd->uscsi_cdb, CDB_GROUP0);

inqcmd->uscsi_flags = USCSI_READ|USCSI_RQENABLE;inqcmd->uscsi_timeout = 0; /* "no timeout" */inqcmd->uscsi_bufaddr = (caddr_t)inqbuf;inqcmd->uscsi_buflen = INQBUFLEN;inqcmd->uscsi_cdblen = CDB_GROUP0; /* a GROUP 0 command, length is 6 bytes */

inqcmd->uscsi_cdb[0] = SCMD_INQUIRY; /* SCMD_INQUIRY = 0x12 */inqcmd->uscsi_cdb[1] = 0x01; /* EVPD = Enable Vital Product Data */inqcmd->uscsi_cdb[2] = 0x83; /* Page83 = Device Identification */inqcmd->uscsi_cdb[3] = 0x00; /* allocation length, msb */inqcmd->uscsi_cdb[4] = INQBUFLEN; /* allocation length, lsb, generally 0xff */inqcmd->uscsi_cdb[5] = 0x0; /* control byte /

inqcmd->uscsi_rqbuf = (caddr_t) &rqbuf; /* Request Sense data /inqcmd->uscsi_rqlen = RQBUFLEN; /* allocation length, generally 0xff */

rval = ioctl(fd, USCSICMD, inqcmd); /* send the command out via ioctl() */



What data do I get? (1)

• The USCSI(7D) ioctl returns device identification data

• Example:

Hitachi 36Gb SCSI disk:

00 83 00 24 02 01 00 20 ...$... 48 49 54 41 43 48 49 20 HITACHI 44 4b 33 32 45 4a 2d 33 DK32EJ-336 4e 43 20 20 20 20 20 6NC 34 33 34 4b 35 31 38 30 434K5180




• Example:

Apple iPod, 30Gb, attached via USB:

00 83 00 0c 01 02 00 08 ........00 0a 27 00 14 22 ce 59 ..'..".Y

• Looks kinda binary, doesn't it?




• Here's where it gets interesting:

Fujitsu 72Gb SAS disk, model MAV2073RC:

00 83 00 3c 01 03 00 08 ...<....50 00 00 e0 11 46 07 30 P....F.061 93 00 08 50 00 00 e0 a...P...11 46 07 32 61 94 00 04 .F.2a...00 00 00 01 03 28 00 18 .....(..6e 61 61 2e 35 30 30 30 naa.500030 30 45 30 31 31 34 36 00E0114630 37 33 30 00 00 00 00 0730....

• This shows up under MPxIO as/dev/dsk/c7t500000E011460730d0




• Seagate 73Gb Savvio10k1 SAS disk, model ST973401L:

00 83 00 0c 01 23 00 08 .....#..50 00 c5 00 00 2c c0 d8 P....,..

• This shows up under MPxIO as

/dev/dsk/c0t0d0

• What is interesting here?




• Sun T4 lun, direct-attached via FC

00 83 00 24 01 03 00 10 ...$....60 00 3b a2 7d 51 70 00 `.;.}Qp.3e 5d 2a c5 00 06 4b 4f >]*...KO01 14 00 04 00 00 00 01 ........01 1f 00 04 02 04 00 00 ........

• This lun shows up with a long target number:/dev/dsk/c5t20030003BA27D517d8

• The target number looks more like the hba'sport-wwn, which isn't unique to the device....




• How about some other devices which enumerateunder MPxIO?

Sun T4 lun, attached via FC:

00 83 00 24 01 03 00 10 ...$....60 00 3b a2 7d 51 70 00 `.;.}Qp.3e 5d 2a 7a 00 07 f3 d2 >]*z....01 14 00 04 00 00 00 01 ........01 1f 00 04 02 04 00 00 ........

• This shows up under MPxIO as/dev/dsk/c0t60003BA27D5170003E5D2A7A0007F3D2d0




• Sun StorageTek ST2530, attached via SAS:

00 83 00 28 01 03 00 10 ...(....60 0a 0b 80 00 25 4d 3e `....%M>00 00 0a 08 45 e4 f9 06 ....E...61 93 00 08 50 0a 0b 82 a...P...fc 0c 10 04 61 94 00 04 ....a...

• Under MPxIO, this shows up as

/dev/dsk/c0t600A0B8000254D3E00000A0845E4F906d0




• 1Gb iSCSI lun (local host, local initiator):

00 83 00 94 51 95 00 04 ....Q...00 00 00 01 51 94 00 04 ....Q...00 00 00 01 51 82 00 10 ....Q...01 00 00 14 4f 3a 64 52 ....O:dR00 00 2a 00 46 74 c1 eb ..*.Ft..53 88 00 44 69 71 6e 2e S..Diqn.31 39 38 36 2d 30 33 2e 1986-03.63 6f 6d 2e 73 75 6e 3a com.sun:30 32 3a 36 64 66 63 37 02:6dfc735 64 61 2d 33 64 61 35 5da-3da52d 65 38 36 30 2d 62 64 -e860-bd63 64 2d 63 33 64 62 64 cd-c3dbd31 35 37 30 34 37 64 2e 157047d.74 67 74 31 00 00 00 00 tgt1....51 a2 00 10 01 00 00 14 Q.......4f 3a 64 52 00 00 2a 00 O:dR..*.46 74 c1 eb 51 92 00 10 Ft..Q...01 00 00 14 4f 3a 64 52 ....O:dR00 00 2a 00 46 74 c1 eb ..*.Ft..

• Under MPxIO, this shows up as/dev/dsk/c12t010000144F3A645200002A004674C1EBd0 ->/scsi_vhci/disk@g010000144f3a645200002a004674c1eb



How do I decode all that? (1)

• Data is returned in VPD (Vital Product Data) format, defined in SPC-3 and SPC-4 section 7.6.3

• The first four bytes are information about the page code data in the rest of the buffer

Byte 0: [765 = Peripheral Qualifier] [43210 = Device Type]Byte 1: Page code 0x83Byte 2: page length, MSB, in bytesByte 3: page length, LSB, in bytes (n-3)

• For the Hitachi SCSI disk we have 00 83 00 24

DType = fixed, with 0x24 (36 decimal) bytes returned after this 4 byte header




• The device's next 4 bytes tell us how to decode the first Desginator of its Page83 information:

Byte 4: [7654 = Protocol Identifier] [3210 = Code Set]Byte 5: [7 = PIV] [54 = Association] [3210 = Type]Byte 6: [reserved]Byte 7: [Designator length (n-3)]

• For the Hitachi SCSI disk we have02 01 00 20

CodeSet = ASCIIAssociation = 0 (Addressed Logical Unit)Type is T10 vendor ID basedLength is 0x20 bytes




• What about the iPod?

00 83 00 0c 01 02 00 08 ........00 0a 27 00 14 22 ce 59 ..'..".Y

• 0x0c = 12 bytes returned

0x01 = Protocol Identifier is reserved, andCode Set is Binary

0x02 = Association is 0 (Addressed Logical Unit)Designator type is EUI-64 based

0x08 = Designator length is 0x8 bytes




• What about that Seagate Savvio10k1 disk?

00 83 00 0c 01 23 00 08 .....#..50 00 c5 00 00 2c c0 d8 P....,..

• Byte 5 is 0x23, which breaks out into these bits toindicate the data's Association:> 0 0 1 0 0 0 1 1

• The important part here are bits 5:4 (1 0), which mean that the data is associated with the SCSI target device which contains the addressed logical unit (lun).

• This GUID (5000c500002cc0d8) is not necessarily unique to this lun




• The ASSOCIATION field is very important:

If the GUID is not directly associated with a LUN(01b) then MPxIO will refuse to enumerate thatLUN because we cannot guarantee that the GUIDis unique for that device

• iSCSI is different, of course....

Code Description00B The DESIGNATOR field is associated with the addressed logical unit.

01B The DESIGNATOR field is associated with the target port that

10B The DESIGNATOR field is associated with the SCSI target device that

11B Reserved

RECEIVED the request

CONTAINS the addressed logical unit.




• iSCSI's Page83 response tells us00 83 00 94 51 95 00 04 ....Q...00 00 00 01 51 94 00 04 ....Q...00 00 00 01 51 82 00 10 ....Q...01 00 00 14 4f 3a 64 52 ....O:dR00 00 2a 00 46 74 c1 eb ..*.Ft..

• 51 = 0101.0001 Protocol Identifier = iSCSI, Codeset = Binary95 = 1001.0101 Protocol Identifier Valid = 1, Association = Target Port

Designator Type = Target Port Group

• Designator values 00 00 00 01 indicate that this target port is a member of target port group #1

• 51 = 0101.0001 Protocol Identifier = iSCSI, Codeset = Binary94 = 1001.0100 Protocol Identifier Valid = 1, Association = Target Port

Designator Type = Relative Target Port Identifier

• 51 = 0101.0001 Protocol Identifier = iSCSI, Codeset = Binary82 = 1000.0010 Protocol Identifier Valid = 1, Association = Addressed Logical Unit

Designator Type = ASCII Printable Characters

• The following 16 bytes are an ASCII-Printable GUID

01 00 00 14 4f 3a 64 52 ....O:dR 010000144f3a6400002a004674c1eb00 00 2a 00 46 74 c1 eb ..*.Ft..



How do we use GUIDs in OpenSolaris?

• devids, aka Device IdsSolaris generates GUIDs via devid functions thatconsume the Page83 INQUIRY(6) information

• MPxIO, SVM (Solaris Volume Manager) and ZFSall use devids to track their devices

The OpenSolaris kernel and userland code for devids is licensed under CDDL, so exploration is not just possible, it's thoroughly encouraged!

As part of OpenSolaris, MPxIO is licensed under CDDL (except for 3rd party vendor-specific failover code) so you can see how Sun has implementedfailover code which uses devids and GUIDs



Devids and GUIDs (1)

• The devid common functions use Page83 andPage80 data to generate a devid with

ddi_devid_scsi_encode(...)

• If available, Page83 data supplied is first validatedand then used to generate a devid

• Fallback #1: Page80 data (SCSI serial number)

• Fallback #2: If it's a Sun-branded disk, we know it has a serial number

• Fallback #3: Fake it!

• If we have to use a fallback method, MPxIO mightnot enumerate the device – it's up to the hba driver




• Validation and generation functions are found in

usr/src/common/devid/devid_scsi.c

• Other client functions are found inside

usr/src/uts/common/os/sunmdi.cusr/src/uts/common/os/driver_lyr.cusr/src/uts/common/os/sunddi.c

• Check http://src.opensolaris.org for more usesof devid functions


http://src.opensolaris.org/



• When you look at prtconf(1M) or prtpicl(1M) output, you see the string representation of the devid from

ddi_devid_str_encode() (kernel space)devid_str_encode() (userland)

• These two functions are in

usr/src/common/devid/devid.c

• The algorithm used is subject to change(and has been changed at least once before now)



Show me....

• prtpicl(1M) output

sd (block, 61000001ec) :compatible (6100000207TBL) | scsiclass,00.vFUJITSU.pMAY2073RCSUN72G.r0301 | | scsiclass,00.vFUJITSU.pMAY2073RCSUN72G | | scsa,00.bmpt | | scsiclass,00 | | scsiclass | :sas-mpt :inquiry-device-type 0 :inquiry-vendor-id FUJITSU :inquiry-product-id MAY2073RCSUN72G :inquiry-revision-id 0301 :devid id1,sd@n500000e0115ffb50 :class scsi :target 0x2 :lun 0 ....

id1driver

typedevice data



Hang on, I'm confused again

Sorry about that....

• We use the term “GUID” to refer to the contents of the Designation Descriptor which we get from a Page83 INQUIRY(6) command.

That's a bit lazy....

• To be technically correct, a Solaris GUID is what you get from the ddi_devid_to_guid() function.

Anything else is merely bytes!



What about SVM?

• SVM uses Page83 data to identify devices viaDevids

• PATA-attached:$ cat /etc/lvm/mddb.cf#metadevice database location file do not hand edit#driver minor_t daddr_t device id checksumcmdk 7 16 id1,cmdk@AST3320620AS=____________4QF01RZE/h -3798 cmdk 7 8208 id1,cmdk@AST3320620AS=____________4QF01RZE/h -11990cmdk 7 16400 id1,cmdk@AST3320620AS=____________4QF01RZE/h -20182cmdk 71 16 id1,cmdk@AST3320620AS=____________3QF0EAFP/h -3855cmdk 71 8208 id1,cmdk@AST3320620AS=____________3QF0EAFP/h -12047cmdk 71 16400 id1,cmdk@AST3320620AS=____________3QF0EAFP/h -20239

• Mixing parallel SCSI and FC-attached:$ cat /etc/lvm/mddb.cf #metadevice database location file do not hand edit#driver minor_t daddr_t device id checksumsd 255 16 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -4150ssd 32 16 id1,ssd@w60020f2000007e7e3b278e67000cfb1d/a -3355sd 255 8208 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -12342sd 255 16400 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -20534sd 255 24592 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -28726sd 255 32784 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -36918sd 255 40976 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -45110

Faked

Page80

Page83



And ZFS?

• Same deal – the devid is used to track devicesin your zpool

• ZFS example:

$ strings /etc/zfs/zpool.cache |grep id1,id1,cmdk@AST3320620AS=____________4QF01RZE/d,id1,cmdk@AST3320620AS=____________3QF0EAFP/d

These are from PATA-attached disks, so they don't support the SCSI INQUIRY(6) command and thedevid code fakes a response as required

• SAS-attached example:

$ strings /etc/zfs/zpool.cache |grep id1id1,sd@n500000e0115ffb50/eid1,sd@n500000e0115ffb50/f


mailto:cmdk@AST3320620AS


More on the ZFS example

• Made up of four components:

“id1” indicates a non-NULL devid“sd” last 4 characters of the driver name“n” type of info; n for NAA, w for WWN

x for iSCSI target etc

and the rest?

device id data

....... which we get from the Page83 response



Show me....

• Iostat output:c0t2d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: FUJITSU Product: MAY2073RCSUN72G Revision: 0301 Serial No: 0537S001VJ

• Inquiry utility output:# ./inquiry.i386 -rvg -f /dev/rdsk/c0t2d0s000 83 00 3c 01 03 00 08 ...<....50 00 00 e0 11 5f fb 50 P...._.P61 93 00 08 50 00 00 e0 a...P...11 5f fb 52 61 94 00 04 ._.Ra...00 00 00 01 03 28 00 18 .....(..6e 61 61 2e 35 30 30 30 naa.500030 30 45 30 31 31 35 46 00E0115F46 42 35 30 00 00 00 00 FB50....

Device GUID -------------------------------- --------------------/dev/rdsk/c0t2d0s0 500000e0115ffb50IEEE Registered, codeset: binary, assoc: Logical Unit, type: NAA



Port WWN vs devid and GUID

• Here we see the devid using the IEEE Registered Extended format GUID, but the device shows up in /dev/dsk/ using the port-wwn instead of a GUID:ssd, instance #21

...Hardware properties:name='devid' type=string items=1

value='id1,ssd@n60003ba27d5170003e5d2ac500064b4f'...name='target' type=int items=1

value=001a0700name='target-port' type=string items=1

value='20030003ba27d517'name='port-wwn' type=byte items=8

value=20.03.00.03.ba.27.d5.17...

Device Minor Nodes:dev=(118,168)dev_path=/pci@780/pci@0/pci@8/SUNW,qlc@0/fp@0,0/ssd@w20030003ba27d517,8:a

spectype=blk type=minordev_link=/dev/dsk/c5t20030003BA27D517d8s0

• This is an artefact of PSARC 1997/386 Fibre Channel Architecture

• Yes, we're stuck with it. Sorry!



Is there anything secret in a GUID?

• There might be, but you'll have to dig

• Manufacturers frequently encode interesting infoin their device GUIDs.

• HDS 99xx arrays feature in this infodochttp://sunsolve.sun.com/search/document.do?assetkey=1-9-43203-1

• Caveat: Typically this information is notdisclosed outside of manufacturers andsupport organisations


http://sunsolve.sun.com/search/document.do?assetkey=1-9-43203-1


How does all this info help me?

Remember the potential problems:#1: many storage devices attached to a host

What if the target ID/number changes?#2: multiple paths from host to storage

How do I uniquely identify this device, evenif the controller number changes?

#3: multiple hosts accessing same storage#4: dynamic visibility of devices

(remember that SAN cloud diagram?)

GUIDs help us manage #1, #2 and #4 with ease#3 requires other assistance (such as a cluster

framework), but GUIDs still help there too



Prove it: ZFS (1)

• Iostat -En output for our target disk:

c0t2d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0Vendor: FUJITSU Product: MAY2073RCSUN72G Revision: 0301 Serial No: 0537S001VJ Size: 73.41GB <73407865344 bytes>

• # zpool create testpool mirror c0t2d0s4 c0t2d0s5# zpool status -v pool: testpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM testpool ONLINE 0 0 0 mirror ONLINE 0 0 0 c0t2d0s4 ONLINE 0 0 0 c0t2d0s5 ONLINE 0 0 0 errors: No known data errors

• Now enable MPxIO

# stmsboot -e << from snv_63 onwards this works on x86/x64[reboot] as well as sparc



Prove it: ZFS (2)

• # stmsboot -Lnon-STMS device name STMS device name------------------------------------------------------------------/dev/rdsk/c0t2d0 /dev/rdsk/c4t500000E0115FFB50d0

• Iostat -En output

c4t500000E0115FFB50d0 Soft Errors: 0 Hard Errors: 0 Transport Errors: 0 Vendor: FUJITSU Product: MAY2073RCSUN72G Revision: 0301 Serial No: 0537S001VJSize: 73.41GB <73407865344 bytes>

• # zpool status -v pool: testpool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM testpool ONLINE 0 0 0 mirror ONLINE 0 0 0 c4t500000E0115FFB50d0s4 ONLINE 0 0 0 c4t500000E0115FFB50d0s5 ONLINE 0 0 0errors: No known data errors



Please explain ... (1)

• What if the target ID/number changes?

• This occurs if you re-map a target or lun onyour array

• As long as you don't change the lun configuration from the array's point of view, the Page83 data shouldn't change

• If the Page83 data doesn't change, neither the GUID or the devid will change either



Please explain.... (2)

• How do I uniquely identify this device, evenif the controller number changes?

• Use Page83 data

• If the Page83 data doesn't change, neither the GUID or the devid will change either

• Conclusion: you can plug and play with your storage as much as you want. SVM, MPxIO and ZFSwill still track your devices and send the appropriate IOs as required



Please explain ... (3)

• What about dynamic visibility of devices?

• Applicable to SANs and SAS domains

• Device paths can come and go, but as long as the lun on the other end doesn't change configuration, the Page83 data won't change

• Sounds like a problem we've already solved!

• For the Fibre Channel (aka Leadville) stack on Solaris, this has been a feature since Solaris 8 on SPARC and Solaris 10 for x86/x64

• For SAS domains, this is available in Solaris Nevada build 66 for mpt(7D). The Solaris 10 patch is 125081-10 for sparc, and 125082-10 for x86/x64



Resources - websites

• SCSI Standard Committeehttp://www.t10.org

• Fibre Channel Standard Committeehttp://www.t11.org

• IEEE list of OUIshttp://standards.ieee.org/regauth/oui/index.shtml

• http://src.opensolaris.orgSearch in the ON (aka Nevada) andNWS (aka NetWork Storage) consolidations

• http://docs.sun.com

• http://www.opensolaris.org/os/community/arc/


http://www.t10.org/

http://www.t11.org/

http://standards.ieee.org/regauth/oui/index.shtml

http://src.opensolaris.org/

http://docs.sun.com/

http://www.opensolaris.org/os/community/arc/


Resources - documentation

• T10 (SCSI) specificationsSPC-3, SPC-4, SAS-2, FCP-2

• Solaris driver manpagesscsi_vhci(7D), uscsi(7D), sd(7D), st(7D)iscsi(7D), fp(7D), fcp(7D), mpt(7D)

• Solaris function manpagesioctl(2), devid_get(3DEVID),ldi_open_by_devid(9F)

• Solaris library manpageslibdevinfo(3LIB), libdevid(3LIB)



Resources – Selected ARC cases and fasttracks• PSARC 1995/352

Disk ID Enablers

• PSARC 1997/386Fibre Channel Architecture

• PSARC 1999/647Multiplexed I/O Framework

• PSARC 2002/229MPXIO/scsi_vhci failover-ops configuration

• PSARC 2004/504Common Devid/GUID Encode Interfaces for SCSI Device

• PSARC 2006/703MPxIO extension for Serial Attached SCSI (SAS) on mpt(7D)

• PSARC 2007/046stmsboot(1M) extension for mpt(7D)

• PSARC 2007/100Device Id Extensions

• PSARC 2007/329SCSI inquiry property enhancement





Whatquestionsdoyouhave?


what is a guid?

Documents

ieee registered guid

ieee extended guid

naa 6hmsb12 ieee company

se3510 ieee registered

vendorspecific identifier

sort of guids

lsb msb

storage devices