What Is a GUID?

What is a GUID
and
Why do I care?

James C. McPherson
James.McPherson@Sun.COM

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

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 with
easy 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, and
MPxIO aka Solaris MultiPlexed I/O

Why do we need GUIDs?

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

• Problem: multiple paths from host to storage
How do I uniquely identify this device, even
if 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 through
the 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), and
SAS, 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
Byte / Bit 7 6 5 4 3 2 1 0
0 NAA (2h) MSB
1 Vendor-specific Identifier A LSB
2 MSB
3 IEEE Company_ID
4 LSB
5 MSB
6 Vendor-specific Identifier B
7 LSB

• 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.

What does an IEEE Registered GUID look like?
• SPC4: 7.6.3.6.3 NAA IEEE Registered designator
format
Byte / Bit 7 6 5 4 3 2 1 0
0 NAA (5h) MSB
1
2 IEEE Company_ID
3 LSB MSB
4
5
6 Vendor-specific Identifier
7 LSB

• 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.

What does an IEEE Registered Extended GUID look like?

• SPC4: 7.6.3.6.4 NAA IEEE Registered Extended designator
format
Byte / Bit 7 6 5 4 3 2 1 0
0 NAA (6h) MSB
1
2 IEEE Company_ID
3 LSB MSB
4
5
6 Vendor-specific Identifier
7 LSB
8 MSB
15 Vendor-specific Identifier Extension LSB

• 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 version 1.5
28 November 2007 http://www.opensolaris.org http://www.sun.com 12

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 TECHNOLOGY
002037 (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 ....

How do we find GUIDs? (1)

• We use SCSI INQUIRY(6) and request
Vital Product Data Page83
huh? Wazzat?

• Use the Solaris USCSI(7D) user-level SCSI interface
to 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-3
36 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.0
61 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.5000
30 30 45 30 31 31 34 36 00E01146
30 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....,..

/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 >]*...KO
01 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's
port-wwn, which isn't unique to the device....



• How about some other devices which enumerate
under 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 ........

/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:dR
00 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:6dfc7
35 64 61 2d 33 64 61 35 5da-3da5
2d 65 38 36 30 2d 62 64 -e860-bd
63 64 2d 63 33 64 62 64 cd-c3dbd
31 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:dR
00 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 0x83
Byte 2: page length, MSB, in bytes
Byte 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 have
02 01 00 20
CodeSet = ASCII
Association = 0 (Addressed Logical Unit)
Type is T10 vendor ID based
Length 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, and
Code 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 to
indicate the data's Association:
> 00100011
• 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:
Code Description
00B The DESIGNATOR field is associated with the addressed logical unit.
01B The DESIGNATOR field is associated with the target port that
RECEIVED the request
10B The DESIGNATOR field is associated with the SCSI target device that
CONTAINS the addressed logical unit.
11B Reserved

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

• iSCSI is different, of course....


• iSCSI's Page83 response tells us
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:dR
00 00 2a 00 46 74 c1 eb ..*.Ft..

• 51 = 0101.0001 Protocol Identifier = iSCSI, Codeset = Binary
95 = 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

94 = 1001.0100 Protocol Identifier Valid = 1, Association = Target Port
Designator Type = Relative Target Port Identifier
82 = 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 010000144f3a6400002a004674c1eb
00 00 2a 00 46 74 c1 eb ..*.Ft..

How do we use GUIDs in OpenSolaris?

• devids, aka Device Ids
Solaris generates GUIDs via devid functions that
consume the Page83 INQUIRY(6) information
• MPxIO, SVM (Solaris Volume Manager) and ZFS
all 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 implemented
failover code which uses devids and GUIDs

Devids and GUIDs (1)

• The devid common functions use Page83 and
Page80 data to generate a devid with
ddi_devid_scsi_encode(...)

• If available, Page83 data supplied is first validated
and 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 might
not 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.c
usr/src/uts/common/os/driver_lyr.c
usr/src/uts/common/os/sunddi.c

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



• 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
....

id1 type
driver device 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 via
Devids

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

• 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 checksum
sd 255 16 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -4150
ssd 32 16 id1,ssd@w60020f2000007e7e3b278e67000cfb1d/a -3355 Page83
sd 255 40976 id1,sd@SSEAGATE_ST318404LSUN18G_3BT2GQ1N00002145EXEJ/h -45110 Page80

And ZFS?

• Same deal – the devid is used to track devices
in 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 the
devid code fakes a response as required

• SAS-attached example:
$ strings /etc/zfs/zpool.cache |grep id1
id1,sd@n500000e0115ffb50/e
id1,sd@n500000e0115ffb50/f

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/c0t2d0s0
00 83 00 3c 01 03 00 08 ...<....
50 00 00 e0 11 5f fb 50 P...._.P
61 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.5000
30 30 45 30 31 31 35 46 00E0115F
46 42 35 30 00 00 00 00 FB50....
Device GUID
-------------------------------- --------------------
/dev/rdsk/c0t2d0s0 500000e0115ffb50
IEEE 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=001a0700
name='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=minor
dev_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 info
in their device GUIDs.

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

• Caveat: Typically this information is not
disclosed outside of manufacturers and
support organisations


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, even
#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: 0
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 -L
non-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
0537S001VJ
Size: 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 0
errors: No known data errors


Please explain ... (1)

• What if the target ID/number changes?

• This occurs if you re-map a target or lun on
your 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, even

• 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 ZFS
will 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 Committee
http://www.t10.org
• Fibre Channel Standard Committee
http://www.t11.org

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

• http://src.opensolaris.org
Search in the ON (aka Nevada) and
NWS (aka NetWork Storage) consolidations
• http://docs.sun.com

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

Resources - documentation

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

• Solaris driver manpages
scsi_vhci(7D), uscsi(7D), sd(7D), st(7D)
iscsi(7D), fp(7D), fcp(7D), mpt(7D)
• Solaris function manpages
ioctl(2), devid_get(3DEVID),
ldi_open_by_devid(9F)
• Solaris library manpages
libdevinfo(3LIB), libdevid(3LIB)


Resources – Selected ARC cases and fasttracks
• PSARC 1995/352
Disk ID Enablers
• PSARC 1997/386
Fibre Channel Architecture
• PSARC 1999/647
Multiplexed I/O Framework
• PSARC 2002/229
MPXIO/scsi_vhci failover-ops configuration
• PSARC 2004/504
Common Devid/GUID Encode Interfaces for SCSI Device
• PSARC 2006/703
MPxIO extension for Serial Attached SCSI (SAS) on mpt(7D)
• PSARC 2007/046
stmsboot(1M) extension for mpt(7D)
• PSARC 2007/100
Device Id Extensions
• PSARC 2007/329
SCSI inquiry property enhancement
http://www.opensolaris.org/os/community/arc/

What
questions
do
you
have?

What Is a GUID?

Recommended

More Related Content

Similar to What Is a GUID? (20)

What Is a GUID?