A ResourcePool is a logical entity (with associated controls) provided by the host system for the purpose of allocation and assignment of resources. A given ResourcePool may be used to allocate resources of a specific type. Hierarchies of ResourcePools may be created to provide administrative control over allocations. In the cases where resources are subdivided, multiple resource pools may exist (e.g. nodal boundaries in NUMA-like systems). In systems that support over commitment, pools represent the reservable capacity, not an upper bound or limit on the maximum amount that can be allocated. Admission control during power on may detect and prevent systems from powering due to resource exhaustion. For example, over commitment on a ResourcePool with ResourceType=Memory would require that sufficient space be available in some backing-store, that may be managed through a storage ResourcePool.
CIM_ResourcePool - child subclasses in ROOT\CIMV2\storage\iscsitarget
'This property specifies the units of allocation used by the Reservation and Limit properties. For example, when ResourceType=Processor, AllocationUnits may be set to MegaHertz. When ResourceType=Memory, AllocationUnits may be set to MegaBytes The value of this property shall be a legal value of the Programmatic Units qualifier as defined in Appendix C.1 of DSP0004 V2.4 or later.'
'Within the scope of the instantiating Namespace, InstanceID opaquely and uniquely identifies an instance of this class. To ensure uniqueness within the NameSpace, the value of InstanceID should be constructed using the following "preferred" algorithm: : Where and are separated by a colon (:), and where must include a copyrighted, trademarked, or otherwise unique name that is owned by the business entity that is creating or defining the InstanceID or that is a registered ID assigned to the business entity by a recognized global authority. (This requirement is similar to the _ structure of Schema class names.) In addition, to ensure uniqueness, must not contain a colon (:). When using this algorithm, the first colon to appear in InstanceID must appear between and . is chosen by the business entity and should not be reused to identify different underlying (real-world) elements. If the above "preferred" algorithm is not used, the defining entity must ensure that the resulting InstanceID is not reused across any InstanceIDs produced by this or other providers for the NameSpace of this instance. For DMTF-defined instances, the "preferred" algorithm must be used with the set to CIM.'
'An opaque identifier for the pool. This property is used to provide correlation across save and restore of configuration data to underlying persistent storage.'
'If true, "Primordial" indicates that this ResourcePool is a base from which resources are drawn and returned in the activity of resource management. Being primordial means that this ResourcePool shall not be created or deleted by consumers of this model. However, other actions, modeled or not, may affect the characteristics or size of primordial ResourcePools. If false, "Primordial" indicates that the ResourcePool, a concrete Resource Pool, is subject to resource allocation services functions. This distinction is important because higher-level ResourcePools may be assembled using the Component or ElementAllocatedFromPool associations. Although the higher-level abstractions can be created and deleted, the most basic, (i.e. primordial), hardware-based ResourcePools cannot. They are physically realized as part of the System, or are actually managed by some other System and imported as if they were physically realized.'
'This property represents the current reservations (in units of AllocationUnits) spread across all active allocations from this pool. In a hierarchical configuration, this represents the sum of all descendant ResourcePool current reservations.'
'A string describing an implementation specific sub-type for this pool. For example, this may be used to distinguish different models of the same resource type.'
'A ResourcePool is a logical entity (with associated controls) provided by the host system for the purpose of allocation and assignment of resources. A given ResourcePool may be used to allocate resources of a specific type. Hierarchies of ResourcePools may be created to provide administrative control over allocations. In the cases where resources are subdivided, multiple resource pools may exist (e.g. nodal boundaries in NUMA-like systems). In systems that support over commitment, pools represent the reservable capacity, not an upper bound or limit on the maximum amount that can be allocated. Admission control during power on may detect and prevent systems from powering due to resource exhaustion. For example, over commitment on a ResourcePool with ResourceType=Memory would require that sufficient space be available in some backing-store, that may be managed through a storage ResourcePool.'