Adding VM Disk Images Up Into a Datastore Figure
A capacity review is mostly columns of gibibytes. Every virtual disk in vCenter, every volume in a Proxmox pool, every line of the guest inventory is quoted in GiB — but the datastore you are fitting them onto is quoted in tebibytes, and so is the purchase request you will eventually raise. Rolling a long list of GiB images into one TiB number is how you learn whether the next batch of virtual machines has anywhere to live.
TiB = GiB ÷ 1024. A rack of guests provisioned for 3,072 GiB works out to 3072 ÷ 1024 = 3 TiB of datastore. Multiply by 1024 to turn a TiB target back into a GiB budget.Provisioned Is Not Consumed
Snapshots Grow Quietly
Overcommit Has a Ceiling
Converting a Provisioned Total Before You Commit
Total the Disk Images in GiB
Add up the virtual disks you plan to place — including second and third disks on database guests, which are easy to miss — and type that total into the left field. Comma or dot both work as the separator.
Compare It Against the Datastore
Hold the tebibyte figure beside the capacity your storage team quoted. If the provisioned total already exceeds it, you are relying on thin provisioning — a decision worth making deliberately.
Copy It Into the Change Record
The copy button on each field yields the bare number with no unit, ready for a change ticket, a capacity spreadsheet or the sizing table in a design document.
Work Backwards From a Target
Press swap to reverse the pair and enter the TiB capacity you have been allocated. The GiB result is the disk budget you hand back to application owners as a per-VM allowance.
Neither field is read-only, so the reverse direction needs no extra step: type a TiB number on the right and the GiB equivalent appears immediately. Both sides carry a searchable unit list, handy when an array console reports the same LUN in a unit your hypervisor never uses.
A Worked Datastore Build From VM Disk Images
Below is a realistic mixed workload laid out the way a capacity plan usually looks: groups of guests, the provisioned disk each carries, and what the group contributes once expressed in tebibytes.
| VM group | Guests | Provisioned each | Group total (GiB) | Group total (TiB) |
|---|---|---|---|---|
| Web front ends | 12 | 40 GiB | 480 GiB | 0.46875 TiB |
| Application servers | 8 | 120 GiB | 960 GiB | 0.9375 TiB |
| Build agents | 6 | 250 GiB | 1,500 GiB | 1.46484375 TiB |
| Database guests | 4 | 500 GiB | 2,000 GiB | 1.953125 TiB |
| File servers | 3 | 1,024 GiB | 3,072 GiB | 3 TiB |
| Provisioned total | 33 | — | 8,012 GiB | 7.82421875 TiB |
That 7.82 TiB is the thick-provisioned worst case. On an 8 TiB datastore it leaves almost nothing spare — no room for snapshot deltas or swap files, and an alarm set at 80% would already be firing at 6,553.6 GiB consumed. Thin provisioning buys back most of the gap, but only while the guests stay well below their declared sizes.
Keeps the Fractions Honest
Results carry up to eight decimals, so 1,500 GiB shows as 1.46484375 TiB rather than a rounded 1.5 that hides 36 GiB of real disk.
Fits a Capacity Review
Convert each VM group in turn and copy the bare numbers into the sizing table you are filling in, with no unit suffix to strip out of every cell.
Budget Down as Well as Up
Swap the direction and a TiB allocation becomes a GiB pool you can divide across requesting teams — the shape most disk requests arrive in.
No Infrastructure Detail Sent Anywhere
Datastore sizes and guest counts describe your estate. Everything is computed in the browser after page load, so nothing about the environment is transmitted.
Datastore Capacity Questions
Why doesn't a 500 GiB virtual disk come out as exactly 0.5 TiB?
Because the step between binary prefixes is 1,024, not 1,000. Dividing 500 by 1,024 gives 0.48828125 TiB. Only powers of two land on tidy numbers: 512 GiB is exactly 0.5 TiB and 2,048 GiB is exactly 2 TiB. Disk sizes chosen for human convenience — 250, 500, 750 — never will.
My guests are provisioned for more than the datastore holds. Is that a problem?
Only if they claim what they were promised. Oversubscription is deliberate and works because most virtual disks sit half empty for their whole life. What matters is the ratio and how closely you watch actual consumption: a store at 1.5:1 with steady growth is manageable, while one at 3:1 with an unmonitored database on it is a queue of stalled VMs waiting to happen.
Do snapshots need to be included in the GiB total I convert?
They do, and they are the usual reason a carefully planned datastore fills up anyway. A snapshot holds the blocks changed since it was taken, so its size tracks the guest's write rate rather than its disk size. One taken before a patch costs little; one forgotten for a month on a write-heavy guest can add as much as the original disk. Budget a working allowance on top of the base images.
Should I size on provisioned GiB or on consumed GiB?
Convert both; they answer different questions. Provisioned is the worst case if every thin disk inflates to its declared size, consumed is where you are today. Purchasing usually sits between the two — consumed plus a growth curve, with the provisioned figure as the number that must never be able to strand the store without warning.
What free-space threshold should trigger the datastore alarm?
A warning around 75–80% consumed with a critical level near 90% is a common pairing, and the gap has to be wide enough to migrate a guest off before the store fills. Convert the threshold once so you know what it means in real GiB: 10% of an 8 TiB store is 819.2 GiB, which is plenty, while 10% of a 1 TiB store is 102.4 GiB, which one runaway snapshot can consume overnight.
No comments yet. Be the first to comment!