Self-service provisioning in Intelligent Infrastructure (II)

On this page:

About the fiscal model

To enable self-service provisioning within the Intelligent Infrastructure (II) environment, CPU, RAM, and disk resources will be associated with resource pools rather than individual virtual machines (VMs). This model will allow II VM administrators to create, modify, expand, clone, and delete VMs at their own discretion.

This resource pool model will require fiscal approvers to approve resource pools rather than individual VMs. Teams can then manage additions, deletions and other changes to their VMs on their own, as long as they do not exceed the approved resource limits.


2023-2024 rates (effective February 1, 2024):

  • Allocated CPU: $45/vCPU/year
  • Allocated RAM: $15/GB/year
  • Allocated fiber channel attached disk storage: $0.33/GB/year
  • Consumed DPS space: $0.21/GB/year


Moving forward, II will treat VMs as belonging to resource pools. A resource pool will represent an allocation of resources that a team can use across as many VMs as needed, enabling VM administrators to create VMs, allocate resources to them, adjust resources as needed to meet performance demands, and delete VMs. The capacity of a resource pool enables self-service within a known maximum expenditure.

You will be charged only for the resources you use. Your costs will fluctuate based on actual usage each month (with an absolute maximum of the approved pool size).

Resource pools

Resource pools allow you to group VMs together. They represent an allocation of resources that can be used for as many VMs as needed. In addition, resource pools are distinct per data center and per account. As such, you will need a separate resource pool for each account to which various VMs in your group will be billed.

For example, if you have two different accounts to cover your VMs, and VMs for each account exist in both IUDC and ICTC, you will need four resource pools (IUDC Account 1, IUDC Account 2, ICTC Account 1, ICTC Account 2) to cover all of your VMs. You will need to plan resources accordingly for each resource pool to contain the VMs associated with it.

Once you reach the allocated limit for a particular resource (such as CPU, RAM, or disk), additional resources will not be available to any of the VMs in that pool until you either reduce or retire resources on another VM in the pool, or request that the pool's allocation for that resource be increased.


A member of a particular organization will request resource pools be created and modified; see more about organizations in the Resource Allocation Center (RAC) system. Requesters will specify their estimate of the maximum resource use for the year in terms of number of CPUs, GB of memory, and TB of storage. Requesters should anticipate potential growth over the course of the year in order to avoid having to expand the capacity of the pool during the year. Expansion will require a new request and fiscal approval. Within the RAC system, fiscal approvers will be provided the maximum cost for that pool assuming all resources are consumed; however, you will only be charged for the resources that are actually consumed. For example, if you approve a pool for 10 CPUs and only actually use two, you will only be charged for two.

Requests will consist of the following:

Label: This is a name that will be easily identifiable by your group. At a minimum, we recommend that it contain the data center on which this pool will reside and the funding source (the account) to which VMs in this pool will be billed.

Data Center: A pool must be tied to a specific data center. This allows you to control where the VM is hosted.

CPUs: Maximum number of CPUs that should be available for various VMs in this pool to use.

Memory: Maximum amount of memory in gigabytes (GB) that should be available for various VMs in this pool to use.

Storage: Maximum amount of storage in terabytes (TB) that should be available for various VMs in this pool to use.

VLAN IDs: Comma-separated list of VLAN IDs that your organization manages that should be available for VMs in this pool to use.

Data Protection Services (DPS): Indicate whether the VMs in this pool are eligible for CommVault AllDisk backup services; see IU's Data Protection Service (DPS) and Determine the type of data protection used for your Intelligent Infrastructure (II) virtual machines.

Cost summary calculations

On the request form and the fiscal approval page, there is a section that presents a cost summary for the request. This "Maximum Annual Cost Summary" represents the maximum annual potential cost that this pool could represent.

CPUs: CPU cost is calculated by taking the number of CPUs requested * the current annual rate per CPU.

Memory: Memory cost is calculated by taking the number of GB of memory requested * the current annual rate per GB.

Storage: Storage cost is calculated by taking the number of GB of storage requested * the current annual rate per GB.

Data protection (DPS): A DPS cost would appear only if AllDisks backups are requested to be available for a particular Resource Pool. The cost is calculated by taking the number of GB of storage requested * the current annual rate per GB for DPS backups. Also note that this total would apply only if all VMs in this resource pool used AllDisks backups. VMs that do not use AllDisks backups would not incur a DPS charge.

See Example, below, for a demonstration of how these calculations would be carried out with actual numbers. Costs will fluctuate based upon actual usage each month, with an absolute maximum of the approved pool size.


The following example uses 2023-24 charge rates.

A request is submitted for a pool consisting of 20 CPUs, 50 GB of memory, and 1 TB (1024 GB) of storage, with DPS enabled.

The resulting Maximum Annual Cost Summary would look like this:

Item Subtotal
CPUs $900.00
Memory $750.00
Storage $337.92
Data protection $215.04
Estimated total $2,202.96
  • CPUs: 20 CPUs * $45/CPU = $900
  • Memory: 50 GB memory * $15/GB = $750
  • Storage: 1 TB (1024 GB) storage * $0.33/GB = $337.92
  • DPS: 1 TB (1024 GB) storage * $0.21/GB = $215.04

The estimate reflects the annual maximum cost if all requested resources are fully utilized within the pool. This estimate also assumes the entire storage capacity is using DPS. This estimate should be treated as an absolute maximum, where costs will fluctuate based on actual usage each month.


All new resource pool requests as well as changes to existing pools must be approved by the appropriate fiscal officer prior to the pool being created or modified. Fiscal officers will be notified by the Kuali Enterprise Workflow system that they have action items to approve. An approval page similar to the RAC resource pool will be displayed, listing all the resource maximums as well as maximum annual cost summary, but will contain Approve and Disapprove buttons at the bottom. The cost summary reflects the maximum cost if all requested resources are fully utilized within the pool. This estimate also assumes the entire storage capacity is using DPS. As such, the estimate should be treated as an absolute maximum where costs will fluctuate below that maximum based on actual usage each month.


Every day, the resources allocated to each VM (as well as any storage used by AllDisks VM backups) in Intelligent Infrastructure are counted and recorded with the Resource Pool the VM is associated with that day. In addition, a charge is calculated based on a 1/365th of the annual costs reflected above. Then, on the first of each month, that data for the previous month is tallied for each Resource Pool and calculated as a total amount to charge for the month. This resulting charge will be billed against the account associated with the Resource Pool. The sum of 12 months worth of resource allocations should never represent a sum greater than the maximum annual cost estimate.

Account changes

In the past, account changes could take place by requiring fiscal officers to instruct the business office to modify the intended billing account. However, resource pools dictate the billing configuration for the VMs associated with them. This means VM admins are able to control how VMs are billed. In order to update billing, either the resource pool needs to be updated to reflect the new account, or the desired VMs need to be moved to a different resource pool with the correct account. Thus, if the billing account for a VM needs to change, fiscal officers should work with VM admins to make this happen.

Periodic notices

Annual re-attestation

In an effort to keep fiscal officers informed about the charges hitting their accounts, II resource pools will undergo an annual re-attestation. This involves the RAC system automatically generating a new workflow acknowledgment action. This process will take place at the beginning of the spring semester, prior to budget construction.

  • FY 24-25: February 5, 2024
  • FY 23-24: February 6, 2023
  • FY 22-23: February 21, 2022

Fiscal officers for accounts associated with II resource pools will receive a Kuali workflow action item for each associated resource pool. For example, if five resource pools use the same account, the fiscal officer will receive five action items. Each action item will take the fiscal officer to an RAC document that displays the projected costs of the given resource pool.

Any resource pools created or modified within 90 days of the re-attestation date will not be included, as the creation/update was recent enough to warrant bypassing this reminder.

These re-attestation acknowledgments will not block new modifications should VM admins need to expand the limits of a resource pool. This process gives both VM admins and fiscal officers the opportunity to verify that all VMs and resources are still necessary with appropriate funding sources.

Expiring accounts

Each resource pool is associated with a funding account. Most accounts have an expiration date associated – whether due to the end of a grant, the end of revenue source (project or event), or merely as a forced review point.

Sixty days prior to the expiration date of a funding account, any resource pools associated with that account will notified about the upcoming expiration. This notification will go to the email address associated with the owning organization. It will note the upcoming date of the expiration of the account, indicate that this will impede billing to process, and will encourage them to contact the fiscal manager of the relevant account to either postpone the expiration date, or to find a new funding source account to use - including instructions on how to update the resource pool to use the new account.

If the admins of the resource pool do not make any changes, it will continue to send reminder notices every seven days until the pool is updated or until the account expires.

Since billing is performed in arrears, deactivating a pool within a month of the expiration date does not eliminate the billing that will take place on the 1st of the next month. So if, for example, an account expires on August 31, deactivating the pool on August 3 will still incur a bill on September 1 (assuming there were any VMs in existence during that period of August 1 - August 31). So if the account is not updated, billing will still be impeded.

Manage VMs

The RAC system is primarily used to manage resource pools. Once you have requested one or more resource pools and they have been approved and created, you can manage VMs with the self-service portal. See the following:


If you have additional questions or concerns, contact the Storage and Virtualization team at

This is document apjh in the Knowledge Base.
Last modified on 2024-02-09 11:58:04.