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
- SMI-S Block Services Package
- SMI-S Extent Composition Subprofile
- SMI-S File Storage Profile
- SMI-S Filesystem Profile
- SMI-S Filesystem Manipulation Profile
- SMI-S Job Control Subprofile
- SMI-S Block Server Performance Subprofile
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.
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.