Find when a virtualization cluster hits its utilisation threshold and when to order hardware given procurement lead time.
Compound growth turns capacity planning into a logarithm rather than a division: at 4% per month a cluster grows 60% in a year, so a linear projection badly overstates the runway. Subtracting the procurement lead time converts the answer from a capacity date into a purchase-order date, which is the number that actually needs a decision. Hardware lead times of two to three months are common and growth does not wait for them, so the useful output is not when the cluster fills but the last month in which an order still arrives in time. Substitute your own quoted host cost — hardware and licensing pricing changes constantly.
Cluster Expansion
months to threshold = ln(threshold VMs ÷ current VMs) ÷ ln(1 + monthly growth); order date = that minus lead time in months, where lead weeks ÷ 4.345 converts weeks to months.
months to threshold = ln(threshold VMs ÷ current VMs) ÷ ln(1 + monthly growth); order date = that minus lead time in months, where lead weeks ÷ 4.345 converts weeks to months. Compound growth turns capacity planning into a logarithm rather than a division: at 4% per month a cluster grows 60% in a year, so a linear projection badly overstates the runway. Subtracting the procurement lead time converts the answer from a capacity date into a purchase-order date, which is the number that actually needs a decision.
Hardware lead times of two to three months are common and growth does not wait for them, so the useful output is not when the cluster fills but the last month in which an order still arrives in time. Substitute your own quoted host cost — hardware and licensing pricing changes constantly.
This calculator takes 8 inputs: Hosts in cluster today, VMs each host supports, VMs running today, VM growth per month, Utilisation threshold to act on, Procurement and racking lead time, Fully loaded cost per host, Planning horizon. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
The last 20% is failover capacity and scheduling headroom. A cluster at 100% cannot absorb a host failure, cannot accept a maintenance-mode evacuation and cannot place a large VM even when the totals suggest room.