Tutorial Requirements - WBEM Solutions · Welcome to the Storage Networking Industry Association...

Introduction

Storage Management Initiative

CIM and WBEM Basics

SMI-S 1.1.0 Overview

SMI-S 1.1.0 Functionality

Resources and References

Questions & Answers

SMI Tutorial > Introduction

Introduction

Welcome to the Storage Networking Industry Association (SNIA) SMI Technical Tutorial. 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 tutorial, you will have sufficient knowledge of the organization of information in SMI-S to properly interpret its contents. Such understanding will allow for the proper implementation of an SMI compliant product.

The tutorial is designed for users who have no prior knowledge of SMI and SMI-S 1.1.0. It 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.

http://www.snia.org/

http://www.wbemsolutions.com/tutorials/CIM/

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

http://www.wbemsolutions.com/tutorials/snia/SMI/Technical/SMI_Technical_Tutorial.pdf


http://www.wbemsolutions.com/

Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Introduction > Executive Summary

Executive Summary

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 tutorial is by no means intended to be a replacement for reading the SMI-S 1.1.0. However, after completion, one will have sufficient knowledge of the organization of information in the SMI-S to more easily absorb its contents.

First, the tutorial provides background information about the SMI. It describes the 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Storage Management Initiative


History of Management Protocols | History of SMI

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 interface for the management of storage networks.

Originally founded by several leading industry engineers and leaders, the SMI now consists of more than 50 member companies, a dozen individual contributors, plus hundreds of volunteers working across the SNIA organization.

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 industry’s 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 industry’s 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Storage Management Initiative > History of Management Protocols

History of Management Protocols


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 Programming Interfaces (API). Neither meet current needs.

SNMP

The most common system management infrastructure is based upon SNMP. Its 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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Storage Management Initiative > History of SMI

History of SMI


2002

● 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 open interface for the management of storage networks.

● The Storage Management Initiative Specification (SMI-S) was created to support the development and promotion of the industry's first standard interface for storage 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > CIM and WBEM Basics

CIM and WBEM Basics

CIM | WBEM

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 meta-model elements. The DMTF has also published a CIM Schema. Using the meta-model rules and syntax, CIM objects have been defined for many different components and aspects in an enterprise computing environment. SMI-S 1.1.0 uses these CIM object definitions.

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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > CIM and WBEM Basics > CIM

CIM

CIM | WBEM

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. For example, CIM can be used to describe the characteristics of a computer system. CIM is also used to depict the relationships between different managed objects. For example, CIM can be used to depict the relationship of disks that are connected to a computer system. CIM consists of a specification and a schema.

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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > CIM and WBEM Basics > WBEM

WBEM

CIM | WBEM

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 Clients and WBEM Agents in an enterprise computing environment. The Distributed Management Task Force (DMTF) defines a set of WBEM Operations that allow a Client to retrieve CIM data and to request that operations be performed on CIM data by the WBEM 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.

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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview


SMI-S History | SMI-S 1.1.0 Requirements | How to Read SMI-S 1.1.0

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 of a Storage Area Network (SAN) that is a heterogeneous environment of management applications, storage devices and storage systems from different vendors. The interface uses standards based protocols and specifications to provide interoperability, security and extensibility. The SMI-S leverages the Common Information Model (CIM), Web Based Enterprise Management (WBEM) and the Service Location Protocol (SLP).

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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S History

SMI-S History


Several versions of the Storage Management Initiative Specification (SMI-S) have been published by the Storage Networking Industry Association (SNIA). IThe versions published are:

● Bluefin in May 2002● SMI-S 1.0 in July 2003● SMI-S 1.0.1 in September 2003● 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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements

SMI-S 1.1.0 Requirements


CIM-XML | xmlCIM | SLP

The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN) 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 standards technologies as the foundation for the architecture. Specifically, the SMI-S 1.1.0 uses the following:

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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > CIM-XML

CIM-XML



CIM-XML is the protocol that is used by SMI-S 1.1.0 to exchange CIM and WBEM 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 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.

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.0Content-Type: text/xml;charset=UTF-8Accept: text/xml, application/xmlMan: http://www.dmtf.org/cim/mapping/http/v1.0;ns=4848-CIMProtocolVersion: 1.048-CIMOperation: MethodCall48-CIMMethod: GetClass48-CIMObject: root%2Fcimv2User-Agent: Java1.2.1Host: edoc5-pcContent-length: 445<?xml version="1.0" encoding="UTF-8"?>





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > xmlCIM

xmlCIM



xmlCIM is a standard way to represent CIM data using the Extensible Markup Language (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. 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 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"> <QUALIFIER TRANSLATABLE="true" NAME="Description" TYPE="string"> <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"> <QUALIFIER TRANSLATABLE="true" NAME="Description" TYPE="string"> <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>




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Overview > SMI-S 1.1.0 Requirements > SLP

SLP



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





Introduction


CIM and WBEM Basics




Questions & Answers

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

How to Read SMI-S 1.1.0


How to Read Profiles | How to Read Recipes

Introduction

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.

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.




Introduction


CIM and WBEM Basics




Questions & Answers

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

How to Read a Profile



Much of the SMI-S 1.1.0 is devoted to describing each Profile and Subprofile in sufficient detail to allow full and proper implementation by a developer. Their descriptions use the same pattern, which consists of

● General Description ● 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 VersionAccess Points No 1.1.0


Disk Drive Lite No 1.1.0Location No 1.1.0Software 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,

Operational Status Possible Subsidiary Operational Status Description

OK The system has good status

Degraded The system will probably fail sometime soon

Error Non-recoverable error A severe error has occurred. Operator 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 DescriptionMandatory Classes

CIM_ComputerSystem (pg. 863) This declares that at least one computer system must pre-exist

CIM_FileShare (pg. 886) Represents the sharing characteristics of a particular file element

Optional ClassesCIM_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 DescriptionMandatory Indications

SELECT * FROM CIM_InstCreation WHERE SourceInstance ISA CIM_ComputerSystem

Addition of a new array instance

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 NotesMandatory Properties/Methods

SystemName string The scoping System's name

OperationalStatus uint16[] One of the defined values shall be 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 DMTFCIM Operations over HTTP 1.2.0 DMTFCIM Schema 2.11.0 DMTF




Introduction


CIM and WBEM Basics




Questions & Answers

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

How to Read a Recipe



A Profile, Subprofile or Package can define Recipes that a Client may use to perform a particular management task on the elements being managed. 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 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// Profilefor #i in $Subprofiles[ ] { #SubprofileVersion = $Subprofile[#i].RegisteredVersion if (!compare(#SubprofileVersion, #ProfileVersion)) { Error(“Subprofile version mismatch with Profile version”) }}




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality



The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN) that is a heterogeneous environment of management applications, storage devices and storage systems. The SMI-S 1.1.0 achieves this goal by using the Common Information Model (CIM), Web Based Enterprise Management (WBEM) and by defining Profiles and Subprofiles.

A Profile defines the base set of information and capabilities that allows a Client to 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles

SNIA Profiles


Fabric Topology | Server | Storage | Host

A SNIA Profile defines the base set of information and capabilities that all implementations 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 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 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > Fabric Topology Profiles

Fabric Topology Profiles



Fabric | Switch

SMI-S 1.1.0 defines the following Profiles that relate to the management of Fabric topology:

● 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Fabric Topology Profiles > Fabric Profile

Fabric Profile



Fabric | Switch

The Fabric Profile allows a Client to manage a Fibre Channel Fabric. 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. 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Fabric Topology Profiles > Switch Profile

Switch Profile



Fabric | Switch

The Switch Profile allows a Client to manage a Fibre Channel Switch device. Disk arrays and tape libraries typically have a fixed number of physical Ports. Hence, they can only be attached to a limited number of systems. Alternatively, their physical Ports can be 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Server Profile

Server Profile



The Server Profile allows a Client to manage and retrieve information about a SMI Agent and its components. Using this Profile, a Client can do the following:

● Find the SMI Agents on a network that support a particular Profile ● Determine all the Profiles and Subprofiles supported by a particular SMI Agent ● 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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles

Storage Profiles



Array | Volume Management | NAS Head | Self-Contained NAS System Storage Library | Storage Virtualizer

In SMI-S 1.1.0, several Profiles are defined for managing storage devices on a Storage Area Network (SAN). Each Profile is focused on a different aspect of storage device 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Array Profile

Array Profile




The Array Profile allows a Client to manage external RAID arrays and disk storage systems. Using this Profile, a Client can do the following:

● 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:


● Access Points - allows a Client to discover remote management interfaces to the 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Volume Management Profile

Volume Management Profile




The Volume Management Profile allows a Client to manage storage as virtual resources 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 ● Return allocated capacity to a Storage Pool ● 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:


● 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

● Extent Composition - allows a Client to retrieve information about the allocation hierarchy of storage pools and logical disks within the device

● Location - allows a Client to retrieve information about the physical location of the system hosting the device

● Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and snapshots in the virtual array

● Job Control - allows a Client to asynchronously monitor a long running operation on the virtual array

● Multiple Computer System - allows a Client to retrieve information about the 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > NAS Head Profile

NAS Head Profile




The NAS Head Profile allows a Client to manage File Systems and File Shares on a Network Attached Storage (NAS) system that does not include local storage. Instead, the 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:

● Enumerate, create or delete a Storage Pool or Logical Disk ● Change the capacity of a Storage Pool or Logical Disk ● Return allocated capacity to a Storage Pool ● Enumerate the Extents in a Storage Pools that may be used to create or expand a

Storage Volume or 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


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:


● Extent Composition - allows a Client to retrieve information about the allocation hierarchy of storage pools and logical disks within the NAS system

● Location - allows a Client to retrieve information about the physical location of the NAS system

● Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and snapshots in the NAS system

● Job Control - allows a Client to asynchronously monitor a long running operation on the NAS system

● Multiple Computer System - allows a Client to retrieve information about the 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 that are acting as initiator ports

● 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

● Device Credentials - allows a Client to change the shared secret (i.e., password) that is used to control access to the NAS system

● File Export Manipulation - allows a Client to manage File Shares on the NAS system




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Self Contained NAS System Profile

Self-Contained NAS System Profile




The Self-Contained NAS System Profile allows a Client to manage File Systems and File 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 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 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 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:

● Enumerate, create or delete a Storage Pool or Logical Disk● Change the capacity of a Storage Pool or Logical Disk ● Return allocated capacity to a Storage Pool ● Enumerate the Extents in a Storage Pools that may be used to create or expand a

Storage Volume or 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


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:


● Extent Composition - allows a Client to retrieve information about the allocation hierarchy of storage pools and logical disks within the NAS system

● Location - allows a Client to retrieve information about the physical location of the NAS system

● Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and snapshots in the NAS system

● Disk Drive Lite - allows a Client to retrieve information about the disk drives in the NAS system

● Job Control - allows a Client to asynchronously monitor a long running operation on the NAS system

● Multiple Computer System - allows a Client to retrieve information about the 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 that are acting as initiator ports

● SPI Initiator Ports - allows a Client to discover all of the Parallel SCSI ports of the NAS system that are acting as initiator ports

● Device Credentials - allows a Client to change the shared secret (i.e., password) 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Storage Library Profile

Storage Library Profile




The Storage Library Profile allows a Client to manage a storage library and its components. A storage library consists of the following components:

● 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:


● Location - allows a Client to retrieve information about the physical location of the 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Storage Profiles > Storage Virtualizer Profile

Storage Virtualizer Profile




The Storage Virtualizer Profile allows a Client to manage a RAID array that does not include any local storage. Instead, the virtual storage system uses external storage 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

changes (e.g., from “OK” to “Degraded”) ● 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 ● Return allocated capacity to a Storage Pool ● Enumerate the Extents in a Storage Pools that may be used to create or expand a

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:


● Location - allows a Client to retrieve information about the physical location of the storage system

● Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and snapshots in the storage system

● Job Control - allows a Client to asynchronously monitor a long running operation on the storage system

● Extent Composition - allows a Client to retrieve information about the allocation hierarchy of storage pools and storage volumes within the storage system

● Multiple Computer System - allows a Client to retrieve information about the redundancy configuration and capabilities of the storage system

● Software - allows the Client to retrieve information about the software used by the 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles

Host Profiles



FC HBA | iSCSI Initiator

SMI-S 1.1.0 defines the following Profiles that relate to the management of components attached to host systems:

● 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles > FC HBA Profile

FC HBA Profile




The FC HBA Profile allows a Client manage the Fibre Channel (FC) ports on a system using a Host Based Adapter (HBA). Using this Profile, a Client can do the following:

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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Profiles > Host Profiles > iSCSI Initiator Profile

iSCSI Initiator Profile




The iSCSI Initiator Profile 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. This combination is called an iSCSI initiator. Using this Profile, a Client can do the following:

● 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 identification number (e.g., SKU).

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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles

SNIA Subprofiles


Common | Common Target Ports | Common Initiator Ports Server | Fabric | Switch | Storage

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 perform the additional management tasks provided by the Subprofile. The Subprofile also defines the associations that will be used to traverse between classes. In addition to 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.




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles

Common Subprofiles



Access Points | Device Credentials | Job Control Location | Multiple Computer System | Software

A SNIA Subprofile can be referenced by a SNIA Profile to allow optional inclusion of 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

● Device Credentials - allows a Client to change the shared secret (i.e., password) 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

● Location - allows a Client to retrieve information about the physical location of the 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Access Points Subprofile

Access Points Subprofile




The Access Points Subprofile is referenced by other SNIA Profiles as an optional 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Device Credentials Subprofile

Device Credentials Subprofile




The Device Credentials Subprofile is referenced by other SNIA Profiles as an optional 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







Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Multiple Computer System Subprofile

Multiple Computer System Subprofile




The Multiple Computer System Subprofile is referenced by other SNIA Profiles as an 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



● Storage Virtualizer Profile - allows a Client to manage a RAID array that does not


include any local storage● Switch Profile - allows a Client to manage a Fibre Channel Switch device● Block Server Performance Subprofile - allows a Client to manage the collection of

performance statistics for a server that uses block I/O




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Job Control Subprofile

Job Control Subprofile




The Job Control Subprofile is referenced by other SNIA Profiles as an optional 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:



● 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 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

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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Location Subprofile

Location Subprofile




The Location Subprofile is referenced by other SNIA Profiles as an optional enhancement 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:






● Volume Management Profile- allows a Client to manage storage as virtual resources using a software storage management subsystem running on a host system





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Subprofiles > Software Subprofile

Software Subprofile




The Software Subprofile is referenced by other SNIA Profiles as an optional enhancement 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:







● Switch Profile - allows a Client to manage a Fibre Channel Switch device





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Target Ports Subprofiles > SPI Target Ports Subprofile

SPI Target Ports Subprofile



SPI Target Ports | FC Target Ports

The SPI Target Ports Subprofile is referenced by other SNIA Storage Profiles as an 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:


● Block Server Performance Subprofile - allows a Client to manage the collection of performance statistics for a server that uses block I/O





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Target Ports Subprofiles > FC Target Ports Subprofile

FC Target Ports Subprofile



SPI Target Ports | FC Target Ports

The FC Target Ports Subprofile is referenced by other SNIA Storage Profiles as an 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 Subprofiles to provide this additional capability:




● Block Server Performance Subprofile - allows a Client to manage the collection of performance statistics for a server that uses block I/O





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Common Initiator Ports Subprofiles > FC Initiator Ports Subprofile

FC Initiator Ports Subprofile



The FC Initiator Ports Subprofile is referenced by other SNIA Profiles as an optional enhancement. This Subprofile allows a Client to discover the ports on a system that use Fibre Channel (FC) to connect to its physical storage.

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:



● Self-Contained NAS System Profile - allows a Client to manage a storage library and its components



● FC HBA Profile - allows a Client to manage the Fibre Channel (FC) ports on a system using a Host Based Adapter (HBA)





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Server Subprofiles > Indications Subprofile

Indications Subprofile



Indications | Object Manager Adapter

The Indications Subprofile is referenced by the Server Profile as an optional enhancement that allows a SMI Agent to support indications. This Subprofile must be supported by SMI 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Server Subprofiles > Object Manager Adapter Subprofile

Object Manager Adapter Subprofile



Indications | Object Manager Adapter

The Object Manager Adapter Subprofile is referenced by the Server Profile as an optional 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Enhanced Zoning and Enhanced Zoning Control Subprofile

Enhanced Zoning and Enhanced Zoning Control Subprofile



Enhanced Zoning Control | Zone Control | FDMI | Fabric Path Performance

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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Zone Control Subprofile

Zone Control Subprofile




The Zone Control Subprofile is referenced by Fabric Profile as an optional enhancement 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > FDMI Subprofile

FDMI Subprofile




The FDMI Subprofile is referenced by the Fabric Profile as an optional enhancement that allows a Client to retrieve information about Fibre Channel Ports on a Host Based Adapter (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).





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Fabric Subprofiles > Fabric Path Performance Subprofile

Fabric Path Performance Subprofile




The Fabric Path Performance Subprofile is referenced by the Fabric Profile as an optional 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. Using this Subprofile, a Client can do the following:

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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Switch Subprofiles > Switch Configuration Data Subprofile

Switch Configuration Data Subprofile



Switch Configuration Data | Blades

The Switch Configuration Data Subprofile is referenced by the Switch Profile as an 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Switch Subprofiles > Blades Subprofile

Blades Subprofile



Switch Configuration Data | Blades

The Blades Subprofile is referenced by the Switch Profile as an optional enhancement for Director Class Switch devices. A Director Class Switch is one that has a large number of 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).





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles

Storage Subprofiles



File System Manipulation | File Export Manipulation | Block Services Resource Ownership Block Server Performance | Copy Services | Disk Drive Lite | Disk Sparing

Extent Composition | Masking and Mapping | Storage Library Limited Access Port Elements

The SNIA Storage Profiles can reference the following storage specific Subprofiles as 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Filesystem Manipulation Subprofile

File System Manipulation Subprofile





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 retrieve information about the File Systems on the NAS system. For example, 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 vendor may choose to support:

● Job Control - allows a Client to asynchronously monitor a long running operation





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > File Export Manipulation Subprofile

File Export Manipulation Subprofile





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

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 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 Profiles to provide this additional capability:



The Subprofile defines the following Subprofiles that represent optional features that a vendor may choose to support:


● Job Control - allows a Client to asynchronously monitor a long running operation




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Block Services Resource Ownership Subprofile

Block Services Resource Ownership Subprofile





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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Block Server Performance Subprofile

Block Server Performance Subprofile





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:



In addition, other Subprofiles can optionally take advantage of the performance statistics collection features provided by this Subprofile. They are:

● Multiple Computer System - allows a Client to retrieve information about the 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● Copy Services - allows a Client to manage local mirrors, remote mirrors, clones and

snapshots.● Disk Drive Lite - allows a Client to retrieve information about the disk drives in an

storage device




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Copy Services Subprofile

Copy Services Subprofile





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 provide this additional capability:




● Volume Management - allows a Client to manage storage as virtual resources using a software storage management subsystem running on a host system




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Disk Drive Lite Subprofile

Disk Drive Lite Subprofile





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 identification number (e.g., SKU).

The Disk Drive Lite Subprofile can optionally enhance the following storage Profiles and Subprofiles to provide this additional capability:



● Block Server Performance Subprofile - hat allows a Client to manage the collection of performance statistics of a server that uses block I/O





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Disk Sparing Subprofile

Disk Sparing Subprofile





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 provide this additional capability:







Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Extent Composition Subprofile

Extent Composition Subprofile





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:






The Extent Composition Subprofile can optionally enhance the following storage Subprofiles and Packages to provide this additional capability:

● Block Server Performance Subprofile - allows a Client to manage the collection of 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




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Masking and Mapping Subprofile

Masking and Mapping Subprofile





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


Profiles to provide this additional capability:






Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Subprofiles > Storage Subprofiles > Limited Access Port Elements Subprofile

Storage Library Limited Access Port Elements Subprofile





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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages

SNIA Packages


Health | Physical Package | Software | Block Services

A SNIA Package can be referenced by SNIA Profile. Like a Profile, a Package defines a 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 and extrinsic methods to be used. In certain cases, the Package even specifies the values a property or method argument can have.

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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Health Package

Health Package



The Health Package is referenced by a SNIA Profile to allow a Client to retrieve information about the status of the device managed by the Profile. A Client can also retrieve information about the state of the device components.

For example, the Array Profile references the Health Package. Doing so allows a Client to 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:









Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Physical Package Package

Physical Package Package



The Physical Package Package is referenced by a SNIA Profile to allow a Client to 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 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 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





● Switch Profile - allows a Client to manage a Fibre Channel Switch device ● 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Software Package

Software Package



The Software Package is referenced by a SNIA Profile to allow a Client to retrieve 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 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 information such as a build number.

The Software Package is referenced by the following Profiles and Subprofiles:

● Switch Profile - allows a Client to manage a Fibre Channel Switch device● 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





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > SMI-S 1.1.0 Functionality > SNIA Packages > Block Services Package

Block Services Package



The Block Services Package is referenced by storage related SNIA Profiles to allow a 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 the common elements and mechanisms that these devices use.

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 ● Return allocated capacity to a Storage Pool ● Enumerate the Extents in a Storage Pools 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”)

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:





This Package identifies the following Subprofiles which represent optional features that a vendor may choose to support:

● Job Control - allows a Client to asynchronously monitor a long running operation ● Extent Composition - allows a Client to retrieve the hierarchy of storage extents

used to create the storage element




Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Resources and References


Conformance Test Program | SMI-Lab | References

A vendor can take advantage of a couple of programs to help it deliver a SMI-S conformant product to market. They are:

● Conformance Test Program (CTP) allows a vendor to officially certify that their product conforms to a particular Profile in SMI-S 1.1.0

● SMI-Lab provides an environment that helps a vendor more quickly develop a SMI-S conformant prodcut.

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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Resources and References > Conformance Test Program

Conformance Test Program


The goal of the SMI-S 1.1.0 is to achieve interoperability in a Storage Area Network (SAN) that is a heterogeneous environment of management applications, storage devices and storage systems from different vendors. The first step towards this goal is the definition of Profiles and Subprofiles. They define the CIM elements that a Client and SMI Agent will use to perform particular storage management tasks.

However, by itself, the SMI-S 1.1.0 does not ensure interoperability. First, the specification 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Resources and References > SMI-Lab

SMI-Lab


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 conformant products to market. A SMI-Lab program organizes and coordinates several activities. One is the creation and management of a 7 x 24 testing environment at the SNIA Technology Center in Colorado Springs, CO. Supplied with equipment from all leading storage product vendors, participants have access to this equipment for testing purposes. Another is the series of meetings called Plugfests where storage management 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.





Introduction


CIM and WBEM Basics




Questions & Answers

SMI Tutorial > Resources and References > References

References


CIM and WBEM

● Distributed Management Task Force ● CIM Schemas ● 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



http://www.dmtf.org/

http://www.dmtf.org/standards/cim/

http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf

http://www.dmtf.org/standards/published_documents/DSP0200.pdf



http://www.dmtf.org/standards/wbem/wbem.1.0.en

http://www.dmtf.org/standards/wbem/CIM_DTD_V22.dtd



http://www.snia.org/ctp/

http://www.snia.org/apps/org/workgroup/techcouncil/tsg_smi/download.php/5122/SMIS_1_0_2_final.pdf

http://www.snia.org/dictionary/

http://www.snia.org/ctp/conformingproviders

http://www.snia.org/ctp/smi_conform

http://www.snia.org/smi/developers/

http://www.snia.org/smi/tech_activities/smilab/

http://www.snia.org/smi/tech_activities/CIMSAN/



Introduction


CIM and WBEM Basics




Questions & Answers

SNIA Tutorial > Questions and Answers

Questions and Answers

The following questions will help to reinforce the information you have just read.

The acronym FCAPS represents five different aspects of manageability. What are they?

● Fault Management● Configuration Management● Accounting Management● Performance Management● 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




Date post:	18-Jul-2019
Category:	Documents
Upload:	dothuy
View:	214 times
Download:	0 times

Tutorial Requirements - WBEM Solutions · Welcome to the Storage Networking Industry Association...

Documents