Main Nav

This question pops up each year as the next budget is being created, and I am hoping others have implemented a solution they would like to share.  Historically when servers were physical, if a department wanted/needed a server to host a specific application, a process similar to this would occur. 


1.  The requesting department would have to show they had budgeted for it and had the funding

2.  A quote would be obtained by I.T.

3.  A purchase order request would be generated by I.T., using the requesting department’s organization/account number

4.  The requesting department head would sign off and forward the P.O. request to purchasing.


Now of course, because the vast majority of servers are virtual, I.T. buys blade chassis, blade servers, storage, VMware licenses, etc., and when a department needs/wants a server (virtual piece of the whole blade/storage/etc), there is no finite way that we currently employ to easily estimate cost for a department’s budgeting, nor can we use the historic purchase order method as there is nothing to physically purchase.  This of course leads to the impression that this infrastructure is free, and where once a department would request one server, they will now request three, with no thought to budget or support.


So my questions are, how are you currently handling your virtual server budgeting/charging, and have any of you implemented a form of chargeback utilizing specific software to compute cost?


Any suggested solutions would be appreciated.





Paul V. Fontaine

Providence College | Accinno Hall

1 Cunningham Square, Providence, RI 02918

401-865-1575 |


********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at


We make a “guestimate” of the number of virtual servers that the hardware will support, divide the acquisition cost by n, and then provide that number as the “cost” of a virtual server.  It seems to work well.  People don’t see it as a free good and the cost is not so large as to be prohibitive.




Charles R. Williams
Chief Information Officer
Benedictine University
5700 College Road
Lisle, IL  60532




At Penn College we don’t make departments pay for their servers. Central budgeting is in ITS. We ask other offices to ask for new things are budget time but if it is approved the money is in the ITS budget and we order, install, configure and deploy. ITS also manages life cycle replacement budgeting


            We’ve done essentially the same thing as Randy’s team. Our current virtual server cost is $4,800 upfront and $800 per year thereafter. Of course, that includes upgrades, replacements, etc. We record the costs, account numbers, etc. and pass the data to Accounting who processes the JV’s against the departmental accounts.


Good luck!




Michael R. Belote

Chief Technology Officer

Mercer University

O: 478-301-2850

M: 478-719-2955


We have used a spreadsheet originally created by Ron Oglesby (search for VMOglator) and which we've altered to better fit our situation. The sheet takes data about server costs including incremental costs for CPUs, memory, disk and so forth, as well as estimating how many VM's per server there are. 

When costing out a VM, you enter how many CPUs, how much disk and memory, and a few options for resource allocation and prioritization and it computes what the cost of a VM is. We typically charge based on a 5 year amortization, and set up a payment plan that best fits the department (one time, monthly, yearly).

Beside the fact that there is some estimating involved, there are a few other gaps with this method. There's nothing here that considers the people time involved in VM administration, storage administration or data center costs. Probably the largest gap is that the price is based on resource reservation, but not on actual resource usage. We could have 2 customers have exactly the same size VMs configured (and charged out) where one has infrequent and spiky load where the other one is operating near capacity all the time. We can support a lot more of the first profile per server, so we really should be charging less for that profile.

I'm sure you know that VMWare as well several 3rd party providers have software packages that assist with chargeback models. 

Feel free to contact me directly if you'd like further information.

John Grover
Director | Enterprise Computing and Application Services
University of Maine System | (207) 561-3510 (desk) | (207) 949-4208 (cell)

This is indeed an interesting conversation.  We don't typically charge back to units for virtual servers.  Our culture has seen any kind of charge back as an obstacle, and charge-backs then encourage people to go around us.  We find that when they go around us, they don't carry typical university strategies and values with them, particularly around identity management and security.  We've relied on central funding for the virtual architecture and shared storage environments.  That is getting more difficult.  We recognized that  in the past, if we had to ask for extra funding, the discreet nature of specific servers was easier to describe in a business case.  In shared services environments, the nature of blending makes a specific business case more difficult to develop.  We had an easier time rationing server purchases over time, rather than replacing this huge infrastructure all at once.  We certainly prefer incremental purchases for budget management.  If your organization is making business cases and analyzing return on investment, are there any hints you would share?


Hi Theresa,

Here at U of Maine System, we do make business cases and project ROI though we could do more to analyze actual ROI. Since you don't cost out virtual servers, I'm curious how you write a business case for a service that relies on virtual servers. It wouldn't seem right to put them in at $0 since they do cost something. 

I described in my earlier reply to this thread how we estimate the cost of a slice (a virtual machine) of a virtual server which I find to be analogous to estimating the cost of a slice (LUN or volume) of our SAN. In both cases I often supply the total cost for a fixed length project and then also have to estimate an ongoing cost (usually) monthly for ongoing operations. This close estimate is necessary to get at the real ROI that we project.

I firmly believe in the economics of  incentive. As you note, the "full boat" cost of enterprise supported systems becomes an incentive for people to go with a solution that is cheaper for them but may ultimately be more expensive for the institution. Conversely, I've found that when our people don't share the cost, there is no self-regulation - they want more and more because it's free. The sweet spot is where the consumer is sharing the cost - though not necessarily shouldering it all - and at a rate that keeps them from looking elsewhere. That seems like the right compromise in that the consumer gets service at a reasonable price while the institution is paying a little to keep the benefits of centralized management.

John Grover
Director | Enterprise Computing and Application Services
University of Maine System | (207) 561-3510 (desk) | (207) 949-4208 (cell)