SMI-S Requirements
The first use of the Microsoft Standards-Based Storage Management service is in System Center 2012 Virtual Machine Manager (VMM). For Windows Server 2012, the Windows Standards-Based Storage Management Service is an optional component that supersedes the version supplied with VMM. Since VMM 2012 SP1 is compatible with Windows Server 2012, it uses the new storage service. Many new capabilities have been added for the Windows release and this document has been updated to reflect both versions. For simplicity, the term “storage service” will represent both products and differences are noted throughout the document.
The storage service provides Discovery, Provisioning and Monitoring capabilities for use by applications. The intent of the storage service is to provide simplified access to SMI-S functionality without requiring much SMI-S knowledge on the part of the user. Typically, functionality is exposed to applications (such as VMM) and end-users through a set of PowerShell cmdlets, part of the Storage Management API (SMAPI) in Windows Server 2012. The full functionality is also exposed through the Windows Management Instrumentation (WMI) layer.
In many cases, the exposed interfaces will obfuscate industry-specific terms in favor of terms that are more user-friendly. However, wherever possible, the underlying implementation of the storage service is faithful to SMI-S.
This set of topics will not duplicate SMI-S documentation or DMTF MOFs. Therefore, it is assumed that the reader is familiar with those standards.
Audience
This documentation is aimed at SMI-S hardware provider developers. The intent is to identify the SMI-S capabilities being used in VMM 2012, VMM 2012 SP1, and Windows Server 2012. It is not a comprehensive guide to all the required CIM classes that a provider needs to implement. Rather, it gives insight into how Microsoft will use the SMI-S providers to implement recipes and functionality. Also note that Windows Server 2012 has greater capabilities than VMM. These differences are called out when applicable throughout the documentation.
Devices
Fibre Channel and iSCSI Storage arrays are supported in all versions. Support for SAS arrays and Host Hardware RAID (HHRC) controllers has been added for Windows Server 2012.
Windows Server 2012 also includes a passthrough capability allowing access to any CIM classes defined by an SMI-S provider. Applications can use this to extend management to FC fabrics, for example. Passthrough allows accessing all vendor-unique properties and classes in addition to the subset of SMI-S defined classes used by the storage service. VMM 2012 SP1 uses this capability in addition to the SMAPI interfaces.
Conformance to Standards
Full array functionality will require SMI-S 1.4 or later conformance – all references in this documentation refer to SMI-S 1.6 clauses unless otherwise noted. All references in this documentation refer to SMI-S 1.6 clauses unless otherwise noted. Although passage of the SNIA Provider Conformance Testing Program (CTP) is a desired goal, it is not sufficient to ensure that a particular SMI-S provider will function properly in this environment as the service requires some optional classes and properties and CTP tests do not enforce all the mandatory requirements.
Additional standards that have been implemented include CIM-XML, CIM Operations over HTTP, Service Location Protocol (SLP) 2, CIM (2.29.1 Experimental, or in some cases, later MOFs) and SMI-S. (SMI-S often requires the Experimental DMTF MOFs; not the final MOFs.)
Note If a provider advertises a profile or subprofile by registering it (CIM_RegisteredProfile), it will be assumed that the provider conforms to that profile's (and version) requirements. CTP does not enforce this and instead lets vendors advertise any profile but bypass conformance testing.
Passive or readonly providers are not supported.
SMI-S Architecture
In addition to the referenced books and profiles, Windows requires strict conformance to the SMI-S Architecture Book. Special attention must be paid to Clause 7: Correlatable and Durable Names. Failure to follow these requirements will prevent the SMI-S provider from working properly - particularly masking operations - and that provider will not be supported for use with Windows.
Transport Protocols
This implementation supports CIM/XML and WMI (Windows Management Instrumentation) transports only. While the service supports HTTP (except for indications), the preferred transport for CIM/XML is HTTPS.
Namespaces
All providers must support the interop or root/interop namespace for CIM-XML providers and root\interop for WMI-based providers. The interop namespace is used to locate supported profiles, and from there, discovery of the vendor-specific namespaces(s) can be performed. See the SMI-S Architecture Book for more information.
The current implementation supports some well-known interop namespaces:
| Namespace | Notes |
|---|---|
| interop | It is expected that all standalone CIMXML providers will use this namespace. Indications are supported in this namespace only. |
| root\interop | Used by WMI-based providers only. |
| root/PG_InterOp | Used by some older OpenPegasus-based providers. |
Note A provider may advertise a different interop namespace through SLPv2. While the storage service will send an Attribute Request (AttrRqst) to the provider, it is the vendor's responsibility to ensure this request is received and responded to promptly.
Installation Requirements for SMI-S Proxy Providers
While a provider can be embedded or a proxy installed on a non-Windows system, the following requirements are in place for any provider that installs on Windows.
| Requirement | Description |
|---|---|
| Provider must be installed as a service | Provider must run as a Windows service (or as a daemon on *nix systems) and not as an interactive application, except for debugging purposes. |
| Provider running on Windows must install on supported current releases of Windows Server | Windows Server 2008, Windows Server 2008R2, and Windows Server 2012 are currently the only supported platforms. The provider must install properly for those versions of the operating system and, unless the provider requires inband FC or SAS access to the arrays, the provider must support running on a virtual machine. For inband access, Hyper-V passthrough devices may be used to enable a provider to run on a VM. In that case, Hyper-V must be configured to disable SCSI filtering for LUNs requiring access for the purpose of management. By default, this is enabled, blocking most SCSI CDBs. It is the vendor's responsibility to configure this properly as part of the installation routine for the provider. |
| Provider must install properly using Windows guidelines | In addition to the Windows User Account Control (UAC) Guidelines, the provider should not require special Windows administrative accounts and all accounts in the Administrators group must be supported. Also note that customers frequently lock down systems by disabling or renaming the local administrator account. |
| Firewall | Any application or service must not disable - or suggest that a user disable - the firewall. The application or service must work properly with the inbox firewall, which is a standard component installed by Windows. Rules must be added during installation for inbound and outbound traffic, but must be as specific as possible (scoped to the correct type of network, the specific program, specific ports, direction, and so on). A best practice is for the installer to instantiate the appropriate firewall rules. The installer should not assume that the firewall will allow outbound connections even if that is the default setting; explicit rules should be added. |
| IPv6 | All providers running on Windows must support IPv6 as well as IPv4 and 6to4 tunneling addresses without any additional configuration steps. Customers run in mixed and single dialect environments. Therefore, any HTTP or HTTPS listener must listen on all interfaces or be configurable to enable/disable any specific interface. URL formats for IPv6 are defined in RFC 2732 and providers must adhere to that specification. |
| IPsec | IPsec policy may prevent a provider from being accessed by a management system and may prevent deliver of indications if the provider and the storage service are not in the same domain or are subject to different filtering policies. |
| Provider must support HTTPS | The recommended practice is to validate certificates. When a provider installs and creates a certificate for use by its HTTPS server, that certificate will be checked by the Storage Service. The service always checks for a valid date range and may be configured to check for a common name equivalent to the server name (optional). Support for TLSv1.2 is recommended. |
| Vendor must handle configuration of their provider | Examples include being able to easily add and remove arrays, management of array credentials, management of security credentials (unless Windows native security is employed) and certificates, and configuration of any optional feature such as tracing and logging. The storage service will not add or remove arrays through the use of CIM instances. |
Related topics
ISV Application Readiness and Certification