SMI Tutorial > SMI-S 1.1.0 Overview > How to Read SMI-S 1.1.0


How to Read SMI-S 1.1.0



The Storage Management Initiative Specification v1.1.0 (SMI-S 1.1.0) is organized into 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 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.


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.


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.


Back Next