SMI Technical Tutorial

SMI Tutorial > Introduction
Introduction
Storage Management
Initiative
Introduction
CIM and WBEM Basics
Welcome to the Storage Networking Industry Association (SNIA) SMI Technical Tutorial.
SMI-S 1.1.0 Overview
This tutorial will familiarize you with the SNIA, the Storage Management Initiative (SMI)
and the Storage Management Initiative Specification (SMI-S) 1.1.0. After completing this
SMI-S 1.1.0
tutorial, you will have sufficient knowledge of the organization of information in SMI-S to
Functionality
properly interpret its contents. Such understanding will allow for the proper implementation
Resources and of an SMI compliant product.
References
The tutorial is designed for users who have no prior knowledge of SMI and SMI-S 1.1.0. It
Questions & Answers is designed for SMI application developers and SMI instrumentation developers. However,
this tutorial assumes that you have a basic understanding of the Common Information
Model (CIM) and Web Based Enterprise Mangement (WBEM) concepts and principles. If
you are unfamiliar with CIM and WBEM, please read the CIM Tutorial first.
Tutorial Requirements
To view this tutorial you will need the following:
Netscape Navigator, Firefox or Internet Explorer

800 x 600 or higher screen resolution
Tutorial Navigation
There are several ways to navigate through this tutorial:
Index - The index in the left pane lists the major topics discussed in this tutorial.
Select any item in the list to go to the first page for that topic. For example, if you
are already familiar with the SMI and are only interested in learning about SMI-S
1.1.0, select SMI-S 1.1.0 Overview to start with this topic.
Next - To go through the tutorial in order, just click on the Next image in the lower
or upper right hand corner.
Back - To go to a previous page, just click on the Back image in the lower or upper
left hand corner.
At the top of each page, the current position in the tutorial is displayed. For
example, the SNIA Profile page displays
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles
Each item is a link to that topic. So, selecting SMI Tutorial returns you to the
first page of the tutorial, which is this page.
Sub-Menus - On some pages, sub-menus are displayed under the page title. They
contain links to other pages in the tutorial that provide more details about the
information described. For example, selecting SMI-S 1.1.0 Functionality will display
Profiles | Subprofiles | Packages
Then selecting Profiles will display the page that discusses the topic of
Profiles.
Downloading the Tutorial

To download and run the tutorial, follow these steps:
Download the SMI Technical Tutorial PDF file. Approximate size: 2.5 MB.
To run locally, open the downloaded file using a PDF viewer.
Copyright 2005-2006 Storage Networking Industry Association and WBEM Solutions, Inc.
All rights reserved.
SMI Tutorial > Introduction > Executive Summary
Introduction
Storage Management
Initiative
Executive Summary
CIM and WBEM Basics
The Storage Management Initiative (SMI) Developer Tutorial conveys information about
the SNIA and the SMI. The tutorial introduces the reader to the fundamental concepts
discussed in the Storage Management Initiative Specification (SMI-S) 1.1.0. Reading this
SMI-S 1.1.0
tutorial is by no means intended to be a replacement for reading the SMI-S 1.1.0.
Functionality
However, after completion, one will have sufficient knowledge of the organization of
Resources and information in the SMI-S to more easily absorb its contents.
References
First, the tutorial provides background information about the SMI. It describes the
Questions & Answers motivation for its creation and outlines historical information about the SMI
accomplishments since its inception. Next, because the SMI-S 1.1.0 is based upon the
Common Information Model (CIM) and Web Based Enterprise Management (WBEM), the
tutorial gives a quick summary of the basic concepts for these open standards
technologies.
The tutorial explains the motivation for creating the SMI-S 1.1.0. It briefly describes the
previous versions of the specification. Each of the SMI-S requirements are highlighted and
explained. Next, the tutorial discusses how to read the SMI-S by describing the
organization of information. Each major section in the specification is explained.
The contents of each Profile and Subprofile are summarized. The tutorial describes the
purpose for each Profile or Subprofile. After reading each description, the reader will
understand the major components that are managed. The tutorial also identifies the some
of information that are exposed and the some of management operations that can be
performed. However, to get information about all of the CIM elements in the Profile or
Subprofile, one must read the SMI-S 1.1.0 in detail. The reader can easily navigate to the
particular Profiles or Subprofiles of interest by traversing the navigation links at the top of
the page
The final sections of the tutorial show the various resources that the reader can consult to
find additional information. The last section is a list of questions and answers that will help
to reinforce the information contained in the tutorial.
SMI Tutorial > Storage Management Initiative
Introduction
Storage Management
Initiative
Storage Management Initiative
CIM and WBEM Basics History of Management Protocols | History of SMI
SMI-S 1.1.0 Overview The Storage Networking Industry Association (SNIA) in 2002 created the Storage
Management Initiative (SMI) to develop and foster the adoption of a highly-functional open
SMI-S 1.1.0
interface for the management of storage networks.
Functionality
Resources and Originally founded by several leading industry engineers and leaders, the SMI now
References consists of more than 50 member companies, a dozen individual contributors, plus
hundreds of volunteers working across the SNIA organization.
Questions & Answers
Today, the SMI is governed by the SMI committee whose focus is to create open
standards for networked storage management. This committee was chartered by the SNIA
board of directors to oversee the efforts of multiple work groups, committees and forums
of the SNIA.
As a vendor-neutral trade organization, the SNIA works in conjunction with its members to
make storage networking technologies understandable, simpler to implement, easier to
manage, and recognized as valued assets to the business process.
Supporting this vision, the key deliverable for the SMI is the development and promotion
of the industrys first standard interface for storage management the Storage
Management Initiative Specification (SMI-S).
Through the contributions of hundreds of engineers, vendors, end-users and industry

partners in the SMI, the standard has been developed, tested and widely adopted as the
industrys core standard for storage management.
Delivering the standard has required the SMI to provide a comprehensive set of programs
to educate developers as well as coordinate, test, and communicate the direction of the
activities to participating companies. The initiative has multiple programs such as training,
education and conformance testing, making the SMI-S much more than just an industry
standard specification.
The SMI-Specification has been accredited by the INCITS ANSI fast track program and is
the first specification to go through the accreditation process without dissenting comments
from the reviewers. This is a testimony to the diligence performed by the SMI team in
preparing the specification document for ratification. The name of the formal standard is
ANSI INCITS 388-2004, American National Standard for Information Technology
Storage.
SMI Tutorial > Storage Management Initiative > History of Management Protocols
Introduction
Storage Management
Initiative
History of Management Protocols
SMI-S 1.1.0 Overview Until the adoption of SMI-S, management of a storage area network (SAN) used either the
Simple Network Management Protocol (SNMP) or swapping of vendor specific Application
SMI-S 1.1.0
Programming Interfaces (API). Neither meet current needs.
Functionality
Resources and SNMP

References
The most common system management infrastructure is based upon SNMP. Its
Questions & Answers
beginnings go back to the 1980's. Its original charter was to provide a common framework
for managing the low level components of a computer network such as routers and
bridges. Over time, SNMP became the accepted standard for discovering network
topology and monitoring its status.
However, network technology has evolved. Enterprises have increasingly integrated

computers into the operation of their business. Storage resources have become more
distributed. Such trends impose greater demands on a company to efficiently manage its
enterprise computing environment. Unfortunately, despite attempts to expand its
capabilities, SNMP can no longer fulfill these demands. The reasons are many.
SNMP definitions and data are represented in a text file called a Management Information
Base (MIB). Modeling a new object in SNMP requires defining a new MIB. One MIB has
no inherent relationship to any other MIB. A separate MIB is needed for each defined
SNMP managed object. Achieving industry interoperability requires that each participating
vendor agrees to use the same MIBs in the same way.
One MIB has no inherent relationship to any other MIB. Although one MIB may contain
some of the same properties as another MIB, no SNMP mechanism exists to take
advantage of the commonality. Furthermore, SNMP cannot easily model objects in an
enterprise or storage area network (SAN). SNMP was originally chartered to only manage
low level network components, not the entire enterprise. Its naming scheme and
infrastructure do not lend themselves to management of diverse enterprise environments.
For example, SNMP cannot model non-computing elements such as corporate
organizational units.
SNMP defines only four operations. They are Get, GetNext, Set and Trap. Get retrieves
one or more MIB values. GetNext is used to sequentially retrieve data from a table of MIB
values, one row at a time. A table is a logical structuring of MIB values into rows and
columns. Set is used to update an individual MIB value. However, almost all SNMP
management frameworks are read-only while SANs require active management. For
example, an storage administrator must have the ability to create new storage capacity or
to reconfigure existing storage capacity.
For these reasons, the Storage Management Initiative (SMI) chose the Common
Information Model (CIM) because CIM is a much more extensible data model. The SMI
chose Web Based Enterprise Management (WBEM) as the underlying infrastructure
technology because it supplied a richer set of capabilities.
API Swapping
Current enterprise networks consist of systems, network and storage resources from
many different vendors. Each vendor created their own private management application
that used a private interface. Remote management even used private network protocols.
Consequently, in the worst case scenario, a storage management administrator has to
use a separate management application for each storage product.
One solution is create a management application that is knowledgeable of more than one
private interface or protocol. However, creating such an application requires vendors to
share information about their interfaces. Such sharing is called API swapping.
Unfortunately, API swapping does not scale business-wise or engineering-wise. First, the
two competitors must negotiate a mutually beneficial business arrangement. Next, the two
competitors must integrate the new technology into each other's management
applications. This time-intensive process must be repeated for each new device to be
supported from a new vendor. Additionally, even after the initial integration, continual
updates are required for each individual product release.
The SMI chose CIM and WBEM as the underlying technology because they were based
on open standards and provided a normalized approach to the management of SAN
resources. Using CIM and WBEM allows storage management application vendors and
storage device vendors to interact in a common manner without knowledge of any private
API's.
SMI Tutorial > Storage Management Initiative > History of SMI
Introduction
Storage Management
Initiative
History of SMI

2002
SMI-S 1.1.0
Functionality The Storage Management Initiative (SMI) was created by the SNIA in early 2002,
code named BlueFin to develop and foster the adoption of a highly-functional
Resources and open interface for the management of storage networks.
References The Storage Management Initiative Specification (SMI-S) was created to support
the development and promotion of the industry's first standard interface for storage
Questions & Answers
management.
SNIA holds CIM-SAN 1 and 2 Demos at Storage Networking Worlds (SNW). The
CIM-SAN Initiative was based on the highly successful CIM-SAN-1 demonstration
at the Storage Networking World conference in October 2002 where 17 vendors
integrated 32 products creating 97 points of interoperability between those
products. CIM-SAN-1 proved that CIM and WBEM technology are accelerating the
development and integration of more functional network storage management
products.
SMI-Lab was created (SMI-Lab1). The SMI-Lab program was an industry-wide
collaborative program that helps companies accelerate the development and
implementation of SMI-S based Client and Agent products from SNIA member
companies.
2003
The Storage Management Initiative Specification (SMI-S 1.0) was publicly
announced by the SNIA.
SMI-Lab2 was held to accelerate the development and implementation of SMI-S
based Client and Agent products from SNIA member companies.
SNIA announced and created the SNIA Conformance Test Program (CTP)
consisting of master test suites that are developed, owned and operated by SNIA to
provide the assurance of SMI implementations accuracy to the SMI-Specification.
SMI-S Developer courses were introduced and offered to accelerate the
development and implementation of the SMI-Specification.
Continued efforts to enhance the SMI-Specification
2004
SMI-Labs 3 and 4 were held to accelerate the development and implementation of
SMI-S based Client and Agent products from SNIA member companies.
SNIA submitted SMI-S 1.0.2 to the InterNational Committee for Information
Technology Standards (INCITS) for accreditation.
SMI-Lab 5 was held with 29 vendors implementing and validating SMI-S
Vendors began development of SMI enabled products
SMI-S 1.0.2 became an ANSI Standard. The name of the formal standard is ANSI
INCITS 388-2004, American National Standard for Information Technology
Storage
SNIA began development of Client Conformance Testing by CTP in support of SMI-
S 1.1.0
The SNIA announced the first round of products to have passed the CTP for the
SMI-S 1.0.2 including over 100 products from 14 member companies
Successful remote scripted demonstration was performed between SMI-Lab 5 SMI
Agents at the SNIA Technology Center in Colorado Springs and SMI Clients in
SNW Europe
Continued efforts to add to the growing SMI-Specification adding additional
functionality and Profiles targeted for the SMI-S 1.1.0 release including NAS, iSCSI,
Policy and HDR.
Scoping of SMI-S 1.2 started based on End User requirements
2005
SNIA submitted SMI-S 1.0.2 to the International Organization for Standardization
(ISO)
CTP began testing of SMI conforming Clients
SMI-Lab 6 expands to validate SMI-S 1.1.0 Client and Agent implementations
Over 280 products from 18 SNIA Member companies were certified to SMI-S 1.0.2
SNIA released SMI-S 1.1.0 for public review covering even more complex storage
management including Copy Services, Disk partitioning, Provisioning and Switch
port management
SMI Tutorial > CIM and WBEM Basics
Introduction
Storage Management
Initiative
CIM and WBEM Basics
CIM and WBEM Basics CIM | WBEM
SMI-S 1.1.0 Overview SMI-S 1.1.0 uses the Common Information Model (CIM) as its data model. The Distributed
Management Task Force (DMTF) has published a CIM Specification which defines the
SMI-S 1.1.0
meta-model elements. The DMTF has also published a CIM Schema. Using the meta-
Functionality
model rules and syntax, CIM objects have been defined for many different components
Resources and
and aspects in an enterprise computing environment. SMI-S 1.1.0 uses these CIM object
References definitions.
Questions & Answers SMI-S 1.1.0 also uses the Web Based Enterprise Management (WBEM) technology.
WBEM is a set of standards that allow a Client to performa operations on CIM data that is
managed by a WBEM Agent.
The following sections describe each in further detail.
SMI Tutorial > CIM and WBEM Basics > CIM
Introduction
Storage Management
Initiative
CIM
SMI-S 1.1.0 Overview The Common Information Model (CIM) is a hierarchical, object oriented architecture that is
used to describe the attributes of managed objects in a enterprise computing environment.
SMI-S 1.1.0
For example, CIM can be used to describe the characteristics of a computer system. CIM
Functionality
is also used to depict the relationships between different managed objects. For example,
Resources and
CIM can be used to depict the relationship of disks that are connected to a computer
References system. CIM consists of a specification and a schema.
Questions & Answers Specification

The CIM Specification describes an object-oriented meta model. It defines the syntax and
rules for describing managed objects in terms of meta schema elements. Using these
rules, the CIM Specification defines the following meta schema elements:
Class
Property
Method
Qualifier
Reference
Association
Indication
Instance
A Class is a template for describing the attributes and behavior of a particular managed
object. Classes contain Properties that represent attributes of the managed object. For
example, the class CIM_Keyboard describes the attributes of a keyboard. This class
contains Properties such as Layout and NumberOfFunctionKeys.
Classes can contain Methods that represent behavior of the managed object. A Client can
invoke the Method of a Class to perform a defined function. A Method signature includes a
name, return type, optional input parameters and optional output parameters. For
example, CIM_Service defines StartService() and StopService() Methods.
CIM is a hierarchical, object oriented architecture. Classes can be derived from another
Class. The derived Subclass inherits all of the Properties and Methods of the parent
Class. For example, when CIM_ManagedSystemElement is derived from
CIM_ManagedElement. it inherits the Caption, Description and ElementName Properties
from CIM_ManagedElement.
An Instance represents the instantiation of a Class. Whereas a Class is just a template for
describing a managed element, an Instance contains values for the Properties defined in
the Class template. For example, when an Instance of CIM_Keyboard is created, the
Layout property might have a value of QWERTY.
An Association is a specialized Class that is used to represent a relationship between two

Classes. For example, the CIM_SystemDevice Class represents the relationship between
a CIM_System and a CIM_LogicalDevice. An Assocation Class contains two or more
Properties that are References to other Classes. An Association Instance contains
References to other Instances. References are a special type of Property that is a pointer
to another Class or Instance. Only Associations can contain Reference Properties. Using
Associations, a Client can traverse from one Class to another to discover the various
components of a system or subsystem. For example, after finding the Instance
representing the storage system, using the appropriate Associations, a Client can
determine the storage devices that comprise the storage system.
An Indication Class is another specialized Class that is used during Event handling. A
Client can subscribe to a WBEM Agent to be notified when a particular event occurs. The
Client defines the event it wishes to monitor by specifying a Filter which is a CIM Query
Language (CQL) expression. CQL is a subset of the Structured Query Language (SQL).
When the particular event occurs, the WBEM Agent delivers an Indication Instance to the
Client that is listening for the Indication.
Qualifiers are used to provide additional information about a CIM element (e.g., Class,
Property, etc.). The CIM Specification defines many types of Qualifiers. For example, the
Description Qualifier below is applied to the Class element named A
[Description(An example of using the Description Qualifier on a Class element]
class A : B {
};
The ValueMap Qualifier below is applied to the Property element named intProp whose
data type is an unsigned 32-bit integer. The Qualifier specifies that intProp is only
permitted to have the integer values of 3, 7 or 0.
class C : B {
[ValueMap(3, 7, 0)]
uint32 intProp;
};
Here, the ValueMap Qualifier is applied to the Property named intProp whose data type is
an unsigned 32-bit integer. The Qualifier specifies that intProp is only permitted to have
the integer values of 3, 7 or 0.
CIM Classes are grouped by a Namespace. A WBEM Agent can have one or more
Namespaces. A CIM Instance is identified by an Object Name which is the combination of
System Address, Namespace, Class name and a list of Key/Value pairs. An example
Object Name is given below:
http://192.168.0.200/interop.Class_A.Key1=1,Key2=aaa
The Object Name above can be broken down as follows:
System Address: 192.168.0.200

Namespace: interop
Class name: Class_A
Key/Value pairs:
Key1=1
Key2=aaa
Schema
A schema is an implementation of the information model that creates a specific data
model. The Distributed Management Task Force (DMTF) has defined a CIM Schema data
model. The CIM Schema describes the managed objects in its data model in the form of
Class definitions that contain the Property and Method definitions as well. Periodically, the
DMTF publishes new versions of the CIM Schema. Each version contains new Class
definitions as well as corrections or enhancements to existing Class definitions created in
previous versions. The SMI-S 1.1.0 is based upon the CIM Schema v2.11.
SMI Tutorial > CIM and WBEM Basics > WBEM
Introduction
Storage Management
Initiative
WBEM
SMI-S 1.1.0 Overview Web Based Enterprise Management (WBEM) is a set of standards based technologies
that are used to provide a uniform mechanism for exchanging CIM information between
SMI-S 1.1.0
Clients and WBEM Agents in an enterprise computing environment. The Distributed
Functionality
Management Task Force (DMTF) defines a set of WBEM Operations that allow a Client to
Resources and
retrieve CIM data and to request that operations be performed on CIM data by the WBEM
References Agent. These operations are defined by the DMTF in the CIM Operations over HTTP
specification. SMI-S 1.1.0 is based upon version 1.2.0 of this specification.
Questions & Answers
Each WBEM Operation has arguments defined that control the type and amount of
information returned. Consult the CIM Operations over HTTP specification for information
about their use. WBEM Operations can be grouped by the following functions:
Instance Operations
GetInstance - return a CIM Instance from a Namespace
CreateInstance - create a new CIM Instance in a Namespace
ModifyInstance - modify an existing CIM Instance in a Namespace
DeleteInstance - delete an existing CIM Instance in a Namespace
EnumerateInstances - return the Instances of a CIM Class and all its subclasses in
a target Namespace.
EnumerateInstanceNames - return the names of Instances of a CIM Class and all
its subclasses in a target Namespace.
Association Traversal
Associators - return the Classes that are associated to a particular CIM Class or
return the Instances that are associated to a particular CIM Instance.
AssociatorNames - return the names of Classes that are associated to a particular
CIM Class or return the names of Instances that are associated to a particular CIM
Instance
References - return the Association Classes that refer to a particular CIM Class or
return the Association Instances that refer to a particular CIM Instance
ReferenceNames - return the names of Association Classes that refer to a
particular CIM Class or return the names of Association Instances that refer to a
particular CIM Instance
Class Operations
GetClass - return a CIM Class from a Namespace
CreateClass - create a new CIM Class in a Namespace
ModifyClass - modify an existing CIM Class in a Namespace
DeleteClass - delete an existing CIM Class in a Namespace
EnumerateClasses - return the subclasses of a CIM Class a Namespace
EnumerateClassNames - return the names of subclasses of a CIM Class in a
Namespace
Query Execution
ExecQuery - perform a query against a Namespace.
Extrinsic Method Invocation

InvokeMethod - perform the private function defined in the CIM Class
Qualifier Declarations
GetQualifier- return a Qualifier declaration from a Namespace
SetQualifier - create or modify a Qualifier declaration in a Namespace
DeleteQualifier - delete an existing Qualifier declaration in a Namespace
EnumerateQualifiers - return all Qualifier declarations from a Namespace
SMI Tutorial > SMI-S 1.1.0 Overview
Introduction
Storage Management
Initiative
CIM and WBEM Basics SMI-S History | SMI-S 1.1.0 Requirements | How to Read SMI-S 1.1.0
SMI-S 1.1.0 Overview A major activity in the Storage Management Initiative (SMI) is the Storage Management
Initiative Specification (SMI-S). This specification defines an interface for the management
SMI-S 1.1.0
of a Storage Area Network (SAN) that is a heterogeneous environment of management
Functionality
applications, storage devices and storage systems from different vendors. The interface
Resources and
uses standards based protocols and specifications to provide interoperability, security and
References extensibility. The SMI-S leverages the Common Information Model (CIM), Web Based
Enterprise Management (WBEM) and the Service Location Protocol (SLP).
Questions & Answers
CIM is the data model. It is a hierarchical, object-oriented architecture that is used to
represent all of the storage management components and resources in a SAN. SMI-S
1.1.0 is based on the CIM Schema version 2.11. WBEM is a set of standards based
technologies that allow for the exchange of CIM data in an enterprise. It defines a uniform
means to retrieve CIM data and to perform operations on CIM data. SLP allows a Client to
discover the SMI Agents that are available on a SAN. SLP also allows a Client to
determine the capabilities of the SMI Agents such as which storage devices they manage.
The latest version of the SMI-S is 1.1.0. This version describes a functionality matrix that
defines the scope of manageability covered by the specification. Five levels of functionality
are defined. In top-down order they are:
Level 5 Application Level Functionality - allows a Client to manage applications

(e.g., database, mail server, etc) in a SAN that use data at the File/Record level.
Level 4 File/Record Level Functionality - allows a Client to manage SAN
resources that expose data as files or records such as filesystems.
Level 3 Block Level Functionality - allows a Client to manage the SAN resources
that are used by the File/Record resources such as Storage Volumes (e.g., LUNs)
and Logical Disks.
Level 2 Connectivity Level Functionality - allows a Client to manage the
connectivity between physical devices in a SAN such as Fabrics, Zones and iSCSI
Sessions.
Level 1 Device Level Functionality - allows a Client to manage the physical
devices in a SAN such as Host Based Adapters (HBA) and disk drives.
Additionally, for each level of functionality, the SMI-S 1.1.0 defines five separate aspects
of manageability. Referred to by the acronym FCAPS, they are:
Fault Management - allows a Client to identify, isolate, correct and log faults that
might occur on a SAN resource.
Configuration Management - allows a Client to discover, configure and monitor
SAN resources
Accounting Management - allows a Client to collect usage statistics for SAN
resources
Performance Management - allows a Client to collect performance, error rate and
utilization statistics for SAN resources
Security Management - allows a Client to manage security mechanisms that
protect against unauthorized access to SAN resources
SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S History
Introduction
Storage Management
Initiative
SMI-S History
SMI-S 1.1.0 Overview Several versions of the Storage Management Initiative Specification (SMI-S) have been
published by the Storage Networking Industry Association (SNIA). IThe versions published
SMI-S 1.1.0
are:
Functionality
Resources and Bluefin in May 2002

References SMI-S 1.0 in July 2003
SMI-S 1.0.1 in September 2003
Questions & Answers SMI-S 1.0.2 in February 2004
SMI-S 1.1.0 scheduled for December 2005
Bluefin
This draft specification was the forerunner for the SMI-S. Originally, this work was
accomplished outside of the SNIA by the private effort of a group of storage vendor
companies known as the Partner Developer Process (PDP). The Bluefin specification was
made public in May 2002. Later in 2002, the SNIA adopted the PDP and renamed it as the
Storage Management Initiative (SMI) and in turn renamed Bluefin as the SMI-S.
Bluefin laid the groundwork requirements that were later adopted by the SMI-S.
Specifically, it adopted the open standards of the Common Information Model (CIM) and
Web Based Enterprise Management (WBEM) as the basis for providing interoperable
storage management in a Storage Area Network (SAN) consisting of management
applications and storage systems from different vendors. These technologies are owned
by the Distributed Management Task Force (DMTF). They are the foundation for achieving
interoperability in a heterogeneous Storage Area Network (SAN) consisting of storage
management applications and storage devices and resources from different vendors.
Bluefin defined the initial Profile work for several storage resources. They were Fabric,
Switch, Array and Host Based Adapter (HBA). This effort resulted in many new CIM
Classes and enhancements being adopted into the CIM Schema version 2.7. Bluefin was
based on the CIM Specification version 2.2 and the CIM Operations over HTTP version
1.1.
SMI-S 1.0
The SMI-S 1.0 was made available in July 2003. The SMI-S 1.0 added more Profiles and
Subprofiles and further clarified their use. It further refined the Bluefin content by clarifying
the use of Profile and Subprofiles. However, the SMI-S 1.0 was considered to be a Work-
in-Progress specification that was not yet finalized. This specification defined several
Profiles for Fabric, Storage and Hosts along with several Common Subprofiles and a few
Storage Subprofiles. This effort resulted in many new CIM Classes and enhancements
being adopted into the CIM Schema version 2.8. SMI-S 1.0 was based on the CIM
Specification version 2.2 and the CIM Operations over HTTP version 1.1.
SMI-S 1.0.1
The SMI-S 1.0.1 was made available in September 2003. It finalized the content of SMI-S
1.0. However, in some cases, it marked several of the SMI-S 1.0 Profiles and Subrofiles
as Experimental. Profiles or Subprofiles are marked as Experimental when insufficient
implementation experience creates too much risk that the set of CIM Classes might
change. The Experimental Profiles and Subprofiles listed were:
Sparing Subprofile
InterLibaryPort Connection Subprofile
Partitioned/Virtual Library Subprofile
Fibre Channel Connection Subprofile
Extender Profile
Management Appliance Profile
Out of Band Virtualizer Profile
JBOD Profile
The SMI-S 1.0.1 used the CIM Schema version 2.8, the CIM Specification version 2.2 and
the CIM Operations over HTTP version 1.1.
SMI-S 1.0.2
The SMI-S 1.0.2 was made available in February 2004. Most changes were minor
corrections to text and diagrams. Some descriptive material was rewritten to provide
greater clarification. The specification added one Experimental Subprofile, which was
Library Capacity.
SMI-S 1.0.2 used the same set of standards specifications as SMI-S 1.0.1, which were
CIM Schema version 2.8, the CIM Specification version 2.2 and the CIM Operations over
HTTP version 1.1.
SMI-S 1.1.0
The SMI-S 1.1.0 is scheduled to be made available in December 2005 and is described by
this tutorial.
SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements
Introduction
Storage Management
Initiative
SMI-S 1.1.0 Requirements
SMI-S 1.1.0 Overview CIM-XML | xmlCIM | SLP
SMI-S 1.1.0
The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN)
Functionality
that is a heterogeneous environment of management applications, storage devices and
storage systems. To achieve this goal, the SMI-S 1.1.0 specifies the use of open
Resources and
References
standards technologies as the foundation for the architecture. Specifically, the SMI-S 1.1.0
uses the following:
Questions & Answers
Common Information Model (CIM) - the data model that represents SAN
resources and their information
Web Based Enterprise Management (WBEM) - the infrastructure that is used to
exchange CIM data and to perform operations on CIM data
CIM-XML - the protocol used to exchange CIM data between a Client and WBEM
Agent
xmlCIM - the specific encoding of CIM data into XML documents
Service Location Protocol (SLP) allows a Client to discover SMI Agents on a SAN
and to determine their capabilities
CIM and WBEM have already been discussed in previous sections. The following sections
will discuss CIM-XML, xmlCIM and SLP.
SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > CIM-XML
Introduction
Storage Management
Initiative
CIM-XML
SMI-S 1.1.0
CIM-XML is the protocol that is used by SMI-S 1.1.0 to exchange CIM and WBEM
Functionality
information between a Client and a WBEM Agent. CIM-XML uses xmlCIM as the payload
and HTTP as the transport. Currently, both HTTP 1.0 and 1.1 are supported. SMI-S 1.1.0
Resources and
References
chose CIM-XML because it required by WBEM. Moreover, HTTP is a widely supported
protocol that is usable by almost all existing infrastructures and over the Internet.
Questions & Answers
Using HTTP, SMI-S 1.1.0 can leverage the existing HTTP security mechanisms. To
establish the connection to a WBEM Agent, a Client can use Basic or Digest
authentication. Basic authentication sends the credential information in clear text while
Digest authentication sends the credential information as encrypted data. SMI-S 1.1.0 also
requires that the Client and WBEM Agent exchange the HTTP payload as encrypted data
using the Secure Sockets Layer (SSL).
Using HTTP, SMI-S 1.1.0 can leverage the existing HTTP mechanisms to define
extension headers. A SMI-S 1.1.0 WBEM Agent is required to support the HTTP
operations of POST and MPOST. The CIM Operations over HTTP Specification v1.2
defines specific extension headers for a Client request and a WBEM Agent response.
Different extension header are defined for single versus multiple (i.e., batch) operations.
The example below shows several CIM-XML extension headers for a GetClass operation
on the root/cimv2 namespace
M-POST /cimom HTTP/1.0

Content-Type: text/xml;charset=UTF-8
Accept: text/xml, application/xml
Man: http://www.dmtf.org/cim/mapping/http/v1.0;ns=48
48-CIMProtocolVersion: 1.0
48-CIMOperation: MethodCall
48-CIMMethod: GetClass
48-CIMObject: root%2Fcimv2
User-Agent: Java1.2.1
Host: edoc5-pc
Content-length: 445
<?xml version="1.0" encoding="UTF-8"?>
SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > xmlCIM
Introduction
Storage Management
Initiative
xmlCIM
SMI-S 1.1.0
xmlCIM is a standard way to represent CIM data using the Extensible Markup Language
Functionality
(XML). XML is a subset of Standardized General Markup Language (SGML) that offers
data modeling capabilities. An XML Document is a collection of data represented in XML.
Resources and
References
Hence, xmlCIM allows CIM data to be expressed as XML elements in an XML Document.
This XML Document then becomes the payload that CIM-XML encapsulates within an
Questions & Answers HTTP header.
A Document Type Definition (DTD) is used to map CIM objects into XML elements. The
CIM DTD is defined by the Distributed Management Task Force (DMTF). It defines CIM
object Declarations to represent CIM meta schema elements such as Classes, Instances
and Qualifiers, etc. It also defines CIM Messages for use by CIM-XML.
The following example illustrates the mapping of CIM data into XML elements. This XML
Document a Class called CIM_LogicalPort whose superclass is CIM_LogicalDevice. The
CIM_LogicalPort class definition includes a string Description Qualifier whose value is
The abstraction of a port or connection point of a Device. The CIM_LogicalPort class has
two Properties, Speed and MaxSpeed. The Speed Property is an unsigned 64-bit integer.
It has a string Description Qualifier whose value is The speed of the Port in Bits per
Second. The MaxSpeed Property is an unsigned 64-bit integer. It has a string Description
Qualifier whose value is The max speed of the Port in Bits per Second. Both Properties
have a string Units Qualifier whose value is Bits per Second.
<CLASS NAME="CIM_LogicalPort" SUPERCLASS="CIM_LogicalDevice">

<QUALIFIER TRANSLATABLE="true" NAME="Description" TYPE="string">
<VALUE>The abstraction of a port or connection point of a Device.</VALUE>
</QUALIFIER>
<PROPERTY NAME="Speed" TYPE="uint64">
<VALUE>The speed of the Port in Bits per Second.</VALUE>
</QUALIFIER>
<QUALIFIER TRANSLATABLE="true" NAME="Units" TYPE="string">
<VALUE>Bits per Second</VALUE>
</QUALIFIER>
</PROPERTY>
<PROPERTY NAME="MaxSpeed" TYPE="uint64">
<VALUE>The max speed of the Port in Bits per Second.</VALUE>
</QUALIFIER>
<QUALIFIER TRANSLATABLE="true" NAME="Units" TYPE="string">
<VALUE>Bits per Second</VALUE>
</QUALIFIER>
</PROPERTY>
</CLASS>
SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > SLP
Introduction
Storage Management
Initiative
SLP
SMI-S 1.1.0
The SMI-S 1.1.0 requires the use of the Service Location Protocol (SLP) version 2 to allow
Functionality
Clients to discover SMI Agents on a Storage Area Network (SAN). SLP is defined by IETF
RFC 2608. The DMTF defines the use of the SLP by a SMI Agent in DSP0205. The DMTF
Resources and
References
defines a SLP Template in DSP0206. The SLP Template contains information about the
capabilities of the SMI Agent. By examining the SLP Template, a Client can determine the
Questions & Answers capabilities of a SMI Agent such as which storage devices it supports.
The SLP defines the following three roles:
Service Agent (SA) - represents the resource that advertises the capabilities of SMI
Agents.
Directory Agent (DA) - represents the resource that acts as a centralized network
repository for SMI Agent advertisements.
User Agent (UA) - represents the Client that wants to discover SMI Agents and to
determine the capabilities of a SMI Agent.
A SMI Agent registers its SLP Template with a SA or DA. A Client broadcasts a request to
listening SA's or DA's for available advertisements. The default reserved listening port for
SLP is 427. An SA sends back its SLP Template. A DA sends back all the SLP Templates
it has collected. A Client then examines the SLP Templates to discover which SMI Agents
are available and to discover the capabilities of each discovered SMI Agent. Based on
information collected, the Client decides which SMI Agent to connect to and manage. The
SLP Template contains information that allows a Client to make their decision. The most
important information is as follows:
The address of the SMI Agent (e.g., http://192.168.0.200:5988)

The communication mechanisms supported by the SMI Agent (e.g., CIM-XML)
The types of HTTP authentication supported by the SMI Agent (e.g., Digest)
The WBEM operations supported by the SMI Agent. For example, some SMI
Agents may only be capable of read operations. Some may not support schema
manipulation.
The Namespaces available on the SMI Agent
The name of the interop Namespace on the SMI Agent. The interop Namespace
contains the Classes needed by the SMI Agent to manage itself.
The Registered Profiles supported by the SMI Agent. For example, if a SMI Agent
supports the SMI-S management of a disk array, then the "SNIA:Array" Profile
would be advertised in its SLP Template.
SMI Tutorial > SMI-S 1.1.0 Overview > How to Read SMI-S 1.1.0
Introduction
Storage Management
Initiative
How to Read SMI-S 1.1.0
SMI-S 1.1.0 Overview How to Read Profiles | How to Read Recipes
SMI-S 1.1.0
Functionality Introduction
Resources and The Storage Management Initiative Specification v1.1.0 (SMI-S 1.1.0) is organized into
References several major sections. The initial chapter lay the groundwork for understanding the rest of
the specification. First, the specification lists the definitions of the important terms and
Questions & Answers acronyms that are used. Next, it explains how the reader should interpret certain keywords
such as shall or may not. Then it lists the conventions used including the important
designations of Experimental and Deprecated materials.
Sections identified as Deprecated contain material that is not recommended for use in
new development. They represent specifications that have become obsolete or have been
replaced by newer specifications. Sections identified as Experimental contain material
that lack sufficient review and implementation experience which prevents it from being
officially adopted by SMI committee within the SNIA. As a consequence, Experimental
sections are subject to change or even removal.
NOTE: Any sections marked as Experimental will not be discussed.
One of the early sections discusses the important CIM concepts used by the SMI-S 1.1.0.
For example, it describes the commonly used Classes such as CIM_Product,
CIM_PhysicalPackage and CIM_LogicalDevice. The section explains how a Client uses
the CIM_RegisteredProfile and CIM_RegisteredSubprofile Classes to determine the
capabilities of a SMI Agent.
Naming
CIM Object Names uniquely locate CIM objects amongst SMI Agents in an enterprise
network. However, CIM objects are simply CIM data model representations of real world
objects. The SMI-S 1.1.0 discusses Durable Names which allow a Client to determine
when two different CIM Object Names refer to the same real world SAN resource. The
specification defines the recognized Durable Name formats for several types of SAN
resources which are
SCSI Logical Units that are exported from storage systems

External Ports on hosts and storage devices
Fibre Channel ports on interconnect elements
Fibre Channel fabric
Storage systems
Operating system device
Health and Fault Management

The SMI-S 1.1.0 defines a uniform approach for interpreting status and detecting an error
or fault condition in a SAN resource and discusses this topic in one of its introductory
sections. The specification identifies three methods for a Client to detect error or fault
conditions. They are
Poll SAN resources and determine their status by examining the HealthState and
OperationalStatus properties. The interpretation of the HealthState and
OperationalStatus property value combinations will be vary from device to device.
For example, OperationalStatus = Stopped can have a different meaning for a FC
Port than for a Disk Drive.
Evaluate errors that might be received from CIM Operations performed against a
SAN resource.
Use the indication mechanism to be notified when certain error conditions occur.
Use of Profiles and Subprofiles

After the introductory sections, much of the remaining content in the SMI-S 1.1.0 is
devoted to explaining each Profile and Subprofile in sufficient detail to allow full and
proper implementation by a developer. In the SMI-S 1.1.0, Profiles and Subprofiles are the
cornerstone for achieving interoperability.
To perform a particular management function on a SAN device using CIM, a vendor must
decide upon the set of CIM Classes that will be used. The CIM Schema defines almost
two thousand Classes. To achieve interoperability, a Client and SMI Agent must use the
same set of CIM Classes. More specifically, for every Class used by a Client, a Provider
for that Class must exist on the SMI Agent. Otherwise, a Client may attempt a WBEM
operation that will fail because the SMI Agent has no Provider for the requested Class.
However, even if the same Classes are used, interoperability is still not guaranteed
because the same Properties within each Class must also be used. For example, a Client
may assume that a Property of a Class has a meaningful value. If the provider on the SMI
Agent for that Class does nothing with that Property, then the Client will not operate
properly. Similarly, a Client and SMI Agent must also use the same Extrinsic Methods for
each Class.
If the Client and SMI Agent are developed by the same vendor, then obtaining agreement
on the Classes, Properties and Extrinsic Methods is a manageable intra company
problem. However, if the Clients and SMI Agents are developed by different vendors, the
probability that they would independently choose these same CIM elements is very low.
Hence, the motivation for defining Profiles in SMI-S is to get agreement amongst SAN
vendors on the Classes, Properties and Extrinsic Methods that will be used to perform a
particular management function. For this purpose, industry experts from SNIA member
companies meet and work within Technical Work Groups (TWG) to define such Profiles
and add them to SMI-S. For example, the Disk Resource Management TWG works on the
Storage related Profiles and Subprofiles.
When a vendor chooses to implement an SMI-S Profile, the specification requires that ALL
CIM elements defined in the Profile must be implemented. In other words, if a Profile
identifies eight CIM Classes, then providers for all eight Classes must be implemented.
Likewise, if a Profile identifies that ten of the Properties of a CIM Classes must be
supported, then the implementation of the provider for that Class must ensure that ALL ten
Properties are populated with meaningful values. The vendor cannot pick and choose
which Properties to populate, but must populate them all. However, if the Class has
additional Properties defined, a vendor can choose to populate any of the additional
Properties.
Similarly, if a Profile identifies that three Extrinsic Methods of a CIM Class must be
supported, then the implementation of the provider for that Class must ensure that all
three Extrinsic Methods are implemented. Once again, the vendor cannot pick and choose
which Extrinsic Methods to implement but must implement them all. However, if a Class
has additional Extrinsic Methods defined, a vendor can choose to implement any of the
additional Extrinsic Methods.
Discovery
The SMI-S 1.1.0 requires the use of the Service Location Protocol (SLP) version 2 to allow
Clients to discover SMI Agents on a SAN. The specification devotes one section to explain
SLP fundamentals such as the definitions of a User Agent (UA), Service Agent (SA) and
Directory Agent (DA). It describes the SLP Template attributes that are required by the
SMI-S 1.1.0.
identifies the base set of SLP messages that must be supported by a UA, SA and DA.
Some SLP messages allow a UA to request SLP Templates from a SA or DA. Others
allow a SMI Agent to register their SLP Template with a SA or DA.
SMI-S Roles
One section in the SMI-S 1.1.0 discusses the requirements for the various components in
an SMI environment. The specification also identifies the different environments in which a
SMI Agent can operate; i.e., the various roles that a SMI Agent can have. A SMI Agent
can either be a Dedicated SMI-S Server or a General Purpose SMI-S Server. A Dedicated
SMI-S Server manages just one storage resource. The SMI-S 1.1.0 identifies two types of
Dedicated SMI-S Servers. An Embedded Dedicated SMI-S Server is one that is directly
incorporated into its managed storage resource and does not involve separate software
installation steps to become operational. A Proxy Dedicated SMI-S Server is one that is
hosted on a system separate from its managed storage resource and communicates with
the remote resource using a network protocol. A General Purpose SMI-S Server can
manage several storage resources at the same time. Typically, Direct Attached Storage
(DAS) and Host Based Adapters (HBA) are located on a General Purpose SMI-S Server.
SMI Tutorial > SMI-S 1.1.0 Overview > How to Read SMI-S 1.1.0 > How to Read a Profile
Introduction
Storage Management
Initiative
How to Read a Profile
SMI-S 1.1.0
Much of the SMI-S 1.1.0 is devoted to describing each Profile and Subprofile in sufficient
Functionality
detail to allow full and proper implementation by a developer. Their descriptions use the
same pattern, which consists of
Resources and
References
General Description
Questions & Answers Instance Diagrams
List of supported Subprofiles
List of incorporated Packages
Interpretation of the HealthState and OperationalStatus properties
Description of the defined Recipes
CIM Server Requirements
List of mandatory and optional CIM Classes that must be implemented
List of mandatory and optional Indication Filters that must be supported
For each CIM Class, the list of mandatory and optional Properties and Extrinsic
Methods
The standards specifications dependencies
The General Description describes how the CIM elements of the Profile are used. In
particular, it explains the mapping of the technology components managed by the Profile
to the CIM Classes and Properties in the Profile. For example, the Fabric Profile includes
a table that maps the various Port types (i.e., N-port, E-port, etc) to the RequestedType
property in the FCPortSetting class.
To show CIM elements in diagram form, the SMI-S 1.1.0 uses a variation of the Unified
Modeling Language (UML) standard specification from the Object Management Group
(OMG). The General Description often includes Instance UML diagrams that show the
important CIM elements that are used by the Profile.
A Profile can identify Subprofiles that represent optional functionality that a vendor can
choose to implement to enhance the Profile capabilities. If a Profile supports other
Subprofiles, they are listed in a table. For example, the following table shows that the
Profile recognizes the Access Points, Disk Drive Lite, Location and Software Subprofiles.
All are optional Subprofile. All are version 1.1.0
Registered Subprofile Name Mandatory Version

Access Points No 1.1.0
Disk Drive Lite No 1.1.0
Location No 1.1.0
Software No 1.1.0
If the Profile includes CIM elements that contain the HealthState and OperationalStatus
properties, then a table is shown that defines how to interpret their possible values. For
example,
Possible Subsidiary
Operational Status Description
Operational Status
OK The system has good status
The system will probably fail sometime
Degraded
soon
A severe error has occurred. Operator
Error Non-recoverable error
intervention is unlikely to fix it
Stopping The system is shutting down
If the Profile requires that some Extrinsic Methods be supported, then the specification
explains what each Method accomplishes. The Profile shows the Method signature and
explains how each Method argument is used.
If a Profile supports active management, then the specification also describes the
management tasks that can be performed via Intrinsic Methods such as createInstance or
deleteInstance. For example, the Fabric Profile explains that the management task of
Zone deletion is accomplished by performing a deleteInstance operation.
A Profile can define Recipes that a Client may use to perform a particular management
task on the elements managed by the Profile. In the SMI-S 1.1.0, the Recipe name is
followed by the descriptive comments and Perl-like expressions that comprise the Recipe.
For example, the Fabric Profile lists the Recipes for the following management tasks:
Discover The Fabric Topology

HBA to switch paths
Determine logical path from Switch to Storage Arrays
Determine the active Zone Set in a SAN
Next, the Profile shows a table listing the CIM Server functional requirements for the
Profile. Examination of this table allows easy determination of two important Profile
characteristics. If BasicWrite has a value of No, then the Profile is Read-Only meaning
that active management and use of Extrinsic Methods is not allowed. If Indications has a
value of No, then a Client cannot ask to be notified when a particular event occurs within
the context of this Profile.
The Profile shows a summary table listing the mandatory CIM Classes that must be
implemented for the Profile. Optional CIM Classes that a vendor can choose to implement
to provide additional capability are also identified. For example, the following table shows
that the Profile defines two classes that must be implemented, CIM_ComputerSystem and
CIM_FileShare. The Profile also defines one option class, CIM_StorageExtent, that a
vendor can choose to implement.
Element Name Description
Mandatory Classes
This declares that at least one computer system
CIM_ComputerSystem (pg. 863) must pre-exist
Represents the sharing characteristics of a
CIM_FileShare (pg. 886) particular file element
Optional Classes
CIM_StorageExtent (pg. 890) Represents the LUNs that are imported
The Profile shows a table listing the mandatory Indication Filters that must be supported.
Optional Indication Filters that a vendor can choose to support to provide additional
capability are also listed. For example, the following table shows that the Profile allows a
Client to be notified when a new array comes online.
Element Name Description

Mandatory Indications
SELECT * FROM CIM_InstCreation
WHERE SourceInstance ISA Addition of a new array instance
CIM_ComputerSystem
After the summary tables, the Profile shows a table for each identified CIM Class. Each
table lists the mandatory Properties in the CIM Class that must be implemented. Optional
Properties that a vendor can choose to support to provide additional capability are also
listed. For some Properties, the Description field show a required value or set of values for
that Property. For example, the following table shows that the Profile allows a Client to
retrieve information about the FC Port. An implementation must ensure that the
SystemName, OperationalStatus and LinkTechnology properties in the CIM_FCPort class
have values. The SystemName is a string property. The OperationalStatus is an array of
unsigned 16-bit integers.The LinkTechnology property is an integer whose value will be
the integer value that represents "FC". The implementation can optionally choose to
populate the ElementName string property.
SMI Referenced Properties/Methods for CIM_FCPort
Property Flags Type Description and Notes

Mandatory Properties/Methods
SystemName string The scoping System's name
One of the defined values shall be
OperationalStatus uint16[]
present
LinkTechnology uint16 "FC"
Optional Properties/Methods
ElementName string Port symbolic name
Finally, the Profile shows a table listing the standards upon which it depends. For
example, the following table shows that the Profile depends upon the DMTF CIM
Infrastructure Specification version 2.3.0, the DMTF CIM Operations over HTTP
specification version 1.2.0 and the DMTF CIM Schema version 2.11.0.
Specification Revision Organization

CIM Infrastructure Specification 2.3.0 DMTF
CIM Operations over HTTP 1.2.0 DMTF
CIM Schema 2.11.0 DMTF
SMI Tutorial > SMI-S 1.1.0 Overview > How to Read SMI-S 1.1.0 > How to Read a Recipe
Introduction
Storage Management
Initiative
How to Read a Recipe
SMI-S 1.1.0
A Profile, Subprofile or Package can define Recipes that a Client may use to perform a
Functionality
particular management task on the elements being managed. Using comments and PERL-
like expressions, a Recipe describes the specific WBEM operations that must be
Resources and
References
performed, the order in which they must be performed and the argument values to be
used for each WBEM operation.
Questions & Answers
A Recipe typically has the following components:
Description - describes the purpose of the Recipe

Pre-Existing Conditions and Assumptions - lists the operations that have already
been performed before the Recipe is executed
Steps - explains each step of the Recipe
The following is an example Recipe from the Server Profile. This Recipe verifies that the
version of the Subprofiles match that of a particular Profile. The Recipe can be interpreted
as follows:
Step 1 performs the WBEM operation GetInstance to an instance of

CIM_RegisteredProfile and then extracts the Profile version number from the
instance.
Step 2 retrieves all instances the Subprofiles of the Profile using the Associators
WBEM operation and then extracts the Subprofile version number from returned
instances
Step 3 compares each Subprofile version number to the Profile version number
// DESCRIPTION
// A management application wishes to determine the optional subprofiles
// supported by a SNIA Profile.
//
// PRE-EXISTING CONDITIONS AND ASSUMPTION
// 1.Assume the client has already discovered the CIM Server that
// supports the SNIA profile
// 2.Assume the client already has a $ObjectManager-> reference for
// the CIMOM on the WBEM Server.
// 3.Assume the client already has a $RegisteredProfile-> reference
// for the profile in question.
// Step 1: Check the version of the supported profile. Based on the

// RegisteredVersion property, the client should know what functions
// are REQUIRED as part of the profile definition.
$Profile = GetInstance($RegisteredProfile->)
#ProfileVersion = $Profile.RegisteredVersion
// Step 2: For each Profile, traverse the SubProfileRequiresProfile

// association to determine what optional subprofiles are also
// supported. If the subprofile (e.g., CopyServices subprofile)
// exists for a profile, this means that the copy services are
// supported. The Copy Services also has a Version
// (RegisteredSubProfile.RegisteredVersion). The RegisteredVersion
// of the subprofile MUST match the RegisteredVersion of the profile.
// The RegisteredVersion implies a set of functional capabilities
// that are defined for that version of the subprofile.
$Subprofiles[ ] = Associators (
$RegisteredProfile->,
CIM_SubProfileRequiresProfile,
CIM_RegisteredProfile,
NULL, NULL, false, false, NULL)
// Step 3: Verify that each Subprofile has the same version as the
// Profile
for #i in $Subprofiles[ ] {
#SubprofileVersion = $Subprofile[#i].RegisteredVersion
if (!compare(#SubprofileVersion, #ProfileVersion)) {
Error(Subprofile version mismatch with Profile version)
}
}
SMI Tutorial > SMI-S 1.1.0 Functionality
Introduction
Storage Management
Initiative
SMI-S 1.1.0 Functionality
CIM and WBEM Basics Profiles | Subprofiles | Packages
SMI-S 1.1.0 Overview The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN)
SMI-S 1.1.0
storage systems. The SMI-S 1.1.0 achieves this goal by using the Common Information
Functionality
Model (CIM), Web Based Enterprise Management (WBEM) and by defining Profiles and
Resources and
Subprofiles.
References
A Profile defines the base set of information and capabilities that allows a Client to
Questions & Answers manage a particular storage resource. It defines all the CIM elements (Classes,
Associations, Properties, Methods, etc) that a Client must use to perform a particular task.
A Subprofile defines additional CIM elements that a vendor may choose to implement in
order to enhance a Profile. Doing so allows a Client to use additional features of the
vendor's product.
The following sections describe Profile and Subprofiles in more detail. Then, the tutorial
provides more specific information about each Profile and Subprofile defined in the SMI-S
1.1.0.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles
Introduction
Storage Management
Initiative
SNIA Profiles
SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host
SMI-S 1.1.0
A SNIA Profile defines the base set of information and capabilities that all implementations
Functionality
must make available to allow a Client to manage a particular SAN device such as a disk
array. It defines the classes that a Client will use to perform a particular management task
Resources and
References
in a SAN. The Profile also defines the associations that will be used to traverse between
classes. In addition to identifying the classes used, a Profile also defines the properties
Questions & Answers and extrinsic methods of each class that must be supported. In certain cases, the Profile
even specifies the values a property or method argument must have.
In many Profiles, one class is identified as the entry point for managing the
implementation for the Profile. This class is called the top level system. Starting with this
class, a Client traverses the associations defined in the Profile to access the properties or
extrinsic methods contained in the other classes.
A Profile can allow a Client to be notified when a particular event occurs. To be notified, a
Client must subscribe for an Indication using the filter defined in the Profile. Additionally,
the SMI Agent must be able to detect such changes in its environment and deliver the
notification to subscribed Clients. A Profile defines all filters that a Client can use and that
an SMI Agent must recognize and support.
A Profile can define Recipes that a Client may use to perform a particular management
task on the elements managed by the Profile. Using comments and PERL-like
expressions, a Recipe describes the specific WBEM operations that must be performed,
the order in which they must be performed and the argument values to be used for each
WBEM operation.
A Profile can define Subprofiles which represent additional capability that a vendor can
choose to make available. Like Profiles, Subprofiles define the classes, properties and
extrinsic methods that must be implemented to support its functionality. However,
implementation of Subprofiles is considered optional because some vendors may not offer
the Subprofile functionality in their product. For example, some disk array products do not
support the ability to create snapshots or replicas.
A Profile can incorporate Packages. Like Profiles, a Package defines the classes,
properties and extrinsic methods that must be implemented to support its functionality.
However, unlike Subprofiles, implementation for the classes, properties and extrinsic
methods in a Package is mandatory, not optional. In other words, when a Package is
referenced by a Profile, all of its CIM elements are considered to be part of the Profile.
A Profile specifies the standards upon which the Profile is based. For example, in SMI-S
1.1.0, the Array Profile is based upon the CIM Schema version 2.11, the CIM Operations
over HTTP Specification version 2.3 and the CIM Infrastructure Specification version 1.2.
WBEM operations are grouped by function into sets of operations called functional
profiles. For example, the Basic Read functional profile consists of read operations such
as GetInstance and EnumerateInstances. A Profile defines the functional profiles that a
SMI Agent must support. For example, the Array Profile specifies that the SMI Agent must
support the Basic Read, Association Traversal and Indications functional profiles.
In SMI-S 1.1.0, the Profile elements described above are explicitly defined in Extensible
Markup Language (XML) files, one XML file for each Profile. For example, the Array
Profile is defined in Array.xml.
In SMI-S 1.1.0, the following groups of Profiles have been defined:
Storage - several Profiles have been defined to manage different types of storage
devices
Host - two Profiles have been defined to manage components attached to host
systems
Fabric Topology - two Profiles have been defined to manage the Fabric topology
Server - one Profile has been defined to manage the SMI Agent
SMI Tutorial > SMI-S 1.1.0 Functionality > Fabric Topology Profiles
Introduction
Storage Management
Initiative
Fabric Topology Profiles
SMI-S 1.1.0 Fabric | Switch

Functionality
SMI-S 1.1.0 defines the following Profiles that relate to the management of Fabric
Resources and
topology:
References
Questions & Answers Fabric - allows a Client to manage the Nodes and Ports in a Fibre Channel Fabric
Switch - allows a Client to manage a Fibre Channel Switch device
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Fabric Topology Profiles > Fabric Profile
Introduction
Storage Management
Initiative
Fabric Profile

Functionality
The Fabric Profile allows a Client to manage a Fibre Channel Fabric. In a Fabric, a Node
Resources and
is a source or destination of information for one or more other Nodes. Each Node can use
References
one or more Ports as the physical connection to the Fabric for receiving or transmitting
Questions & Answers data. Disk arrays and tape libraries have a fixed number of physical Ports. Hence, they
can only be attached to a limited number of systems. A Fabric provides a more flexible
alternative. Physical Ports can instead be connected to a Fabric to create a SAN that
allows devices to be shared amongst many servers.
Using this Profile, a Client can do the following:
Enumerate all the Switches, Systems and directly attached devices on the Fabric
Enumerate all the Ports on each Switch, System or directly attached device
Enumerate all the Nodes on the Fabric
Enumerate all the Zones and Zone Sets on the Fabric
Determine the active Zone Set
Ask to be notified when a Switch, System or Port is added to or removed from the
Fabric
Ask to be notified when the operational status of a Switch, System or Port changes
(e.g., from OK to Degraded)
Ask to be notified when Zone change occurs
Ask to be notified when a Zone Set is activated
Ask to be notified when a Port is added to or removed
This Profile exposes information about the Fabric, the Zones within the Fabric and the
Nodes and Ports that are connected to the Fabric. To access the information exposed by
this Profile, a Client starts with the CIM element that represents the Fabric. From there,
the Client can discover the Zones, Nodes and Ports and then retrieve information about
each of them.
For the Fabric, a Client can retrieve information such as its WWN name, configuration and
capabilities. For example, a Client can determine whether the Fabric supports Domain ID
locking, which principal priorities are supported, or which state changes are supported
(e.g., Dormant, Stopped, etc). Similarly, a Client can retrieve the current preferred
Domain ID and principal priority of the Fabric and discover the version and Manufacturer
of the installed software or firmware. Finally, this profile allows a Client to obtain the
product vendor and model number for asset inventory purposes.
For the Ports, a Client can retrieve statistics, configuration and determine its capabilities.
For example, a Client can retrieve information such as its WWN name, port type (e.g.,
bridge, fabric, node, etc) and its current and maximum speed. Similarly, a Client can
determine which types and speeds the Port is capable of supporting. The Profile also
defines two groups of statistics to be collected. One group relates to actual Port usage
such as the number of bytes and frames transmitted or received, or the number CRC
errors or link failures. There are many other optional statistics that a vendor can also
choose to collect and make available. The other group relates to the rate statistics for the
Port such as the data transfer and receive rates (average and peak) and the frame
transfer and receive rates (average and maximum).
For the Nodes, a Client can retrieve its WWN name and enumerate the Ports that it uses.
For the Zone Sets, a Client can enumerate its constituent Zones. Likewise, for Zones, a
Client can enumerate its constituent Members.
The Profile defines Subprofiles that represent optional features that a vendor may choose
to support in their Fabric product. They are:
Zone Control allows a Client to actively manage Fabric zoning

Enhanced Zone and Enhanced Zoning Control - allows a Client to actively manage
Zone Aliases
FDMI - allows a Client to manage HBA's
Fabric Path Performance - allows a Client to retrieve performance statistics for the
path between an Initiator Port and Target Port
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Fabric Topology Profiles > Switch Profile
Introduction
Storage Management
Initiative
Switch Profile

Functionality
The Switch Profile allows a Client to manage a Fibre Channel Switch device. Disk arrays
Resources and
and tape libraries typically have a fixed number of physical Ports. Hence, they can only be
References
attached to a limited number of systems. Alternatively, their physical Ports can be
Questions & Answers connected to a Switch to create a SAN that allows them to be shared amongst many
servers.
Enable, disable or reset the Switch device

Enumerate the Ports on a Switch
Enable or disable the Ports on a Switch
Set the Switch WWN name, Domain ID and preferred Domain ID
Set the Port WWN name, speed and type (e.g., bridge, fabric, node, etc)
Ask to be notified when a Switch is enabled or disabled
Ask to be notified when the operational status of a Port changes (e.g., from OK to
Stopped)
This Profile exposes information about the Switch device and the Ports that might be
connected to it. For the Switch, a Client can retrieve information such as its WWN name,
configuration and capabilities. For example, a Client can determine whether the Switch
supports Domain ID locking, which principal priorities are supported, or which state
changes are supported (e.g., Dormant, Stopped, etc). Similarly, a Client can retrieve
the current preferred Domain ID and principal priority of the Switch and determine the
version and Manufacturer of the installed software or firmware. Finally, this Profile allows a
Client to obtain the product vendor and model number for asset inventory purposes.
For the Ports, a Client can retrieve its statistics, the configuration and capabilities. For
example, a Client can retrieve information such as its WWN name, port type (e.g., bridge,
fabric, node, etc) and its current and maximum speed. Similarly, a Client can determine
which types and speeds are supported by the Port. The Profile also defines two groups of
statistics to be collected. One group relates to Port usage such as the number of bytes
and frames transmitted or received, or the number CRC errors or link failures. There are
many other optional statistics that a vendor can also choose to collect and make available.
The other group relates to the rate statistics for the Port such as the data transfer and
receive rates (average and peak) and the frame transfer and receive rates (average and
maximum).
The Profile can be augmented by the following Subprofiles that represent optional features
that a vendor may choose to support in their Switch product:
Blades - allows a Client to manage a Director Class Switch

Access Points - allows a Client to discover remote management interfaces to the
device
Switch Configuration Data - allows a Client to retrieve and change the configuration
of the Switch
Multiple Computer System - allows a Client to retrieve information about the
redundancy configuration and capabilities of a fault tolerant system
Software Installation Service - allows a Client to find and install software onto the
Switch
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Server Profile
Introduction
Storage Management
Initiative
Server Profile
SMI-S 1.1.0
The Server Profile allows a Client to manage and retrieve information about a SMI Agent
Functionality
and its components. Using this Profile, a Client can do the following:
Resources and
References Find the SMI Agents on a network that support a particular Profile
Determine all the Profiles and Subprofiles supported by a particular SMI Agent
Questions & Answers Find the entry point for managing the implementation of a particular Profile.
Determine the SNIA version of a Profile.
Determine the optional Subprofiles that a particular Profile supports.
Find all the SNIA Profile and Subprofiles on a particular SMI Agent
Find only those SMI Agents that allow management of a particular SAN device
Find all the namespaces managed by a SMI Agent
A Client can retrieve information about the Profiles that have been registered with the SMI
Agent. For example, a Client can obtain information about the name (e.g., "Server") of a
registered Profile, or how the Profile will be advertised (e.g., "SLP") and the Profile's
registered organization (e.g., "SNIA"). A Client can retrieve similar information about
registered Subprofiles. As an optional capability, the Profile defines that the Client can be
notified when a new Profile is registered or when an existing registered Profile is removed.
A Client can retrieve information information about the instrumentation software running
on the SMI Agent. For example, a Client can obtain information about the Manufacturer
and version number of the software used to support the Server Profile. Optionally, a
vendor may choose to show the product identification information for the software as well
such as the vendor name and an identifying number.
A Client can retrieve information about the capabilities of the CIM-XML management
protocol. For example, a Client can determine whether the authentication mechanism
used is Basic or Digest. Basic authentication sends user name and password in clear text
while Digest sends user name and password in more secure form. Additionally, a Client
can determine the types of WBEM operations (e.g., writes, association traversal,
indications, etc) it can perform on the SMI Agent and whether the SMI Agent supports
batch operations.
A Client can retrieve information about the SMI Agent such as its operational status. With
proper authorization, a Client can also shutdown the SMI Agent.
The Server Profile defines the following Subprofiles that represent optional features that a
vendor may choose to support:
Object Manager Adapter - allows a Client to manage the adapter component of the
SMI Agent.
Indications - allows a Client to be notified when a particular event occurs.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles
Introduction
Storage Management
Initiative
Storage Profiles
SMI-S 1.1.0 Array | Volume Management | NAS Head | Self-Contained NAS System
Functionality Storage Library | Storage Virtualizer
Resources and
In SMI-S 1.1.0, several Profiles are defined for managing storage devices on a Storage
References
Area Network (SAN). Each Profile is focused on a different aspect of storage device
Questions & Answers
management. These devices are:
Array - allows a Client to manage an external RAID array or disk storage system
Volume Management - allows a Client to manage physical disks as logical devices
called volumes.
NAS Head - allows a Client to manage a Network Attached Storage system that
exposes logical storage capacity such as filesystems but gets its actual capacity
from external SAN storage resources
Self-contained NAS System - allows a Client to manage a Network Attached
Storage system that exposes logical storage capacity such as filesystems but gets
its actual capacity from local storage that must also be managed
Storage Library - allows a Client to manage a storage system that has mechanisms
for retrieving data from different physical forms of storage media
Storage Virtualizer - allows a Client to manage a storage system that does not
directly include any local storage.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Array Profile
Introduction
Storage Management
Initiative
Array Profile
Resources and
The Array Profile allows a Client to manage external RAID arrays and disk storage
References
systems. Using this Profile, a Client can do the following:
Questions & Answers
Ask to be notified when a new array comes online
Ask to be notified when an array goes offline
This Profile provides the base functionality. The rest of the storage system features is
provided by incorporating other Packages and SubProfiles.
By incorporating the Block Services Package as part of the Array Profile, a Client can
manage the storage pools, storage volumes and logical disks on the array. Specifically, a
Client can do the following:
Enumerate, create or delete a Storage Pool, Storage Volume or Logical Disk

Change the capacity of a Storage Pool, Storage Volume or Logical Disk
Return allocated capacity to a Storage Pool
Enumerate the Extents in a Storage Pool that may be used to create or expand a
Storage Volume or Logical Disk
Ask to be notified when a new Storage Pool, Storage Volume or Logical Disk is
created or deleted
Ask to be notified when the operational status of a Storage Volume or Logical Disk
changes (e.g., from OK to Degraded)
By incorporating the Physical Package Package as part of the Array Profile, a Client can
retrieve physical information about the array hardware. For example, a Client can retrieve
the version or serial number. Additionally, a Client can retrieve product information about
the array hardware. For example, a Client can retrieve the vendor name and an
identification number (e.g., SKU).
By incorporating the Health Package as part of the Array Profile, a Client can retrieve
information about the status (e.g., OK, Degraded, Stopped, etc.) of the disk array. A
Client can also retrieve information about the state of a disk array component such as a
disk drive.
The Array Profile defines the following Subprofiles that represent optional features that a
vendor may choose to support in their array product:
device
Block Server Performance - allows a Client to manage the collection and retrieval of
performance statistics for the disk array
Drive Lite - allows a Client to retrieve information about the disk drives in the disk
array
Extent Composition - allows a Client to retrieve information about the allocation
hierrarchy of storage pools, storage volumes and logical disks within the disk array
Location - allows a Client to retrieve information about the physical location of the
disk array
Software - allows the Client to retrieve information about the software or firmware
installed on the disk array
Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and
snapshots in the disk array
Job Control - allows a Client to asynchronously monitor a long running operation on
the disk array
Device Credentials - allows a Client to change the shared secret (i.e., password)
that is used to control access to the disk array
Masking and Mapping - allows a Client to manage the access to the LUNs attached
to the target ports on a storage system using the Masking and Mapping
mechanisms
FC Target Ports - allows a Client to discover all of the FC ports of the disk array that
are acting as target ports
Disk Sparing - allows a Client to manage spare logical disks that can be used in
place of a failed component in the disk array.
FC Initiator Ports - allows a Client to discover all of the FC ports of the disk array
that are acting as initiator ports
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Volume Management
Introduction
Profile
Storage Management
Initiative
Volume Management Profile
CIM and WBEM Basics
Fabric Topology | Server | Storage | Host
SMI-S 1.1.0
Functionality Array | Volume Management | NAS Head | Self-Contained NAS System
Storage Library | Storage Virtualizer
Resources and
References
The Volume Management Profile allows a Client to manage storage as virtual resources
Questions & Answers
using a software storage management subsystem running on a host system. Such a
subsystem is called a host volume manager. By using software RAID techniques, a host
volume manager can provide features similar to hardware disk arrays. If the volume
manager software is embedded (e.g., in a Switch), then the Storage Virtualizer Profile
should be used instead.
Creating virtual storage starts by allocating Primordial Pools from physical disk capacity.
Then, unassigned space from one or more Primordial Pools is allocated to create a
Storage Pool. Next, unassigned space from one or more Storage Pools is allocated to
create a Logical Disk (i.e., volume). A host system treats Logical Disks as if they were
physical drives.
This Profile provides the base functionality. The rest of the Profile features is provided by
incorporating other Packages and Subprofiles.
A Client can retrieve information about the fault tolerant capabilities and current fault
tolerant settings of the storage managed by this Profile. For example, a Client can
determine the number of spindles (i.e., package redundancy) and the number of copies
(i.e., data redundancy). Where data redundancy is possible, a Client can determine the
amount of space on a replica for caching changes (i.e., delta reservation).
By incorporating the Block Services Package as part of the Volume Management Profile,
a Client can manage the storage pools, storage volumes and logical disks. Specifically, a
Client can do the following:
Enumerate, create or delete a Storage Pool or Logical Disk

Change the capacity of a Storage Pool or Logical Disk
Enumerate the Extents in a Storage Pools that may be used to create or expand a
Logical Disk
Ask to be notified when a new Storage Pool or Logical Disk is created or deleted
Ask to be notified when the operational status of a Logical Disk changes (e.g., from
OK to Degraded)
By incorporating the Health Package as part of the Volume Management Profile, a Client
can retrieve information about the status (e.g., OK, Degraded, Stopped, etc.) of the
volume manager. A Client can also retrieve information about the state of the other
storage system components that help to provide fault tolerance.
The Volume Management Profile defines the following Subprofiles that represent optional
features that a vendor may choose to support in their array product:

device
Block Server Performance - allows a Client to manage the collection and retrieval of
performance statistics for the device
Block Services Resource Ownership - allows a Client to manage the ability to grant
or deny access to the Logical Disk
hierarchy of storage pools and logical disks within the device
system hosting the device
snapshots in the virtual array
the virtual array
redundancy configuration and capabilities of the virtual array
Software - allows the Client to retrieve information about the software used for
managing virtual storage
Disk Sparing - allows a Client to manage spare disks that can be used to provide
redundancy in a storage system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > NAS Head Profile
Introduction
Storage Management
Initiative
NAS Head Profile
Resources and
The NAS Head Profile allows a Client to manage File Systems and File Shares on a
References
Network Attached Storage (NAS) system that does not include local storage. Instead, the
Questions & Answers
NAS Head system uses external storage resources for its storage capacity. The NAS
establishes a data path from one of its initiator ports to a target port on another storage
system.
A File System is created on a Logical Disk which is allocated from a Storage Pool. A File
Share is a file or directory that can be accessed over a network using a file protocol such
as the Network File System (NFS) protocol or the Common Internet File System (CIFS)
protocol.
Enumerate the existing File Systems and Files Shares on the NAS
Ask to be notified when the operational status of File System or File Share changes
(e.g., from OK to Error)
Ask to be notified when the operational status of the NAS system changes (e.g.,
from OK to Error)
Ask to be notified when the operational status of the initiator port changes (e.g.,
from OK to Error)
Ask to be notified when the operational status of a NFS or CIFS connection
changes (e.g., from OK to Error)
A Client can retrieve information about the File Systems on the NAS system. For example,
a Client can determine the File System name, the amount of available space and the
block size. A Client can also determine whether file names are case sensitive for the File
System. Optionally, a vendor can choose to expose information about the number of files,
the code set used and whether the File System is read-only.
A Client can retrieve information about any File Shares on the NAS system. For example,
a Client can determine the file protocol used (e.g., NFS or CIFS) and the file protocol
version number. A Client can also determine the name of the directory that is shared.
This Profile provides the base functionality. The rest of the NAS system features is
provided by incorporating other Packages and SubProfiles.
By incorporating the Block Services Package as part of the NAS Head Profile, a Client can
manage the storage pools, storage volumes and logical disks on the NAS system.
Specifically, a Client can do the following:

OK to Degraded)
By incorporating the Health Package as part of the NAS Head Profile, a Client can retrieve
information about the status (e.g., OK, Degraded, Stopped, etc.) of the NAS system.
If the NAS system has fault tolerant features, a Client can also retrieve information about
the state of the other NAS system components that provide the fault tolerance.
By incorporating the Physical Package Package as part of the NAS Head Profile, a Client
can retrieve physical information about the NAS system hardware. For example, a Client
can retrieve the version or serial number. Additionally, a Client can retrieve product
information about the NAS system hardware. For example, a Client can retrieve the
vendor name and an identification number (e.g., SKU).
The NAS Head Profile defines the following Subprofiles that represent optional features
that a vendor may choose to support in their NAS system product:

device
hierarchy of storage pools and logical disks within the NAS system
NAS system
snapshots in the NAS system
the NAS system
redundancy configuration and capabilities of the NAS system
Software - allows the Client to retrieve information about the software used by the
NAS system
FC Initiator Ports - allows a Client to discover all of the FC ports of the NAS system
SPI Initiator Ports - allows a Client to discover all of the Parallel SCSI ports of the
NAS system that are acting as initiator ports
iSCSI Initiator Ports - allows a Client to discover all of the iSCSI ports of the NAS
system that are acting as initiator ports
that is used to control access to the NAS system
File Export Manipulation - allows a Client to manage File Shares on the NAS
system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Self Contained NAS
Introduction
System Profile
Storage Management
Initiative
Self-Contained NAS System Profile
CIM and WBEM Basics
Fabric Topology | Server | Storage | Host
SMI-S 1.1.0
Functionality Array | Volume Management | NAS Head | Self-Contained NAS System
Storage Library | Storage Virtualizer
Resources and
References
The Self-Contained NAS System Profile allows a Client to manage File Systems and File
Questions & Answers
Shares on a Network Attached Storage (NAS) system that includes local storage. In
contrast, a NAS Head system uses external storage resources for its storage capacity.
The hierarchy of storage is as follows. Primordial Pools are created from physical disk
capacity. Then, unassigned space from one or more Primordial Pools is allocated to
create a Storage Pool. Next, unassigned space from one or more Storage Pools is
allocated to create a Logical Disk.
A File System is created on a Logical Disk. A File Share is a file or directory that can be
accessed over a network using a file protocol such as the Network File System (NFS)
protocol or the Common Internet File System (CIFS) protocol.
Enumerate the existing File Systems and Files Shares on the NAS
Ask to be notified when the operational status of File System or File Share changes
(e.g., from OK to Error)
Ask to be notified when the operational status of the NAS system changes (e.g.,
from OK to Error)
Ask to be notified when the operational status of the initiator port changes (e.g.,
from OK to Error)
Ask to be notified when the operational status of a NFS or CIFS connection
changes (e.g., from OK to Error)
a Client can determine the File System name, the amount of available space and the
block size. A Client can determine whether file names are case sensitive for the File
System. Optionally, a vendor can choose to expose information about the number of files,
the code set used and whether the File System is read-only.
version number. A Client can also determine the name of the directory that is shared.
This Profile provides the base functionality. The rest of the NAS system features are
provided by incorporating other Packages and Subprofiles.
By incorporating the Block Services Package as part of the Self-Contained NAS System
Profile, a Client can manage the storage pools, storage volumes and logical disks on the
NAS system. Specifically, a Client can do the following:

OK to Degraded)
By incorporating the Health Package as part of the Self-Contained NAS System Profile, a
Client can retrieve information about the status (e.g., OK, Degraded, Stopped, etc.) of
the NAS system. If the NAS system has fault tolerant features, a Client can also retrieve
information about the state of the other NAS system components that provide the fault
tolerance.
By incorporating the Physical Package Package as part of the Self-Contained NAS

System Profile, a Client can retrieve physical information about the NAS system
hardware. For example, a Client can retrieve the version or serial number. Additionally, a
Client can retrieve product information about the NAS system hardware. For example, a
Client can retrieve the vendor name and an identification number (e.g., SKU).
The Self-Contained NAS System Profile defines the following Subprofiles that represent
optional features that a vendor may choose to support in their NAS system product:

device
hierarchy of storage pools and logical disks within the NAS system
NAS system
snapshots in the NAS system
Disk Drive Lite - allows a Client to retrieve information about the disk drives in the
NAS system
the NAS system
redundancy configuration and capabilities of the NAS system
NAS system
FC Initiator Ports - allows a Client to discover all of the FC ports of the NAS system
SPI Initiator Ports - allows a Client to discover all of the Parallel SCSI ports of the
NAS system that are acting as initiator ports
that is used to control access to the NAS system
File Export Manipulation - allows a Client to manage File Shares
File System Manipulation - allows a Client to manage File Systems
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Storage Library Profile
Introduction
Storage Management
Initiative
Storage Library Profile
Resources and
The Storage Library Profile allows a Client to manage a storage library and its
References
components. A storage library consists of the following components:
Questions & Answers
Storage media
Media access devices
Changer devices
Storage media containers
Storage media can be various types of physical media such as tape, CD, DVD, etc.
Storage media containers can also be of various types. Removable media is located in
slots or spaces. A magazine is a container for a group of storage media slots that are
handled as a unit. Other container forms can also be used such as a vault or shelf. A
media access device accesses the data on the storage media. The changer device moves
the physical storage media inside the storage library.
Discover the physical configuration of the storage library

Enumerate and retrieve information about the physical media in the storage library
Enumerate and retrieve information about the changer devices in the storage library
Enumerate and retrieve information about the media access device in the storage
library
Enumerate and retrieve information about the containers where the physical media
are stored in the storage library
Ask to be notified when a storage library comes online or goes offline
Ask to be notified when new physical media is added or removed
Ask to be notified when a media access device or changer device comes online or
goes offline
Ask to be notified when the status of a storage library, media access device or
changer device changes
A Client can retrieve information about the storage media. For example, a Client can
determine the type of storage media (e.g., tape, CD, DVD, etc). A Client can determine
the media's capacity and whether it is dual-sided or single sided media.
A Client can retrieve information about the changer devices. For example, a Client can
determine whether a changer device supports media flipping.
A Client can retrieve information about the media access devices. For example, if the
storage library supports removable media, a Client can determine how many times the
media has been mounted for data transfer. A Client can also determine whether the media
needs cleaning.
A Client can retrieve information about the physical security aspects of the storage library
chassis. For example, a Client can determine whether a chassis lock is present. A Client
can retrieve information about whether the chassis was locked or whether security was
breached.
A Client can determine the physical characteristics of the components that contain the
storage media.of the storage library. For example, a Client can determine the type of
container (e.g., slot, magazine, vault, etc.). A Client can discover the types of storage
media supported by the storage library (e.g., 8mm tape cartridge, CD, DVD, etc).
By incorporating the Physical Package Package as part of the Storage Library Profile, a
Client can retrieve physical information about the storage library chassis hardware. For
example, a Client can retrieve the version or serial number. Additionally, a Client can
retrieve product information about the storage library chassis. For example, a Client can
retrieve the vendor name and an identification number (e.g., SKU).
The Storage Library Profile defines the following Subprofiles that represent optional
features that a vendor may choose to support in their storage library product:

device
storage library and its components such as the storage media
FC Target Ports - allows a Client to discover all of the FC ports of the storage library
system that are acting as target ports
Software - allows the Client to retrieve information about the software or firmware
installed on the storage library and its components such as the changer device or
media access device
Storage Library Limited Access Port Elements - allows a Client to discover
information about the mechanisms of physical access used to transport physical
media into or out of a storage library
Additionally, the Storage Library Profile defines the following Experimental Subprofiles that
also represent optional features that a vendor may choose to support in their storage
library product. However, because the Subprofiles are classified as Experimental, their
contents may change.
Storage Library Media Movement

Storage Library Capacity
Storage Library Element Counting
Storage Library InterLibraryPort Connection
Storage Library Partitioned Library
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Storage Virtualizer Profile
Introduction
Storage Management
Initiative
Storage Virtualizer Profile
Resources and
The Storage Virtualizer Profile allows a Client to manage a RAID array that does not
References
include any local storage. Instead, the virtual storage system uses external storage
Questions & Answers
resources for the storage capacity it uses to create a seamless Storage Pool. Storage
Volumes are allocated from this virtual Storage Pool. Using this Profile, a Client can do the
following:
Ask to be notified when a storage system comes online

Ask to be notified when a storage system goes offline
Ask to be notified when the operational status of an FC Port or Ethernet Port
Ask to be notified when the operational status of the storage system changes (e.g.,
from OK to Degraded)
This Profile provides the base functionality. The rest of the virtual storage system features
is provided by incorporating other Packages and Subprofiles.
By incorporating the Block Services Package as part of the Storage Virtualizer Profile, a
Client can manage the storage pools, storage volumes and logical disks on the array.
Specifically, a Client can do the following:
Enumerate, create or delete a Storage Pool and Storage Volume

Change the capacity of a Storage Pool or Storage Volume
Storage Volume
Ask to be notified when a new Storage Pool or Storage Volume is created or
deleted
Ask to be notified when the operational status of a Storage Volume changes (e.g.,
from OK to Degraded)
By incorporating the Health Package as part of the Storage Virtualizer Profile, a Client can
retrieve information about the status (e.g., OK, Degraded, Stopped, etc.) of the
storage system. If the storage system has fault tolerant features, a Client can also retrieve
information about the state of the other storage system components that provide the fault
tolerance.
The Storage Virtualizer Profile defines the following Subprofiles that represent optional
features that a vendor may choose to support in their storage system product:

device
storage system
snapshots in the storage system
the storage system
hierarchy of storage pools and storage volumes within the storage system
redundancy configuration and capabilities of the storage system
storage system
FC Target Ports - allows a Client to discover all of the FC ports of the storage
system that are acting as target ports
FC Initiator Ports - allows a Client to discover all of the FC ports of the storage
system that are acting as initiator ports
Masking and Mapping - allows a Client to manage the access to the LUNs attached
to the target ports on a storage system using the Masking and Mapping
mechanisms
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles
Introduction
Storage Management
Initiative
Host Profiles
SMI-S 1.1.0 FC HBA | iSCSI Initiator

Functionality
SMI-S 1.1.0 defines the following Profiles that relate to the management of components
Resources and
attached to host systems:
References
Questions & Answers FC HBA - allows a Client manage the Fibre Channel (FC) ports on a system using a
Host Based Adapter (HBA)
iSCSI Initiator - allows a Client to manage the combination of hardware and drivers
on a host system that act as a client to a target SCSI device
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles > FC HBA Profile
Introduction
Storage Management
Initiative
FC HBA Profile

Functionality
The FC HBA Profile allows a Client manage the Fibre Channel (FC) ports on a system
Resources and
using a Host Based Adapter (HBA). Using this Profile, a Client can do the following:
References
Questions & Answers Discover the HBA topology

Retrieve statistics for each port
Retrieve the WWN for each port
Define the persistent binding to a target port WWN
Bind a LUN to an OS device name
Determine the OS device name assigned to a LUN
Blink the LED
Ask to be notified when new FC HBA hardware comes online
Ask to be notified when existing FC HBA hardware is disabled
Determine the software or firmware installed on the FC HBA hardware
Determine asset information about the FC HBA hardware
Determine the product information for the FC HBA hardware
This Profile allows a Client to retrieve statistics about an FC port. For example, a Client
can retrieve the number of bytes and frames transmitted or received. A Client also retrieve
the number CRC errors and link failures.
FC HBA ports can come in a variety of hardware configurations. For example, a single
HBA card may contain multiple FC ports. Alternatively, the FC ports may be integrated
into a motherboard. Regardless, a Client can retrieve physical information about the FC
HBA hardware. For example, a Client can retrieve the version or serial number.
Additionally, a Client can retrieve product information about the FC HBA hardware. For
example, a Client can retrieve the vendor name and an identification number (e.g., SKU).
Optionally, a Client can retrieve information about the software or firmware installed on FC
HBA hardware. For example, a Client can retrieve the name of the manufacturer and the
version number of the firmware installed on the FC HBA hardware. Optionally, a vendor
can choose to expose additional software information such as a build number.
The FC HBA Profile defines the following Subprofiles that represent optional features that
a vendor may choose to support:
FC Initiator Ports - allows a Client to discover all of the ports connected to a storage
system using Fibre Channel (FC) that are acting as initiator ports.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles > iSCSI Initiator Profile
Introduction
Storage Management
Initiative
iSCSI Initiator Profile

Functionality
The iSCSI Initiator Profile allows a Client to manage the combination of hardware and
Resources and
drivers on a host system that act as a client to a target SCSI device. This combination is
References
called an iSCSI initiator. Using this Profile, a Client can do the following:
Questions & Answers
Enumerate all the iSCSI connections
Enumerate all the iSCSI sessions
Ask to be notified when new iSCSI hardware comes online
Ask to be notified when existing iSCSI hardware is disabled
Determine the software or firmware installed on the iSCSI hardware
Determine asset information about the iSCSI hardware
Determine the product information for the iSCSI hardware
An iSCSI session is an active communication stream between an iSCSI initiator port and
an iSCSI target port. An iSCSI session may consist of one or more TCP/IP connections.
The TCP/IP connections are called iSCSI connections. SCSI commands and block data
are encapsulated into packets and transported between the initiator and target via TCP/IP.
This Profile allows a Client to retrieve information about the iSCSI sessions. For example,
a Client can determine the current and maximum number of connections. A Client can
also determine whether the data exchange is in one direction or both directions and the
type of error recovery used.
This Profile may optionally allow a Client to retrieve information about the iSCSI
connection. For example, a Client can determine the parameters that were negotiated
when the iSCSI connection was established such as whether header or data digest
methods are used. A Client can also discover the authentication method used.
iSCSI hardware consists of Ethernet ports. Such ports can come in a variety of hardware
configurations. For example, a single add-in card may contain multiple Ethernet ports that
can be used for iSCSI connections. Alternatively, the Ethernet ports that can be used for
iSCSI connections may be integrated into a motherboard. Regardless, a Client can
retrieve physical information about the iSCSI hardware. For example, a Client can retrieve
the version or serial number. Additionally, a Client can retrieve product information about
the iSCSI hardware. For example, a Client can retrieve the vendor name and an
A Client can retrieve information about the software or firmware installed on iSCSI
hardware. For example, a Client can retrieve the name of the manufacturer and the
version number of the software installed on the iSCSI hardware. Optionally, a vendor can
choose to expose additional software information such as a build number.
The iSCSI Initiator Profile requires the following Subprofile that represent additional
capability:
iSCSI Initiator Port - allows a Client to discover all of the ports connected to a
storage system using iSCSI that are acting as initiator ports.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles
Introduction
Storage Management
Initiative
SNIA Subprofiles
SMI-S 1.1.0 Overview Common | Common Target Ports | Common Initiator Ports
Server | Fabric | Switch | Storage
SMI-S 1.1.0
Functionality
A SNIA Subprofile can be referenced by a SNIA Profile to allow optional inclusion of
additional capability. Like a Profile, a Subprofile defines the classes that a client will use to
Resources and
perform the additional management tasks provided by the Subprofile. The Subprofile also
References
defines the associations that will be used to traverse between classes. In addition to
Questions & Answers identifying the classes used, a Subprofile also defines the properties and extrinsic
methods of each class that must be supported. In certain cases, the Subprofile even
specifies the values a property or method argument must have.
However, a significant difference exists between a Profile and a Subprofile. A Profile

represents a base set of classes and capabilities that all supporting implementations must
make available. In contrast, a Subprofile represents an optional set of classes and
capabilities that a vendor may or may not choose to implement. As an example, for a disk
array product, a vendor would implement all of the CIM elements defined in the Array
Profile. If their array product can create snapshots and replicas, then the vendor may also
choose to implement the CIM elements defined in the Copy Services Subprofile.
A Subprofile can contain the same components as a Profile. They are:
The standards used

The events that a Client can monitor
The Packages that are incorporated into the Subprofile
Recipes for performing a particular management task using the Subprofile
The WBEM operations that the SMI Agent must support
The CIM elements used by the Subprofile
Other Subprofiles
As for a Profile, the Subprofile elements described above are explicitly defined in
Extensible Markup Language (XML) files, one XML file for each Subprofile. For example,
the encapsulation of the model requirements of the FDMI Subprofile is defined in
FDMISubprofile.xml.
In SMI-S 1.1.0, the following four groups of Subprofiles have been defined:
Common
Common Initiator Port
Common Target Port
Profile-specific
A Common Subprofile is one that can apply to many different Profiles. For example, the
Location Subprofile allows a client to determine the physical location of the element
managed by the Profile. Such capability has wide applicability.
A Common Initiator Ports Subprofile is one that can apply to Profiles that manage the
generic SCSI capabilities and transport-specific aspects of target storage systems such as
disk arrays and tape libraries. In contrast, a Common Target Ports Subprofile is one that
can apply to Profiles that manage the generic SCSI capabilities and transport-specific
aspects for hosts and storage systems to discover and make connections to connected
storage such as physical disks and external devices .
A Profile-specific Subprofile applies to only one particular Profile. For example, the Fabric
Profile identifies the following four Fabric specific Subprofiles:
Zone Control
Enhanced Zoning and Enhanced Zoning Control
FDMI
Fabric Path Performance
The other Profiles with specific Subprofiles are
Switch
Server
Storage
A Subprofile can also be referenced by a Package and even another Subprofile.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles
Introduction
Storage Management
Initiative
Common Subprofiles
SMI-S 1.1.0
Functionality Access Points | Device Credentials | Job Control
Location | Multiple Computer System | Software
Resources and
References
A SNIA Subprofile can be referenced by a SNIA Profile to allow optional inclusion of
Questions & Answers
additional capability. Some Subprofiles are applicable to many different types of SNIA
Profiles. SMI-S 1.1.0 identifies such Subprofiles as Common Subprofiles. They are
Access Points - allows a Client to remotely manage the elements of the referencing
Profile using a Web browser, telnet or other interface
that is used to control access to the devices of the referencing Profile
Job Control - allows a Client to asynchronously monitor a long running operation in
the referencing Profile
device or element managed by the referencing Profile
Multiple Computer System - allows a Client to retrieve configuration information
about devices in the referencing Profile that have redundancy and fault tolerant
characteristics
Software - allows a Client to retrieve information about the software or firmware
installed on the device or element managed by the referencing Profile
SMI-S 1.1.0 identifies two other groups of Common Subprofiles that apply to a smaller set
of Profiles. The Common Target Ports Subprofiles apply to Profiles that manage the
generic SCSI capabilities and transport-specific aspects of target storage systems such as
disk arrays and tape libraries. They are
SPI Target Ports - allows a Client to retrieve information about parallel SCSI ports
FC Target Ports - allows a Client to retrieve information about Fibre Channel ports
The Common Initiator Ports Subprofiles apply to Profiles that manage the generic SCSI
capabilities and transport-specific aspects for hosts and storage systems to discover and
make connections to connected storage such as physical disks and external devices.
They are
FC Initiator Ports - allows a Client to retrieve information about Fibre Channel ports
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Access Points
Introduction
Subprofile
Storage Management
Initiative
Access Points Subprofile
CIM and WBEM Basics
Common | Common Target Ports | Common Initiator Ports
SMI-S 1.1.0 Server | Fabric | Switch | Storage
Functionality
Access Points | Device Credentials | Job Control
Resources and Location | Multiple Computer System | Software
References
The Access Points Subprofile is referenced by other SNIA Profiles as an optional

Questions & Answers
enhancement to allow a Client to remotely manage the elements of the Profile. The
remote interface might be a web browser, telnet connection or some other vendor-specific
interface. This Subprofile typically allows the Client to determine the URL to use to
connect to the device. (e.g., http://mydevice.net).
The Access Points Subprofile is considered a Common Subprofile because it can

optionally enhance the following Profiles to provide this additional capability:
Array Profile - allows a Client to manage external RAID arrays and disk storage
systems
NAS Head Profile - allows a Client to manage File Systems and File Shares on a
NAS system that does not include local storage
Self-Contained NAS System Profile - allows a Client to manage File Systems and
File Shares on a NAS system that does include local storage
Storage Library Profile - allows a Client to manage a storage library and its
components
Storage Virtualizer Profile - allows a Client to manage a RAID array that does not
include any local storage
Volume Management Profile - allows a Client to manage storage as virtual
resources using a software storage management subsystem running on a host
system
Switch Profile - allows a Client to manage a Fibre Channel Switch device
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Device Credentials
Introduction
Subprofile
Storage Management
Initiative
Device Credentials Subprofile
CIM and WBEM Basics
Functionality
References
The Device Credentials Subprofile is referenced by other SNIA Profiles as an optional

Questions & Answers
enhancement to allow a Client to change the shared secret (i.e., password) that is used to
control access to the devices of the referencing Profile. The shared secret is different than
the credentials a Client uses for authentication (e.g., login). Using the service that
manages shared secrets, the Client can change a particular shared secret. In other words,
this Subprofile provides write-only key/password (shared secret) configuration.
The Device Credentials Subprofile is considered a Common Subprofile because it can

optionally enhance the following Profiles to provide this additional capability:
Array Profile- allows a Client to manage external RAID arrays and disk storage
systems
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Multiple Computer
Introduction
System Subprofile
Storage Management
Initiative
Multiple Computer System Subprofile
CIM and WBEM Basics
Functionality
References
The Multiple Computer System Subprofile is referenced by other SNIA Profiles as an

Questions & Answers
optional enhancement when the device managed by the Profile offers the capability of
redundancy and fault tolerance. The Subprofile allows a Client to retrieve information
about the redundancy configuration and capabilities such as
The type of redundancy (e.g., N+1, Load Balanced, etc.)

The minimum number of components that must be operational to allow the device
to function properly
Whether a spare component is immediately available to be used (i.e., Hot
Standby) or needs further preparation (i.e., Cold Standby)
Whether failover to the spare component is manual or automatic
Which components are spare versus active
If a vendor chooses to implement the Multiple Computer System Subprofile, a Client can
do the following:
Ask to be notified when the device (e.g., disk array, switch, etc) is activated
Ask to be notified when the device (e.g., disk array, switch, etc) is deactivated
Ask to be notified when the status of the device changes (e.g., from Running to
Suspended)
Ask to be notified when the redundancy characteristics of the primary device
change (e.g., from Fully Redundant to Degraded Redundancy)
The Multiple Computer System Subprofile is considered a Common Subprofile because it

can optionally enhance the following Profiles and Subprofiles to provide this additional
capability:
Array Profile (via the Block Server Performance Subprofile) - allows a Client to
manage external RAID arrays and disk storage systems
Block Server Performance Subprofile - allows a Client to manage the collection of
performance statistics for a server that uses block I/O
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Job Control
Introduction
Subprofile
Storage Management
Initiative
Job Control Subprofile
CIM and WBEM Basics
Functionality
References
The Job Control Subprofile is referenced by other SNIA Profiles as an optional

Questions & Answers
enhancement when the Profile defines one or more operations that might take significant
time to execute. In this case, a Profile can define an optional mechanism that allows a
Client to monitor the Profile operation asynchronously. If a vendor chooses to implement
the Job Control Subprofile, a Client can do the following:
Monitor a long duration operation(s)

Ask to be notified when the job completes successfully
Ask to be notified when the job terminates with an error
Ask to be notified when the percentage of job completion changes
Ask to be notified when the status of the job changes (e.g., from Running to
Suspended)
Retrieve the error that caused the job to fail
Using this Subprofile, a Client can retrieve specific information about the job such as its
status or percentage complete and optionally the elapsed time.
For example, the Array Profile optionally allows a Client to create a storage pool.
However, this operation can take a long time to complete depending upon the storage
device being managed. For this reason, the Array Profile identifies the Job Control
Subprofile as an optional capability. Hence, when creating a storage pool, a Client can
monitor the creation process. After the storage pool is created, the job completes
successfully and the Client is notified of this event.
The Job Control Subprofile is considered a Common Subprofile because it can optionally
enhance the following Profiles to provide this additional capability:
systems
Self-Contained NAS System Profile- allows a Client to manage File Systems and
Volume Management Profile- allows a Client to manage storage as virtual
system
The Job Control Subprofile can optionally enhance the following Subprofiles and
Packages to provide this additional capability:
Copy Services Subprofile - allows a Client to manage local mirrors, remote mirrors,
clones and snapshots
File Export Manipulation Subprofile - allows a Client to manage File Shares on a
NAS system
File System Manipulation Subprofile - allows a Client to manage File Systems on a
NAS system
Block Services Package - allows a Client to manage storage pools, storage
volumes and logical disks. Many sto
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Location Subprofile
Introduction
Storage Management
Initiative
Location Subprofile
SMI-S 1.1.0
Functionality Access Points | Device Credentials | Job Control
Location | Multiple Computer System | Software
Resources and
References
The Location Subprofile is referenced by other SNIA Profiles as an optional enhancement
Questions & Answers
that allows a Client to retrieve information about the physical location of the device or
element managed by the referencing Profile. For example, the Array Profile identifies the
Location Subprofile as an optional capability. If implemented, a Client can retrieve
information about the physical location of the disk array. The information can have any
form because it is defined as a string. For example, it can specify the slot location on a
motherboard or be GPS coordinates. Optionally, a vendor can choose to expose
additional information such as an address (e.g., 123 Main St, Anytown, State or Building
3, 2nd Floor, Room 220).
The Location Subprofile is considered a Common Subprofile because it can optionally

enhance the following Profiles to provide this additional capability:
systems
components
Volume Management Profile- allows a Client to manage storage as virtual
system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Software
Introduction
Subprofile
Storage Management
Initiative
Software Subprofile
CIM and WBEM Basics
Functionality
References
The Software Subprofile is referenced by other SNIA Profiles as an optional enhancement

Questions & Answers
that allows the Client to retrieve information about the software or firmware installed on the
device or element managed by the Profile. For example, the Array Profile identifies the
Software Subprofile as an optional capability. If implemented, a Client can retrieve
information about the disk array software such as the manufacturer and a version number.
Optionally, a vendor can choose to expose additional information such as a build number.
The Software Subprofile definition is identical to Software Package. If a Profile references

the Software Subprofile, then implementation is optional. In contrast, if a Profile references
the Software Package, then implementation is mandatory.
The Software Subprofile is considered a Common Subprofile because the following

Profiles need to provide similar capability:
systems
components
system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Target Ports Subprofiles > SPI
Introduction
Target Ports Subprofile
Storage Management
Initiative
SPI Target Ports Subprofile
CIM and WBEM Basics
Functionality
SPI Target Ports | FC Target Ports
Resources and
References
The SPI Target Ports Subprofile is referenced by other SNIA Storage Profiles as an
Questions & Answers
optional enhancement. This Subprofile allows a Client to discover all of the ports
connected to a storage system using Parallel SCSI (SPI) that are acting as target ports.
A Client can retrieve information about the SPI port. For example, a Client can determine
whether the SPI port can only serve as an target port or as either an initiator or target port.
The SPI Target Ports Subprofile can optionally enhance the following storage Profiles and
Subprofiles to provide this additional capability:
systems
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Target Ports Subprofiles > FC
Introduction
Target Ports Subprofile
Storage Management
Initiative
FC Target Ports Subprofile
CIM and WBEM Basics
Functionality
SPI Target Ports | FC Target Ports
Resources and
References
The FC Target Ports Subprofile is referenced by other SNIA Storage Profiles as an
Questions & Answers
optional enhancement. This Subprofile allows a Client to discover the ports on a storage
system using Fibre Channel (FC) that are acting as front-end ports.
A Client can retrieve information about the FC ports. For example, a Client can determine
whether a FC port can only serve as a target port or as either an initiator or target port.
Additionally, a Client can determine the WWN for the FC ports.
Using this Subprofile, a Client can also do the following:
Ask to be notified when a target FC port comes online

Ask to be notified when a target FC port becomes disabled
Ask to be notified when the speed of a target FC port changes
Ask to be notified when the status of a target FC port changes (e.g., from OK to
Error)
Ask to be notified when the network address of a target FC port changes
The FC Target Ports Subprofile can optionally enhance the following storage Profiles and
systems
components
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Initiator Ports Subprofiles > FC
Introduction
Initiator Ports Subprofile
Storage Management
Initiative
FC Initiator Ports Subprofile
CIM and WBEM Basics
Functionality
The FC Initiator Ports Subprofile is referenced by other SNIA Profiles as an optional
Resources and
enhancement. This Subprofile allows a Client to discover the ports on a system that use
References
Fibre Channel (FC) to connect to its physical storage.
Questions & Answers
A Client can retrieve information about the FC ports. For example, a Client can determine
whether a FC port can only serve as an initiator port or as either an initiator or target port.
Additionally, a Client can determine the current and maximum speed of the port.
Using this Subprofile, a Client can also do the following:
Ask to be notified when an initiator FC port comes online

Ask to be notified when an initiator FC port becomes disabled
Ask to be notified when the status of an initiator FC port changes (e.g., from OK to
Error)
The FC Initiator Ports Subprofile can optionally enhance the following storage Profiles to
provide this additional capability:
systems
Self-Contained NAS System Profile - allows a Client to manage a storage library
and its components
system
FC HBA Profile - allows a Client to manage the Fibre Channel (FC) ports on a
system using a Host Based Adapter (HBA)
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Server Subprofiles > Indications Subprofile
Introduction
Storage Management
Initiative
Indications Subprofile
SMI-S 1.1.0
Functionality Indications | Object Manager Adapter
Resources and
The Indications Subprofile is referenced by the Server Profile as an optional enhancement
References
that allows a SMI Agent to support indications. This Subprofile must be supported by SMI
Questions & Answers
Agents that support Profiles and Subprofiles that require indications. If this Subprofile is
implemented, a Client will be able to perform the following management tasks:
Create a subscription to an indication

Use the CIM-XML protocol for delivery of the notification
Optionally, a vendor can choose to enhance this Subprofile by allowing a Client to do the
following:
Ask to be notified of instance lifecycle events (create, modify, delete)

Ask to be notified for alert indications
Determine the query operations supported such as simple join versus complex join
Define which events to monitor
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Server Subprofiles > Object Manager
Introduction
Adapter Subprofile
Storage Management
Initiative
Object Manager Adapter Subprofile
CIM and WBEM Basics
Functionality
Indications | Object Manager Adapter
Resources and
References
The Object Manager Adapter Subprofile is referenced by the Server Profile as an optional
Questions & Answers
enhancement that allows the Client to manage the Object Manager Adapters of a SMI
Agent. Specifically, a Client can do the following:
Enumerate all of the available Object Manager Adapters on the SMI Agent
Retrieve information about the type of Object Manager Adapter (e.g., Client,
Provider or Indication Handler)
Determine the operational status of a Object Manager Adapter (e.g., Stopped,
Starting, etc.)
Start or stop an Object Manager Adapter
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Enhanced Zoning and
Introduction
Enhanced Zoning Control Subprofile
Storage Management
Initiative
Enhanced Zoning and Enhanced Zoning
CIM and WBEM Basics Control Subprofile
SMI-S 1.1.0 Overview Profiles | Subprofiles | Packages
SMI-S 1.1.0 Common | Common Target Ports | Common Initiator Ports

Functionality Server | Fabric | Switch | Storage
Resources and
Enhanced Zoning Control | Zone Control | FDMI | Fabric Path Performance
References
Questions & Answers The Enhanced Zoning and Enhanced Zoning Control Subprofile is referenced by the
Fabric Profile as an optional enhancement that allows a Client to manage aliases for
zones in a Fabric. A zone alias is an alternative name for a port number or WWN. For
example, Lab could be used as an alternative to 50:01:a3:80:22:3f:bb:12.
Using this Subprofile, a Client can do the following:
Create a Zone Alias for the Fabric

Add the Zone Alias to the Fabric
Delete a Zone Alias from the Fabric
Note that this Subprofile is contingent upon support for the Zone Control Subprofile. This
is to say that it builds upon the capabilities defined in the Zone Control Subprofile.
Information about the zones themselves are defined in the Fabric Profile.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Zone Control
Introduction
Subprofile
Storage Management
Initiative
Zone Control Subprofile
CIM and WBEM Basics
Functionality
Resources and
References
The Zone Control Subprofile is referenced by Fabric Profile as an optional enhancement
Questions & Answers
that allows a Client to manage zoning in a Fabric. A Zone in a Fabric is a set of devices
that can access each other. A device in a Fabric may be configured into one or more
Zones. A Zone Set is a group of one or more Zones. A Worldwide Name (WWN) is
specified as an sixteen hexadecimal non-colon separated number (e.g.,
20e401506fbb428a). A Zone Member may be defined by its physical port number on the
switch or by its Node WWN or by Port WWN. A Zone must have at least one Member.
Using the Zone Control Subprofile, a Client can do the following:
Create or delete a Zone

Create or delete a Zone Set
Create Zone Member and add it to Zone
Add a Zone to a Zone Set
Remove a Zone from a Zone Set
Add a Zone Member to a Zone
Remove a Zone Member from a Zone
Activate a Zone Set
Request a lock of the Fabric to begin zoning configuration changes
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > FDMI Subprofile
Introduction
Storage Management
Initiative
FDMI Subprofile
SMI-S 1.1.0
Functionality Enhanced Zoning Control | Zone Control | FDMI | Fabric Path Performance
Resources and
The FDMI Subprofile is referenced by the Fabric Profile as an optional enhancement that
References
allows a Client to retrieve information about Fibre Channel Ports on a Host Based Adapter
Questions & Answers
(HBA). This Subprofile is used when the host system for the HBA does not have an SMI
Agent. Instead, the Fabric Device Management Interface (FDMI) is used to retrieve the
HBA Fibre Channel Port information.
In a Fabric, a Node is a source or destination of information for one or more other Nodes.
Each Node can use one or more Ports as the physical connection to the Fabric for
receiving or transmitting data. For this Subprofile, it is assumed that the Ports are
packaged on HBAs that reside on a host system.
Using the FDMI Subprofile, a Client can do the following:
Determine the name of the host system on which the HBA is located
Enumerate the HBA devices on host system
Enumerate the Ports on each HBA
Enumerate the Nodes
Retrieve information about the Fibre Channel Ports such as its port WWN and
optionally its speed
Retrieve information about the Fibre Channel Nodes such as its node WWN
Because the Subprofile incorporates the Software Package, a Client can retrieve
information about the software or firmware installed on these components. For example, a
Client can retrieve the name of the Manufacturer and the version number of the software
installed on the HBA. Optionally, a vendor can choose to expose additional software
information such as a build number.
Because the Subprofile also incorporates the Physical Package Package, a Client can
retrieve physical information about the HBA card. For example, a Client can retrieve the
version or serial number. Additionally, a Client can retrieve product information about the
HBA card. For example, a Client can retrieve the vendor name and an identification
number (e.g., SKU).
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Fabric Path
Introduction
Performance Subprofile
Storage Management
Initiative
Fabric Path Performance Subprofile
CIM and WBEM Basics
Functionality
Resources and
References
The Fabric Path Performance Subprofile is referenced by the Fabric Profile as an optional
Questions & Answers
enhancement that allows a Client to retrieve performance statistics for the path between
an initiator and target within a Fabric. Data path connections are often made between
SAN resources in a Fabric. For example, a NAS Head system will get its storage from
external storage such as a disk array. The NAS will create a path from it to the array.
Enumerate the initiator-to-target paths in a Fabric

Determine the endpoints for each path
Collect performance statistics for each path
Retrieve the path performance statistics in groups
To collect these statistics, a Client first enumerates all of the active initiator to target paths
in a particular Fabric. Then, the Client retrieves statistics about the number of bytes
transmitted and received for each active path.
Optionally, a vendor can choose to record the time that the statistic was collected. A Client
can determine the sample interval and time of the last sample. Doing so allows a Client to
perform historical trend analysis.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Switch Subprofiles > Switch Configuration
Introduction
Data Subprofile
Storage Management
Initiative
Switch Configuration Data Subprofile
CIM and WBEM Basics
Functionality
Switch Configuration Data | Blades
Resources and
References
The Switch Configuration Data Subprofile is referenced by the Switch Profile as an
Questions & Answers
optional enhancement that allows the Client to retrieve and change the configuration of
the Switch device. A Client can retrieve the configuration data along with the time that it
was obtained.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Switch Subprofiles > Blades Subprofile
Introduction
Storage Management
Initiative
Blades Subprofile
SMI-S 1.1.0
Functionality Switch Configuration Data | Blades
Resources and
The Blades Subprofile is referenced by the Switch Profile as an optional enhancement for
References
Director Class Switch devices. A Director Class Switch is one that has a large number of
Questions & Answers
Ports and provides fault tolerance. The Ports are located on separate physical
components called Blades that can be inserted or removed from the Switch device as
needed. This form factor allows for easy expansion or replacement.
Using this Subprofile, a Client can perform the following management tasks:
Enumerate all the Blades in a Switch

Enumerate all the Ports on each Blade
Ask to be notified when a Blade is inserted into or removed from the Switch
Ask to be notified when the status of a Blade changes (e.g., from OK to
Degraded)
Client can retrieve physical information about the Blade hardware. For example, a Client
can retrieve the version or serial number. Additionally, a Client can retrieve product
information about the Blade hardware. For example, a Client can retrieve the vendor
name and an identification number (e.g., SKU).
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles
Introduction
Storage Management
Initiative
Storage Subprofiles
SMI-S 1.1.0
Functionality File System Manipulation | File Export Manipulation | Block Services Resource Ownership
Block Server Performance | Copy Services | Disk Drive Lite | Disk Sparing
Resources and Extent Composition | Masking and Mapping | Storage Library Limited Access Port Elements
References
The SNIA Storage Profiles can reference the following storage specific Subprofiles as
Questions & Answers
optional enhancements:
File System Manipulation Subprofile - allows a Client to manage File Systems on a

NAS system - allows a Client to manage File Shares on a NAS system
File Export Manipulation Subprofile
Block Services Resource Ownership Subprofile - allows a Client to manage the
ability to grant or deny access to block storage resources
Block Server Performance Subprofile - allows a Client to define a general
mechanism for collecting and retrieving performance statistics for various types of
block servers.
Copy Services Subprofile - allows a Client to manage local mirrors, remote mirrors,
clones and snapshots
Disk Drive Lite Subprofile- allows a Client to retrieve information about the disk
drives in an storage device
Disk Sparing Subprofile - allows a Client to manage spare logical disks that can be
used in place of a failed component of a disk array
Extent Composition Subprofile- allows a Client to retrieve information about the
allocation hierrarchy of storage pools, storage volumes and logical disks
Masking and Mapping Subprofile - allows a Client to manage the access to the
LUNs attached to the target ports on a storage system using the Masking and
Mapping mechanisms
Limited Access Ports Subprofile - allows a Client to discover information about the
mechanisms of physical access used to transport physical media into or out of a
storage library
The following sections describe these Subprofiles in more detail.

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Filesystem
Introduction
Manipulation Subprofile
Storage Management
Initiative
File System Manipulation Subprofile
CIM and WBEM Basics
Functionality
File System Manipulation | File Export Manipulation | Block Services Resource Ownership
Resources and Block Server Performance | Copy Services | Disk Drive Lite | Disk Sparing
References Extent Composition | Masking and Mapping | Storage Library Limited Access Port Elements
Questions & Answers

The File System Manipulation Subprofile is referenced by other SNIA Storage Profiles as
an optional enhancement. This Subprofile allows a Client to manage File Systems on a
NAS system.
Create or remove a File System

Modify a File System setting
Ask to be notified when a File System is created or removed
Ask to be notified when the settings of a File System change
a Client can determine the File System name, the total capacity and the amount of
available space. A Client can determine the maximum file name length and whether file
names are case sensitive and/or case preserved. Optionally, a vendor can choose to
expose information about the number of files, the code set used and whether the File
System is read-only.
The File System Manipulation Subprofile can optionally enhance the following Storage
Profiles to provide this additional capability:
The Subprofile defines the following Subprofiles that represent optional features that a
Job Control - allows a Client to asynchronously monitor a long running operation

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > File Export
Introduction
Manipulation Subprofile
Storage Management
Initiative
File Export Manipulation Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The File Export Manipulation Subprofile is referenced by other SNIA Storage Profiles as
an optional enhancement. This Subprofile allows a Client to manage File Shares on a
NAS system. A File Share is a file or directory that can be accessed over a network using
a file protocol such as the Network File System (NFS) protocol or the Common Internet
File System (CIFS) protocol.
Create or remove a File Share

Modify a File Share setting
Ask to be notified when a File Share is created or removed
Ask to be notified when the status of a File Share changes
version number. A Client can determine the name of the directory that is shared.
A Client can retrieve information about the File Share capabilities of the NAS system. For
example, a Client can determine which file protocols (e.g., NFS, CIFS) are supported and
which versions of the file protocols are supported. Additionally, a Client can determine
whether the File Share operations can be performed synchronously or asynchronously.
The File Export Manipulation Subprofile can optionally enhance the following Storage
The Subprofile defines the following Subprofiles that represent optional features that a
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Block Services
Introduction
Resource Ownership Subprofile
Storage Management
Initiative
Block Services Resource Ownership
CIM and WBEM Basics Subprofile

Resources and
References
Extent Composition | Masking and Mapping | Storage Library Limited Access Port Elements
Questions & Answers
The Block Services Resource Ownership Subprofile allows a Client to manage the ability
to grant or deny access to block storage resources. The purpose of the Subprofile is to
prevent disruptive behavior in environments where resources might be accessed by
several Clients at the same time.
The Subprofile allows a Client to assign privileges to another user. This Subprofile
identifies two sets of privileges that can be used to control access to storage resources.
The Manage Storage Volume privilege controls access to a storage volume. The Manage
Storage privilege has even more capabilities for controlling access. Using this Subprofile,
a Client can perform the following operations:
Assign the privilege to another user for a particular storage resource

Show the privileges assigned to a user for a particular storage resource
If a Client has the proper privileges, it is allowed to perform the following operations on a
storage resource:
Prevents target or initiator ports from seeing a list of LUNs

Allows target or initiator ports to see a list of LUNs
Unmask a LUN
Mask a LUN
Create or modify a storage pool
Delete a storage pool
Delete a logical disk or storage volume and returns its space to a storage pool
Create or modify a logical disk, storage volume or storage pool
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Block Server
Introduction
Performance Subprofile
Storage Management
Initiative
Block Server Performance Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Block Server Performance Subprofile is referenced by other SNIA Block Server
Storage Profiles as an optional enhancement that allows a Client to manage the collection
of performance statistics. This Subprofile defines a general mechanism for collecting and
retrieving performance statistics for various types of block servers.
A Client can determine the storage elements for which the SMI Agent collects
performance statistics. The Subprofile identifies many different types of storage elements
for which statistics may be collected. For example, a particular implementation might
collect statistics for Storage Volumes and Front-End Ports but not for Back-End Ports or
Disk Drives. Using this Subprofile, a Client can query the SMI Agent to determine what
statistical information is supported.
For each storage element, a Client can determine the specific performance statistics the
SMI Agent will collect. The Subprofile identifies many different types of statistics that may
be supported. For example, a particular implementation might collect statistics for the
number of kilobytes read and the number of write I/O's but not the number of write cache
hits or the number of kilobytes written. The statistics can optionally include time stamp and
sample interval information that can be used for trend analysis. Using this Subprofile, a
Client can query the SMI Agent for this information.
Optionally, a SMI Agent can allow a Client to select the storage elements for which it
wants performance statistics returned. For example, even though the SMI Agent collects
statistics for all recognized elements, a Client might only be interested in examining the
Disk Drive statistics. Using this Subprofile, a Client can specify such filtering when it
retrieves the statistics.
As an additional option, a SMI Agent can allow a Client to specify which performance
statistics it wants returned for each selected storage element. For example, when
requesting Storage Volume statistics, a Client can specify that the SMI Agent only return
the number of kilobytes read or written but not the number of write I/O's. Additionally, a
Client can specify whether to include time stamp and sample interval information.
The Block Server Performance Subprofile is optionally supported to enhance the Profiles
below with these additional capabilities:
systems
system
In addition, other Subprofiles can optionally take advantage of the performance statistics
collection features provided by this Subprofile. They are:

redundancy configuration and capabilities of fault tolerant systems
Extent Composition - allows a Client to retrieve information about the hierarchical
layout of storage capacity
SPI Target Ports - allows a Client to retrieve information about the SCSI ports
FC Target Ports - allows a Client to retrieve information about the FC ports
FC Initiator Ports - allows a Client to retrieve information about the FC ports
snapshots.
Disk Drive Lite - allows a Client to retrieve information about the disk drives in an
storage device
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Copy Services
Introduction
Subprofile
Storage Management
Initiative
Copy Services Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Copy Services Subprofile is referenced by other SNIA Storage Profiles as an optional
enhancement. This Subprofile allows a Client to manage local mirrors, remote mirrors,
clones and snapshots.
A mirror is a storage element that is an identical image of another storage element. A

snapshot is a fully usable image of a source element taken at a particular point in time. A
clone is a fully copied replica taken at a particular point in time that is the same size as the
source element and is intended to become an independent usable storage resource.
The Subprofile identifies the following types of replicas that a Client can manage:
Full Copy - contains all of the data of the source element

Log - consists of log entries for each change made in the source element that can
be used to recreate the source element
After Delta - contains just the changes made in a source element from a point in
time
Before Delta - the source element contains the changes made in the replica from a
point in time
A replica may be synchronized to a point-in-time view of an image or a current view of an

image. Snapshots and clones always represent point-in-time views. Mirrors can represent
either a point-in-time or a current view. Using this Subbrofile, a Client can do the following:
Create a local mirror or clone

Create a remote mirror or clone
Create a snapshot
Modify or delete a replica
Monitor the state of synchronization between two storage elements
Determine whether the copy operation is uni-directional or bi-directional
Determine the type of replication (e.g., full copy, before delta, after delta, etc.)
Ask to be notified when the remaining storage pool space gets too low
Ask to be notified when the delta replica space gets too low
Remote replication requires a transport connection between two systems. These
connections are called peer-to-peer connections. A change in the state of a peer-to-
peer connection can affect the ability to create remote replicas. Using this Subprofile, a
Client can ask to be notified when such a change occurs.
The Subprofile identifies several stages of synchronizing. For example, the storage
elements could be preparing to synchronize or actively resynchronizing. A Client can
determine the stage of synchronization. A Client can additionally monitor the state of
synchronization between two storage elements. A Client can also ask to be notified when
the synchronization changes from one stage to the another.
The Subprofile allows a Client to configure the mirror, clone or snapshot operations. Some
of the configurable settings are the following:
Whether the replication persists persists during power off or reset

Whether the storage element is to be used as a local or remote mirror
Whether the storage element is to be used as a full-size snapshot
Whether a remote mirror can use a replication buffer
The minimum and maximum delta reservation levels
The Subprofile allows a Client to retrieve information about the storage replication
capabilities. Some of the capabilities that a Client can query are the following:
Which replication methods are supported synchronously or asynchronously

Which modify synchronization operations are supported (e.g. restore, detach, start
copy, etc.)
Whether persistent replicas are supported
The maximum number of replicas that can be made from one source element
Whether local and/or remote snapshots are supported
Whether incremental deltas are supported
What storage elements can be replicated (e.g., logical disk, storage volume, etc.)
The minimum, maximum and default values for then delta reservation mechanism
The Copy Services Subprofile can optionally enhance the following storage Profiles to
systems
Volume Management - allows a Client to manage storage as virtual resources using
a software storage management subsystem running on a host system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Disk Drive Lite
Introduction
Subprofile
Storage Management
Initiative
Disk Drive Lite Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Disk Drive Lite Subprofile is referenced by other SNIA storage Profiles as an optional
enhancement that allows a Client to retrieve information about the disk drives in an
storage device. Using this Profile, a Client can do the following:
Enumerate all the disk drives on the storage device

Retrieve information about the firmware used by each disk drives
Retrieve physical information about each disk drive
To access the information exposed by this Subprofile, a Client starts with the CIM element
that represents the storage device (e.g., the Array, the NAS Head, etc). From there, a
Client can discover all the disk drives uses the physical information for the storage device
to find the component physical information for the disk drive.
A Client can retrieve information about the firmware installed on a disk drive. For example,
a Client can retrieve the name of the Manufacturer and the version number. Optionally, a
vendor can choose to expose additional firmware information such as a build number.
A Client can retrieve physical information about the disk drive. For example, a Client can
retrieve the version or serial number. Additionally, a Client can retrieve product information
about the disk drive. For example, a Client can retrieve the vendor name and an
The Disk Drive Lite Subprofile can optionally enhance the following storage Profiles and
systems
Block Server Performance Subprofile - hat allows a Client to manage the collection
of performance statistics of a server that uses block I/O
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Disk Sparing
Introduction
Subprofile
Storage Management
Initiative
Disk Sparing Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Disk Sparing Subprofile is referenced by Storage Profiles as an optional
enhancement that allows a Client to manage spare disks used to provide redundancy in a
storage system. Using this Subprofile, a Client can do the following:
Enumerate the number of spare or failed logical disks

Discover the storage resources used by the logical disks
Determine the fault tolerant characteristics of a storage system
Perform a manual failover to a spare logical disk
A Client can retrieve information about logical disks. For example, a Client can determine
whether the logical disk has a single point of failure and which logical disks are spare.
Additionally, a Client can retrieve the number of blocks and the block size (i.e., capacity),
the number of spindles (i.e., package redundancy) and the number of copies (i.e., data
redundancy). A Client needs this information in order to decide the optimal configuration
for managing the spare capacity.
When a component fails, the storage system must failover to a spare component. Some
storage systems perform automatic failover while others require a storage administrator to
initiate a manual failover. This Subprofile allows a Client to perform a manual failover.
The Disk Sparing Subprofile can optionally enhance the following storage Profiles to
systems
system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Extent Composition
Introduction
Subprofile
Storage Management
Initiative
Extent Composition Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Extent Composition Subprofile is referenced by other SNIA Storage Profiles as an
optional enhancement. Several preparation steps are required before a user can access
data on a Logical Disk or Storage Volume. First, unassigned space from one or more
Primordial Pools is allocated to create a Storage Pool. Next, unassigned space from one
or more Storage Pools is allocated to create a Logical Disk or Storage Volume. Then, the
space on a Logical Disk or Storage Volume is allocated and organized into one or more
File Systems. A System exposes these File Systems which allows users to access their
data.
This Subprofile allows a Client to retrieve information about the layout of the areas, called
Storage Extents, that are used to form Primordial and Storage Pools. In some cases,
Storage Extents are created by allocating space from other Storage Extents. creating a
virtual hierarchy of Storage Extents is used. Similarly, Storage Pools can be created by
allocating space from other Storage Pools. This Subprofile allows a Client to retrieve
information about the virtual hierarchy of both. If a vendor chooses to implement the
Extent Composition Subprofile, a Client can do the following:
Enumerate the Storage Extents used

Traverse the virtual hierarchy of Storage Extents
Traverse the virtual hierarchy of Storage Volumes or Logical Disks
Discover the Storage Extents used by a Storage Pool
Discover the Primordial Extents used by a Storage Volume or Logical Disk
This Subprofile allows a Client to retrieve information about Extents such as block size,
the number of blocks and whether it is Primordial. Where storage elements use striping, a
Client can determine the number of blocks written on one stripe element before using the
next (i.e., strip depth). Where one or more storage elements are used in combination, a
Client can determine the starting and ending block address used by each storage element
and the order in which each element is used. Where fault tolerant storage elements are
used, a Client can retrieve information about whether the storage device has a single point
of failure, the number of disk spindles (i.e., package redundancy), or the number of data
copies made (i.e., data redundancy).
The Extent Composition Subprofile can optionally enhance the following storage Profiles
to provide this additional capability:
systems
system
The Extent Composition Subprofile can optionally enhance the following storage
Subprofiles and Packages to provide this additional capability:

performance statistics on a server that uses block I/O
Block Services Package - allows a Client to manage storage pools, storage
volumes and logical disks
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Masking and
Introduction
Mapping Subprofile
Storage Management
Initiative
Masking and Mapping Subprofile
CIM and WBEM Basics
Functionality
Questions & Answers

The Masking and Mapping Subprofile is referenced by other SNIA Storage Profiles as an
optional enhancement. A SCSI storage device is identified by an assigned Logical Unit
Number (LUN). If a storage device is divided into subsets of storage capacity, then each
subset is assigned a separate Logical Unit Number (LUN).
Before a user can access data from a storage system on a SAN, a data path must be
established between an initiator port on a host system through a target port on a storage
system. The target port exposes the LUNs attached to it. In the absence of any
restrictions, any initiator port on any host system can connect to any target port on any
storage system and see all the LUNs attached to the target port.
Mapping and Masking mechanisms have been defined to impose controls on data access.
Masking provides the ability to control which servers can access which LUNs. Typically, a
storage system will restrict access to a LUN using a list of specific initiator port WWNs.
Access can be read-only or read-write. A View represents the LUNs that an initiator port
sees. Mapping provides the ability to expose a different View of LUNs to different host
initiator ports. For example, different host initiator ports can see the same storage
resource by a different LUN.
This Subprofile allows a Client to manage the access to the LUNs attached to the target
ports on a storage system using the Masking and Mapping mechanisms. Using this
Subprofile, a Client can do the following:
Ask to be notified when a LUN is activated or deactivated

Ask to be notified when a View is added or removed
Ask to be notified when access is granted or removed for an initiator port
Enumerate all of the existing LUNs
Enumerate all of the defined Views
Grant or remove access for a known initiator port
Create, modify or remove Views
Add or remove a known initiator ports that may be granted access to a LUN
The Masking and Mapping Subprofile can optionally enhance the following storage
systems
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Limited Access Port
Introduction
Elements Subprofile
Storage Management
Initiative
Storage Library Limited Access Port
CIM and WBEM Basics Elements Subprofile

Resources and
References
Extent Composition | Masking and Mapping | Storage Library Limited Access Port Elements
Questions & Answers
The Storage Library Limited Access Port Elements Subprofile is referenced by the
Storage Library Profile as an optional enhancement. This Subprofile allows a Client to
discover information about the mechanisms of physical access used to transport physical
media into or out of a storage library. These mechanisms are called limited access ports
because they are specific to a particular type of physical media. Such mechanisms might
be mail slots, cartridge access ports, or other type of import/export element. In a storage
library, removable media is located in slots or spaces. A magazine is a container for a
group of storage media slots that are handled as a unit. Often, a magazine has a barcode
or other identification label. Access ports can be located on a chassis or magazine.
A Client can retrieve information about the magazine such as its location coordinates and
capacity. A Client can determine the media types supported. For example, the magazine
might support a tape cartridge, a CD or DVD. A Client can also determine the types of
label formats supported. For example, the label format might be a barcode or radio
frequency identification (RFID).
A Client can retrieve information about the characteristics of the limited access port such
as whether the media is physically accessible to a human or whether media access is
restricted to non-human (e.g., robotic) mechanisms.
Using this Subprofile, a client can also do the following:
Ask to be notified when a new access port is made available

Ask to be notified when an existing access port is no longer available
Ask to be notified when the status of an existing access port changes
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages
Introduction
Storage Management
Initiative
SNIA Packages
SMI-S 1.1.0 Overview Health | Physical Package | Software | Block Services
SMI-S 1.1.0
A SNIA Package can be referenced by SNIA Profile. Like a Profile, a Package defines a
Functionality
set of CIM classes. It also defines the associations that will be used to traverse between
classes. In addition to defining the classes used, a Package also defines the properties
Resources and
References
and extrinsic methods to be used. In certain cases, the Package even specifies the values
a property or method argument can have.
Questions & Answers
However, there exists a significant difference between a Subprofile and a Package. A
Subprofile represents additional functionality that a vendor can optionally choose to
implement as part of their Profile implementation. In contrast, when a Package is
referenced by a Profile, all of the CIM elements in the Package are considered to be part
of the Profile and hence, must be implemented.
A Package contains the same components as a Profile which are:
The standards used

The events that a Client can monitor
The Subprofiles that can optionally be implemented
Recipes for performing a particular management task using the Package
The WBEM operations that the SMI Agent must support
The CIM elements used by the Package
Other Packages
SMI-S 1.1.0 defines the following four Packages:
Health - allows a Client to retrieve information about the status of the device
managed by the referencing Profile
Physical Package - allows a Client to retrieve information about the physical
characteristics of the device managed by the referencing Profile
Software - allows a Client to retrieve information about the software or firmware
installed on the device or element managed by the referencing Profile
Block Services - allows a Client to manage storage pools and logical disks by the
referencing storage Profile
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Health Package
Introduction
Storage Management
Initiative
Health Package
SMI-S 1.1.0
The Health Package is referenced by a SNIA Profile to allow a Client to retrieve
Functionality
information about the status of the device managed by the Profile. A Client can also
retrieve information about the state of the device components.
Resources and
References
For example, the Array Profile references the Health Package. Doing so allows a Client to
Questions & Answers retrieve information about the status (e.g., OK, Degraded, Stopped, etc.) of the disk
array. A Client can also retrieve information about the state of a disk array component
such as a disk drive.
The Health Package is required by the following Profiles:
systems
system
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Physical Package Package
Introduction
Storage Management
Initiative
Physical Package Package
SMI-S 1.1.0
The Physical Package Package is referenced by a SNIA Profile to allow a Client to
Functionality
retrieve information about the physical characteristics of the device managed by the
Profile. Physically, the device might be a chassis, card or some other form factor. A
Resources and
References
vendor can even choose to expose the physical configuration as a combination of
components (e.g., the chassis and the cards in the chassis). This package also allows the
Questions & Answers Client to retrieve asset inventory information.
For example, the Switch Profile references the Physical Package Package. Doing so
allows a Client to retrieve physical information about the switch device chassis such as the
Manufacturer and a model number. Optionally, a vendor can choose to expose additional
physical information about the switch chassis such as the version or serial number.
Additionally, a Client can retrieve product information about the switch device such as the
vendor and an identification number (e.g., SKU).
The Physical Package Package is required by several Profiles and Subprofiles. They are
systems
components
Fabric Profile (via the FDMI Subprofile) - allows a Client to manage Nodes and
Ports on a Fibre Channel Fabric
FDMI Subprofile - allows a Client to retrieve information about Fibre Channel Ports
on a Host Based Adapter (HBA) using FDMI
When referenced, implementation of the elements defined in the Physical Package

Package is mandatory because a Package is considered to be part of the referencing
Profile.
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Software Package
Introduction
Storage Management
Initiative
Software Package
SMI-S 1.1.0
The Software Package is referenced by a SNIA Profile to allow a Client to retrieve
Functionality
information about the software or firmware installed on the device or element managed by
the Profile. For example, the Switch Profile references the Software Package. Doing so
Resources and
References
allows a Client to retrieve information about the switch software such as the manufacturer
and a version number. Optionally, a vendor can choose to expose additional software
Questions & Answers information such as a build number.
The Software Package is referenced by the following Profiles and Subprofiles:

Fabric Profile (via the FDMI Subprofile) - allows a Client to manage Nodes and
Ports on a Fibre Channel Fabric
FDMI Subprofile - allows a Client to retrieve information about Fibre Channel Ports
on a Host Based Adapter (HBA) using FDMI
SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Block Services Package
Introduction
Storage Management
Initiative
Block Services Package
SMI-S 1.1.0
The Block Services Package is referenced by storage related SNIA Profiles to allow a
Functionality
Client to manage storage pools, storage volumes and logical disks. Many storage devices
provide access to their storage capacity using block I/O interfaces. This Package defines
Resources and
References
the common elements and mechanisms that these devices use.
Questions & Answers When incorporated by the referencing Profile, a Client can perform the following
management tasks:
Enumerate, create or delete a Storage Pool, Storage Volume or Logical Disk

Change the capacity of a Storage Pool, Storage Volume or Logical Disk
Ask to be notified when a new Storage Pool, Storage Volume or Logical Disk is
created or deleted
Ask to be notified when the operational status of a Storage Volume or Logical Disk
A Block is a unit in which data is stored and retrieved on a storage device. A Storage Pool
is a collection of storage capacity. A Primordial Pool represents unallocated storage
capacity on a storage device. Storage capacity is drawn from Primordial Pools to create
Concrete Pools. Storage Volumes and Logical Disks are allocations of storage capacity
exposed by a system via an external interface. They are allocated from Concrete Pools.
When this Package is incorporated by a Profile, a Client can retrieve information about
Storage Pools, Storage Volumes and Logical Disks. For example, for a Storage Pool, a
Client can determine its total size, remaining space and whether it is a concrete or
primordial pool. Similarly, for a Storage Volume and Logical Disks, a Client can determine
the number of blocks, block size and redundancy characteristics.
A Storage Pool can have varying capabilities of redundancy, reliability and availability.
These capabilities allow a Client to determine the fault tolerance characteristics of the
storage device. For example, a Client can retrieve information about whether the storage
device has a single point of failure, the number of disk spindles (i.e., package
redundancy), or the number of data copies made (i.e., data redundancy). Optionally, a
vendor can choose to expose information about the striping configuration (e.g. the number
of columns) or parity layout (e.g., rotated vs. non-rotated). The RAID level is determined
by the combination of these factors.
The Block Services Package is required by the following Profiles:
systems
This Package identifies the following Subprofiles which represent optional features that a

Extent Composition - allows a Client to retrieve the hierarchy of storage extents
used to create the storage element
SMI Tutorial > Resources and References
Introduction
Storage Management
Initiative
Resources and References
CIM and WBEM Basics Conformance Test Program | SMI-Lab | References
SMI-S 1.1.0 Overview A vendor can take advantage of a couple of programs to help it deliver a SMI-S
conformant product to market. They are:
SMI-S 1.1.0
Functionality
Conformance Test Program (CTP) allows a vendor to officially certify that their
Resources and product conforms to a particular Profile in SMI-S 1.1.0
References SMI-Lab provides an environment that helps a vendor more quickly develop a SMI-
S conformant prodcut.
Questions & Answers
The following sections describe these programs in more detail. The final section lists the
URLs that one can use to obtain further information about the topics in this tutorial.
SMI Tutorial > Resources and References > Conformance Test Program
Introduction
Storage Management
Initiative
Conformance Test Program
SMI-S 1.1.0 Overview The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN)
SMI-S 1.1.0
storage systems from different vendors. The first step towards this goal is the definition of
Functionality
Profiles and Subprofiles. They define the CIM elements that a Client and SMI Agent will
Resources and
use to perform particular storage management tasks.
References
However, by itself, the SMI-S 1.1.0 does not ensure interoperability. First, the specification
Questions & Answers may have ambiguities that developers can interpret differently. Second, an implementation
may have design flaws. Either may prevent interoperability. Recognizing the problem, the
SNIA created the Conformance Test Program (CTP) to test vendor conformance to the
SMI-Specification and support the adoption of SMI enabled products. The CTP is the
testing process that validates the numerous vendor implementations of the SMI-
Specification.
The CTP is a test harness that is configured to exercise a vendor's product for
conformance to a particular Profile and Subprofiles. The CTP is driven by an Extensible
Markup Language (XML) file. For each Profile and Subprofile, an XML file explicitly
defines the CIM elements used along with the permissible values allowed. Using the
appropriate XML file, the CTP exercises the product for conformance to the SMI-S Profile
and Subprofile definition. For example, to certify a vendor's array product, the CTP will use
the array.xml file to verify that all mandatory CIM Classes of the Array Profile have been
implemented. Additionally, it will verify that all mandatory Properties of the Array Profile
have valid values. After successful completion, a vendor may choose to list its SMI-S
conformant products on the SNIA web site.
Finally, because the CTP program is focused on providing a vendor-neutral, end user
positive service to the industry, the SNIA does not release performance metrics and the
test is reported as pass only. The test results are confidential and only released to the
vendor requesting conformance testing.
SMI Tutorial > Resources and References > SMI-Lab
Introduction
Storage Management
Initiative
SMI-Lab
SMI-S 1.1.0 Overview The Storage Networking Industry Association (SNIA) created the SMI-Lab program in
2003. Its purpose is to provide an environment that helps accelerate the delivery of SMI-S
SMI-S 1.1.0
conformant products to market. A SMI-Lab program organizes and coordinates several
Functionality
activities. One is the creation and management of a 7 x 24 testing environment at the
Resources and
SNIA Technology Center in Colorado Springs, CO. Supplied with equipment from all
References leading storage product vendors, participants have access to this equipment for testing
purposes. Another is the series of meetings called Plugfests where storage management
Questions & Answers application vendors and storage product vendors can informally test interoperability
between their SMI-S products.
The SMI-Lab5 program ran from July 2004 through April 2005. It included seven
scheduled Plugfests. Some of the SMI-Lab5 Plugfest activities focused on
Enhancing the scripted demonstrations delivered at Storage Networking World

(SNW)
Testing Profiles for Conformance Test Program (CTP) release
Client developer feedback
CTP validation of SMI-S 1.1.0 Profiles
The SMI-Lab6 program runs from July 2005 through June 2006. Currently, five Plugfests
are scheduled. They will take place at the SNIA Technology Center. Participants must be
SNIA members. Registration is required before access to the testing environment and
Plugfest attendance is allowed.
SMI Tutorial > Resources and References > References
Introduction
Storage Management
Initiative
References
SMI-S 1.1.0
Functionality CIM and WBEM
Resources and
Distributed Management Task Force
References
CIM Schemas
Questions & Answers CIM Specification v2.2
CIM Operations over HTTP v1.2
Representation of CIM in XML v1.0
WBEM Discovery using the Service Location Protocol v1.0
WBEM SLP Template v1.0
XML Document Type Definition 2.2
CIM Query Language Definition 1.0
SMI
Storage Networking Industry Association
Conformance Test Program
Storage Management Initiative Specification 1.0.2
SNIA Dictionary
List of Provider Vendors with products that have passed CTP
List of Client Vendors with applications that have passed CTP
Storage Management Developer's Network
SMI-Lab
CIM-SAN
SNIA Tutorial > Questions and Answers
Introduction
Storage Management
Initiative
Questions and Answers
CIM and WBEM Basics
The following questions will help to reinforce the information you have just read.
SMI-S 1.1.0 The acronym FCAPS represents five different aspects of manageability. What are they?
Functionality
Fault Management
Resources and Configuration Management
References Accounting Management
Performance Management
Questions & Answers Security Management
How many versions of the SMI-S have been published?
Four and a fifth is scheduled for December 2005. The Bluefin specification was
published in May 2002, SMI-S 1.0.0 in July 2003, SMI-S 1.0.1 September 2003, SMI-
S 1.0.2 in February 2004 and SMI-S 1.1.0 is scheduled to be published in December
2005
What is the technology does SMI-S specify that Clients use to discover SMI Agents on a
SAN and determine their capabilities
The Service Location Protocol (SLP)
What does SMI-S stand for?
The Storage Management Initiative Specification
What is the difference between a General-Purpose SMI-S Server and a Dedicated SMI-S
Server?
A Dedicated SMI-S Server manages just one SAN resource while a General-
Purpose SMI-S Server can manage more than one SAN resource.
What is the relationship between a Profile and Subprofile?
A Subprofile represents an optional enhancement to a Profile. For example, for the

Array Profile, a vendor can choose, but is not required, to implement the Masking
and Mapping Subprofile to allow a Client to control access to the storage resources.
Must a vendor implement ALL the Classes in a Profile?

A vendor must implement all mandatory Classes defined in the Profile. However, not
all Classes in a Profile are mandatory. If a Class is designated as optional, then a
vendor can choose not to implement support for that Class.
Why are some Subprofiles called Common Subprofiles?
Some Subprofiles are called Common Subprofiles because they can be referenced
by many different types of Profiles. For example, the Location Subprofile applies to
any Profile that contains a physical component whose physical location may be
important to a Client.
What is the relationship between Storage Pools and Logical Disks?
The storage space for Logical Disks is allocated from Storage Pools?
What is the purpose of the xmlCIM specification?
To express CIM Data as XML elements as defined by the CIM Data Type Definition
(DTD) file.
What is a Recipe as defined in SMI-S?
A Recipe describes the specific WBEM operations that must be performed, the order
in which they must be performed and the argument values to be used for each
WBEM operation.
What is the Conformance Test Program?
The Conformance Test Program (CTP) is a test harness that is configured to

exercise a vendor's product for conformance to a particular Profile and Subprofiles.
What are the basic categories of WBEM Operations?
Data
MetaData
Association Traversal
Query Execution
Extrinsic Method Invocation
Qualifier Declarations
What is a Package as defined by SMI-S?
Like a Profile, a Package defines a set of CIM classes, the associations that will be
used to traverse between classes and the properties and extrinsic methods to be
used by the classes.
What is a major difference between a Package and a Subprofile?
The CIM elements of a Package are incorporated into the referencing Profile and
must be implemented as part of the Profile. In contrast, the CIM elements in a
Subprofile are not required to be implemented.
TRUE or FALSE. The Blades Subprofile is a Server Subprofile?
FALSE. It is a Switch Subprofile for Director Class Switch devices.
List the Packages defined by SMI-S 1.1.0?
Health
Physical Package
Software
Block Services
In SMI-S 1.1.0, list the Fabric Topology Profiles?
Fabric
Switch
Can a vendor implement additional Classes or support additional Properties than are
defined in a Profile and still be considered conformant?
Yes. A Profile only defines the minimal implementation requirements. A test suite
need only test for the required elements. Therefore, an implementation is considered
conformant even though it contains elements not in the Profile.
What discovery mechanism is used by WBEM?
The Service Location Protocol (SLP)
TRUE or FALSE? CIM-XML is the encoding of CIM data as XML elements?
FALSE. CIM-XML is the protocol that uses HTTP as the transport and xmlCIM as
the payload
In SMI-S 1.1.0, what is the meaning of a Profile that is marked as Experimental?
An Profile marked as Experimental means that its definition is subject to change.
What is the purpose of the Location Subprofile?
The Location Subprofile allows a Client to retrieve information about the physical
location of the device or element managed by the referencing Profile.
TRUE or FALSE? The Access Points Subprofile is a Common Subprofile.
TRUE
When might a Profile want to reference the Job Control Subprofile?

If a Profile defines a long running operation, then it may reference the Job Control
Subprofile because the purpose of the Subprofile is to spawn a job to monitor the
progress and completion of a long running operation. Without it, the Client must wait
for the operation to complete before resuming operation. Doing so may not be
desired.
Why was the Conformance Test Program (CTP) created?
Defining Profiles in SMI-S 1.1.0, by itself, does not ensure interoperability.

Implementation errors, design flaws and misinterpretation of the specification can
prevent this goal. CTP exercises an implementation to verify that it behaves
correctly.
Which specification defines the WBEM operations used by SMI-S 1.1.0?
CIM Operations over HTTP Specification v2.3. This specification is published by the
Distributed Management Task Force (DMTF).
TRUE or FALSE? The NAS Head Profile allows a Client to manage File Systems and File
Shares on a Network Attached Storage (NAS) system that includes local storage.
FALSE. The NAS System managed by this Profile does NOT include local storage.
When was the Storage Management Initiative (SMI) started?
2002
How does a Client discover the SMI Agents on a Storage Area Network (SAN)?
A Client uses the Service Location Protocol (SLP).
TRUE or FALSE? CIM data is mapped into XML elements using a Document Type
Definition (DTD).
TRUE. The DMTF CIM DTD defines the XML elements for the CIM meta schema.
What is a Durable Name?
In SMI-S 1.1.0, a Durable Name allows a Client to determine when two different CIM
Object Names refer to the same real world SAN resource.
The SMI-S 1.1.0 identifies two different roles that a SMI Agent can perform. What are
they?
A SMI Agent can be a Dedicated Server that manages just one SAN resource.
Alternatively, a General Purpose Server that manages more than one SAN resource.
What is the purpose of the Server Profile?
The Server Profile allows a Client to manage and retrieve information about a SMI
Agent and its components.
TRUE or FALSE? The Associators operation returns the Association classes that refer to a
particular Class.
FALSE. This is the definition of the References operation.
What version of the CIM Schema is SMI-S 1.1.0 based on?
CIM Schema version 2.11
How many Storage Profiles are defined in SMI-S 1.1.0?
Six. Array, Volume Management, NAS Head, Self-Contained NAS System, Storage
Library and Storage Virtualizer
What is a Proxy Dedicated Server?
A Proxy Dedicated SMI-S Server is one that is hosted on a system separate from its
managed storage resource and communicates with the remote resource using a
network protocol.
What is the purpose of the FC Target Ports Subprofile?
The FC Target Ports Subprofile allows a Client to discover the ports on a storage
system using Fibre Channel (FC) that are acting as front-end ports.
TRUE or FALSE. A Profile can reference other Profiles.
FALSE
What are the types of Durable Names recognized by the SMI-S 1.1.0?
SCSI Logical Units that are exported from storage systems

External Ports on hosts and storage devices
Fibre Channel ports on interconnect elements
Fibre Channel fabric
Storage systems
Operating system device
TRUE or FALSE? The SMI-Lab program manages a test lab that is available 24 hours a
day, 7 days a week.
TRUE. This lab is supplied with equipment from all leading storage product vendors.
What is the purpose of the Enhanced Zoning and Enhanced Zoning Control Subprofile?
The Enhanced Zoning and Enhanced Zoning Control Subprofile allows a Client to
manage Zone Aliases in a Fabric
TRUE or FALSE? Only an Association Class can have a Reference Property.
TRUE.
What does the CTP use to determine what tests to run?
For each Profile and Subprofile, an XML file explicitly defines the CIM elements used
along with the permissible values allowed. Using an XML file, the CTP exercises the
product for conformance to the SMI-S Profile and Subprofile definition.
The SMI-S 1.1.0 defines five levels of functionality that it covers. What are they?
Level 5 Application Level Functionality - allows a Client to manage

applications (e.g., database, mail server, etc) in a SAN that use data at the
File/Record level.
Level 4 File/Record Level Functionality - allows a Client to manage SAN
resources that expose data as files or records such as filesystems.
Level 3 Block Level Functionality - allows a Client to manage the SAN
resources that are used by the File/Record resources such as Storage
Volumes (e.g., LUNs) and Logical Disks.
Level 2 Connectivity Level Functionality - allows a Client to manage the
connectivity between physical devices in a SAN such as Fabrics, Zones and
iSCSI Sessions.
Level 1 Device Level Functionality - allows a Client to manage the physical
devices in a SAN such as Host Based Adapters (HBA) and disk drives.
TRUE or FALSE. A Subprofile can reference other Subprofiles.
TRUE
What is the purpose of the Device Credentials Subprofile?
The Device Credentials Subprofile allows a Client to change the shared secret (i.e.,
password) that is used to control access to the devices of the referencing Profile.
When the SMI-S designates a Profile to be Deprecated, what does that mean?
A Deprecated Profile should not be used in new development.
TRUE or FALSE. A Subprofile does not contain Recipes.
FALSE

SMI Technical Tutorial

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SMI Technical Tutorial

Uploaded by

Copyright:

Available Formats

SMI Tutorial > Introduction

Netscape Navigator, Firefox or Internet Explorer

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles

Profiles | Subprofiles | Packages

Downloading the Tutorial

Through the contributions of hundreds of engineers, vendors, end-users and industry

Resources and SNMP

However, network technology has evolved. Enterprises have increasingly integrated

SMI-S 1.1.0 Overview

The following sections describe each in further detail.

Questions & Answers Specification

An Association is a specialized Class that is used to represent a relationship between two

[Description(An example of using the Description Qualifier on a Class element]

System Address: 192.168.0.200

Extrinsic Method Invocation

Level 5 Application Level Functionality - allows a Client to manage applications

Resources and Bluefin in May 2002

SMI-S 1.1.0 Overview CIM-XML | xmlCIM | SLP

SMI-S 1.1.0 Overview CIM-XML | xmlCIM | SLP

M-POST /cimom HTTP/1.0

SMI-S 1.1.0 Overview CIM-XML | xmlCIM | SLP

<CLASS NAME="CIM_LogicalPort" SUPERCLASS="CIM_LogicalDevice">

SMI-S 1.1.0 Overview CIM-XML | xmlCIM | SLP

The SLP defines the following three roles:

The address of the SMI Agent (e.g., http://192.168.0.200:5988)

SMI-S 1.1.0 Overview How to Read Profiles | How to Read Recipes

NOTE: Any sections marked as Experimental will not be discussed.

SCSI Logical Units that are exported from storage systems

Health and Fault Management

Use of Profiles and Subprofiles

SMI-S 1.1.0 Overview How to Read Profiles | How to Read Recipes

Registered Subprofile Name Mandatory Version

Discover The Fabric Topology

Element Name Description

SMI Referenced Properties/Methods for CIM_FCPort

Property Flags Type Description and Notes

Specification Revision Organization

SMI-S 1.1.0 Overview How to Read Profiles | How to Read Recipes

Description - describes the purpose of the Recipe

Step 1 performs the WBEM operation GetInstance to an instance of

// Step 1: Check the version of the supported profile. Based on the

// Step 2: For each Profile, traverse the SubProfileRequiresProfile

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

In SMI-S 1.1.0, the following groups of Profiles have been defined:

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

SMI-S 1.1.0 Fabric | Switch

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

SMI-S 1.1.0 Fabric | Switch

Using this Profile, a Client can do the following:

Zone Control allows a Client to actively manage Fabric zoning

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

SMI-S 1.1.0 Fabric | Switch

Using this Profile, a Client can do the following:

Enable, disable or reset the Switch device

Blades - allows a Client to manage a Director Class Switch

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

Enumerate, create or delete a Storage Pool, Storage Volume or Logical Disk

Enumerate, create or delete a Storage Pool or Logical Disk

Access Points - allows a Client to discover remote management interfaces to the

SMI-S 1.1.0 Overview Fabric Topology | Server | Storage | Host

Using this Profile, a Client can do the following:

Enumerate, create or delete a Storage Pool or Logical Disk