Device hierarchyΒΆ
The API manages all block devices in machine’s local /dev/ directory, i.e. also remote disks (iSCSI, FcoE, ...), as long as there is appropriate device in local /dev/.
The API exposed by OpenLMI-Storage is object-oriented. Each block device present on the managed system is represented as instance of CIM_StorageExtent class. The instance has properties like DeviceID, Name, BlockSize and NumberOfBlocks, which describe the block device.
CIM_StorageExtent has several subclasses, such as LMI_DiskPartition (=MS DOS partition) or LMI_LVStorageExtent (=Logical Volume), which add properites specific for the particular device type.
Each block device is represented by instance of CIM_StorageExtent or its subclasss.
LMI_StorageExtent represents all devices, which do not have any specific CIM_StorageExtent subclass.
Each volume group is represented by LMI_VGStoragePool.
Instances of LMI_VGStoragePool, CIM_StorageExtent and its subclasses compose an oriented graph of devices on the system. Devices are connected with these associations or their subclasses:
- CIM_BasedOn and is subclasses associates a block device to all devices, on which it directly depends on, for example a partition is associated to a disk, on which it resides, and MD RAID is associated to all underlying devices, which compose the RAID.
- LMI_VGAssociatedComponentExtent associates volume groups with its physical extents.
- LMI_LVAllocatedFromStoragePool associates logical volumes to their volume groups.
All other storage objects, like partition tables, filesystems and mounts are designed in similar way - all these are instances of particular classes.
These storage elements are managed (i.e. created / modified and deleted) by subclasses of CIM_Service such as LMI_FileSystemConfigurationService. These services are not system services in systemd or UNIX SysV sense, it is just API collecting bunch of methods related to a particular topic, e.g. filesystem management in our example.
These services are described in OpenLMI-Storage API chapter.