Will 'openlmi-storage' follow the SNIA SMI-S standard?

Gris Ge fge at redhat.com
Fri Nov 1 06:13:42 UTC 2013


On Thu, Oct 31, 2013 at 09:04:08AM +0100, Jan Safranek wrote:
> 
> There is extensive documentation incl. diagrams at
> 
> (and you can find partitioning + other stuff there too)
> 
Thanks.
> 
> Yes, that's what we do. Apart from InPool argument - what kind of pool
> would you expect here? Build VG on top of other VG?
Assuming you refer to 'InPools' of CreateOrModifyStoragePool.

InPools is the pool you want to allocated space from.
Actually every pool is allocated from Primordial StoragePool, so
normally we just ignore this parameters.
When defined but not Primordial StoragePool, it means new pool will be
allocated from defined Pool. 
It was introduced to SNIA as some array like 'IBM DS 8000' are using
mid-level pool to hold disk, and top-level pool(can create volume) to
hold RAID info. 
For that array, 
    top-level Pool should use 'InPools' parameters;
    mid-level Pool should use 'InExtents' parameters.

AFAIK, LVM does not support that layout.
SMI-S provider use 
StorageConfigurationCapabilities.SupportedStoragePoolFeatures to
indicate what argument CreateOrModifyStoragePool() supported.  

StorageConfigurationCapabilities can also associated to each StoragePool to
indicate specific capabilities. Please check SNIA 1.6rev4, Block Book,
PDF Page 68, Figure 9 - Capabilities Specific to a StoragePool
> 
> Sure, that's excellent idea. However, I'd like to make the local storage
> right first and then expose it.
> 
> On related note, is there any library/service/cmdline tool which can
> configure iSCSI target, so we could expose local devices?
Only a cmdline tool -- iscsiadm
I has drafted (unmaintained after I leave QE work) some perl module.
And I believe current Red Hat iSCSI QE could help you also.
Will email you the detail separately.

Thanks.
-- 
Gris Ge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20131101/507e35d1/attachment.sig>


More information about the openlmi-devel mailing list