SNIA Developer Conference September 15-17, 2025 | Santa Clara, CA
Develop Vendor Schema
The CIM is used to model the components of an SMI Implementation. The CIM specification describes an object-oriented meta model based on the UML. This model includes expressions for common elements that must be presented to management applications. The specification defines the meta-model (classes, properties, methods, associations, etc), syntax and rules. The specification also defines a text-based grammar named Managed Object Format (MOF).; A schema is a set of classes with a single owner. A class is named
The DMTF publishes the CIM Schema. The CIM Schema contains classes used in IT environments, such as computer systems, networking, applications, storage, etc. Each class contains properties that represent attributes of a managed element. For example, in the context of SMI, CIM_DiskDrive is a class containing the properties of a disk drive, such as DefaultBlockSize. There are special classes called associations whose primary purpose is to define a relationship between two classes. Associations are used to navigate from one class to another. For example, CIM_AllocatedFromStoragePool associates the CIM_StorageVolume allocated from a CIM_StoragePool. All class names in the CIM Schema have the schema name CIM. New versions of the DMTF CIM Schema are released periodically. Two DMTF CIM schema editions are published;
- Final - The Final CIM Schema classes, properties and extrinsic methods will never be removed or changed in an incompatible manner for a major version. Thus, any software written using CIM Schema version 2.39.0 will always be compatible with future CIM Schema versions such as 2.42.0. Although new classes, properties and extrinsic methods may be added over time to the CIM Schema, such changes do not affect backward compatibility.
- Experimental - The experimental CIM Schema includes the final schema and experimental content. The experimental schema does not promise backward compatibility. The experimental CIM Schema may contain classes that may be removed or changed in a future experimental schema version. Properties or extrinsic methods may also be removed or changed. Developers using Experimental classes must assume the risk of incompatibility with a future schema version. As a warning to developers, all experimental classes, properties and methods are marked Experimental (using the Experimental qualifier).
A version of the SMI Specification references a specific version of the DMTF CIM Schema. For example, SMI Specification version 1.6.1 requires a minimum version of the CIM Schema 2.41.0. A more recent CIM Schema may also be used.
The SNIA publishes the SNIA Schema. All SNIA class names use schema name SNIA. The SNIA schema is historical and replaced by the DMTF CIM classes, but the classes must be used for backward compatibility. As of SMI 1.7.0, the SNIA schema will no longer be supplied/needed as all classes will referenced in the specification will be part of the CIM Schema.
An SMI Implementation requires creating a vendor schema. A vendor schema is an extension schema of the model defined in the SMI-S for a specific device(s).
The following steps describe one way to create a vendor schema
- Download DMTF CIM Schema MOF files
- Download the SNIA Schema MOF files
- Create vendor specific MOF files
- Create a Vendor MOF include file
- Create an Impleementation MOF include file
- Create Profile Registration Classes
1. Download DMTF CIM Schema MOF files
The DMTF CIM Schema can be found here.
Download the version (or newer) referenced by the SMI-S. Download both the final and experimental MOF schema files.
The MOF files are packaged in a ZIP file. Unzip the file into a directory. You can also view the classes online in HTML format.
2. Download the SNIA Schema MOF files
The SNIA schema can be found here. Select the version that matches the SMI-S version.
The SNIA schema is packaged in a ZIP file. Unzip this file into the same directory as used in the previous step.
3. Create vendor specific MOF files
A vendor schema is the combined set of classes used by the profiles that have been chosen to be implemented. To determine the set of classes, the SMI Specification must be examined. For each profile, the SMI Specification contains a CIM Elements section, which contains a table showing a list of classes used by the profile. The Element Name column lists the class names. If the Requirements column in the table shows Mandatory, the class shall also be implemented. If the Requirements column in the table is Conditional, then a condition will also be listed. If the condition is true, then the class shall also be implemented. If the Requirements column in the table is Optional, the class may be implemented. Whether an Optional class is implemented may depend upon the features of the product. A vendor schema excludes any classes not used by the chosen profiles. For example, a vendor schema would not need to include CIM_FingerProfileReader, being as the SMI Specification does not use this class.
For each class to be implemented, identify the properties and methods to be implemented. The CIM Elements section contains a separate table for each class in the profile, which shows the list of properties and methods and the requirement level for each. The Properties column lists the property or method names. If the Requirements column in the table shows Mandatory, the property/method shall also be implemented. If the Requirement column in the table is Conditional, then a condition will also be listed and if the condition is true, then the property/method shall also be implemented. If the Requirement column in the table is Optional, the property/method may be implemented. For some properties, the Description and Notes column contains information about possible values the property may have. To determine which value the implementation should return, further information may be provided in the other sections of the profile. Additional information may also be in the description for the property in the MOF file.
For example, in the Copy Services profile, CIM_StorageReplicationCapabilities is a mandatory class. For this class, SupportedSynchronizationType is a mandatory property. The SMI Specification shows that SupportedSynchronizationType can have a value of 2, 3, 4, 5 or 6. The other sections of Copy Services explain what those values represent. The Description for SupportedSynchronizationType in CIM_StorageReplicationCapabilities.mof may also contain useful information. Note that the SMI Specification does not indicate the data type for a property. However, a provider developer requires this information. To determine the data type, examine the MOF file for the class. For example, CIM_StorageReplicationCapabilities.mof shows that SupportedSynchronizationType is an unsigned integer. More than one MOF file may need to be examined due to some properties being defined in a parent class. For example, the Description for the CIM_ComputerSystem.OperationalStatus property is found in CIM_ManagedSystemElement.mof.
Once all classes, properties and methods have been identified, a vendor schema is created by defining a set of MOF files, one for each class. Vendor subclasses are derived from the parent CIM/SNIA class. For example, ACME_Array is subclassed from CIM_ComputerSystem to represent the array in the Array profile. Here is an example.
[Description ("This is the vendor subclass for CIM_ComputerSystem")]
class ACME_Array : CIM_ComputerSystem {
...
};
Some profiles may use the same CIM class to represent different storage resources. For example, the Block Services Package uses CIM_StoragePool to represent both a concrete and primordial storage pool. To simplify implementation, separate CIM_StoragePool subclasses are defined; e.g., ACME_PrimordialStoragePool and ACME_ConcreteStoragePool. Here is an example.
[Description ("This is the vendor subclass for a"
"concrete storage pool")]
class ACME_ConcreteStoragePool : CIM_StoragePool {
};
[Description ("This is the vendor subclass "
"for a primordial storage pool")]
class ACME_PrimordialStoragePool : CIM_StoragePool {
};
Separate subclasses are defined when a profile uses the same association CIM class to relate different pairs of classes. For example, in the Copy Services profile, the CIM_ElementCapabilities is used to define the association between CIM_StorageReplicationCapabilities and CIM_StorageConfigurationService and also between CIM_StorageConfigurationCapabilities and CIM_StorageConfigurationService. Here, separate subclasses for ACME_ReplicationCapabilitiesForStorageConfigService and ACME_ConfigurationCapabilitiesForStorageConfigService could be defined. Here is an example.
[Association, Description ("This is the vendor subclass for CIM_ElementCapabilities that associates "
"ACME_StorageConfigurationService and ACME_StorageReplicationCapabilities")]
class ACME_ReplicationCapabilitiesForStorageConfigService : CIM_ElementCapabilities {
[Override ("ManagedElement" ), Key]
ACME_StorageConfigurationService REF ManagedElement;
[Override ("Capabilities" ), Key]
ACME_StorageReplicationCapabilities REF Capabilities;
};
ACME_ReplicationCapabilitiesForStorageConfigService would have references to ACME_StorageConfigurationCapabilities and ACME_StorageConfigurationService.
An SMI profile may not support a feature in a company product. In this case, the schema can be extended by defining new classes, properties, extrinsic methods or even new property value definitions. For example, a company product might have an additional type of storage pool synchronization. To support this feature, the vendor subclass, ACME_StorageReplicationCapabilities, would define an additional value for the SupportedSynchronizationType property using the Override qualifier, Here is an example.
[Description ("This is the vendor"
"subclass for the replication service capabilities")]
class ACME_StorageReplicationCapabilities : CIM_StorageReplicationCapabilities {
[Override ( "SupportedSynchronizationType" ),
Description("Added a new schronization type"),
ValueMap { "2", "3", "4", "5", "6", 7, "..", "32768..65535"},
Values { "Async", "Sync", "UnSyncAssoc-Full",
"UnSyncAssoc-Delta", "UnSyncUnAssoc", "ReSync",
"DMTF Reserved", "Vendor Specific" }]
uint16 SupportedSynchronizationType;
...
};
A company can suggest that extensions be incorporated into a future SMI-S using the SNIA Feedback Portal.
4. Create a Vendor MOF include file
A MOF include file is a MOF file that only has include statements that reference the files that make up a particular schema or a subset of a schema.
To create a vendor MOF include file, a separate MOF file that references each MOF file must be created. The MOF file is usually named using the schema name and version, for example, ACME_Schema_1.0.0.mof. The MOF file contains a #pragma include for each MOF file to be included. The order of #pragma include statements is critical because forward references are not allowed. For this reason, ACME_StorageReplicationCapabilities precedes ACME_ReplicationCapabilitiesForStorageConfigService.mof. An example fragment of an include file is included below.
#pragma include("ACME_ConcreteStoragePool.mof")
#pragma include("ACME_PrimordialStoragePool.mof")
#pragma include("ACME_StorageConfigurationService.mof")
#pragma include("ACME_StorageReplicationCapabilities.mof")
#pragma include("ACME_ReplicationCapabilitiesForStorageConfigService.mof")
5. Create an Implementation MOF include file
The #pragma include statements for parent classes must also precede the vendor subclass #pragma include statements. For example, the #pragma include statements for the following parent classes must precede the #pragma include statement for ACME_ConcreteStoragePool:
#pragma include("CIM_ManagedElement.mof")
#pragma include("CIM_ManagedSystemElement.mof")
#pragma include("CIM_LogicalElement.mof")
#pragma include("CIM_ResourcePool.mof")
#pragma include("CIM_StoragePool.mof")
The order of #pragma include statements for parent classes is also critical because a parent class must precede its subclass. CIM_ManagedElement precedes CIM_ManagedSystemElement because CIM_ManagedElement is the parent class of CIM_ManagedSystemElement and so on. Separate MOF include files can be created for the parent classes (CIM) and vendor classes (ACME) if desired. Manually creating a MOF include file in the proper order, can be a time-consuming task. See Development Tools for tools that automate this step.
6. Create Profile Registration Classes
An SMI Implementation uses two namespaces (technically you could put it all in the interop namespace, but convention is to use two or more namespaces). One namespace contains the set of CIM and vendor classes needed to run, configure and manage the WBEM Server itself. Often, this namespace is called interop or root/interop. The other vendor-specific namespace contains the set of CIM and vendor classes needed to run, configure and manage the storage product. A separate MOF include file is created for each namespace. The steps above describe how to create the MOF include file for the vendor namespace. The SMI Specification defines a Profile Registration profile that must be supported. Usually, this profile is supplied as part of the WBEM Server infrastructure and does not need to be implemented. The classes for the Profile Registration profile are defined in the interop namespace. An SMI Implementation uses the Profile Registration profile to advertise to SMI Clients which SMI profiles are supported. For each SMI profile implemented, additional profile-specific classes must be added to the interop namespace using a MOF include file. As an example, to add support for the Array 1.6.0 profile to support the SMI Specification 1.6.1, the MOF include file would contain
#pragma include("ACME_Array16RegisteredProfile.mof")
#pragma include("ACME_Array16RegisteredProfileConformsToSMIS161.mof")
#pragma include("ACME_ArrayConformsToArray16Profile.mof")
The first #pragma include statement is the MOF file that defines the vendor subclass of CIM_RegisteredProfile for the Array profile. The second statement is the vendor subclass of CIM_ElementConformsToProfile that relates ACME_Array16RegisteredProfile to the SMI 1.6.1 CIM_RegisteredProfile vendor subclass. This class is needed because the Array profile is an autonomous profile of SMI version 1.6.1. The third statement is the vendor subclass of CIM_ElementConformsToProfile that relates ACME_Array to ACME_Array16RegisteredProfile. This class is needed for an SMI client to find the central instance for the Array profile. These three statements are the pattern for an autonomous profile.
The pattern for a component profile is similar. Here is an example for Copy Services 1.5.0 to support the SMI Specification 1.6.1.
#pragma include("ACME_CopyServices15RegisteredProfile.mof")
#pragma include("ACME_CopyServices15ReferencesArray16.mof")
#pragma include("ACME_CopyServices15RegisteredProfileConformsToSMIS161.mof")
- The first #pragma include statement is the MOF file that defines the vendor subclass of CIM_RegisteredProfile for the Copy Services profile.
- The second statement is the vendor subclass of CIM_ReferencedProfile that relates ACME_CopyServices15RegisteredProfile to ACME_Array16RegisteredProfile. This class is needed because the Copy Services profile is a component profile of the Array profile.
- The third statement is the vendor subclass of CIM_ElementConformsToProfile that relates ACME_CopyServices15RegisteredProfile to the SMI 1.6.1 CIM_RegisteredProfile vendor subclass. This class is needed because the Copy Services profile is a component profile used by SMI version 1.6.1. These three classes are the pattern for all component profiles.
After following each step, a set of MOF files have been created that can be integrated into the SMI Implementation to support desired profiles and product features.