SMI-S profiles

This chapter lists SMI-S profiles implemented by OpenLMI-Storage. The implementation does not follow SMI-S strictly and deviates from it where SMI-S model cannot be used. Each such deviation is appropriately marked.

OpenLMI-Storage implements following profiles:

• SMI-S Disk Partition Subprofile
  • Profile adjustment
  • Implementation
• SMI-S Block Services Package
  • Primordial pool
  • Logical disks
  • Implementation
• SMI-S Extent Composition Subprofile
• SMI-S File Storage Profile
• SMI-S Filesystem Profile
  • Implementation
• SMI-S Filesystem Manipulation Profile
  • Implementation
• SMI-S Job Control Subprofile
  • Implementation
• SMI-S Block Server Performance Subprofile
  • Implementation

The OpenLMI-Storage CIM API follows following principles:

• Each block device is represented by exactly one CIM_StorageExtent.

• For example RAID devices are created using LMI_StorageConfigurationService. CreateOrModifyElementFromElements, without any pool being involved.
• No CIM_LogicalDisk is created for devices consumed by the OS, i.e. when there is a filesystem on them.

• Actually, all block devices can be used by the OS and it might be useful to have LMI_StorageExtent as subclass of CIM_LogicalDisk.

Warning

This violates SMI-S, each block device should have both a StorageExtent + LogicalDisk associated from it to be usable by the OS.

• CIM_StoragePool is used only for real pool objects - volume groups.
• PrimordialPool is not present. It might be added in future to track unused disk drives and partitions.

The implementation is not complete, e.g. mandatory Server Profile is not implemented at all. The list will get updated.