TruGrid VM Pools: Linked Clones Disk Usage and Storage Planning
Contents
- The short version
- A measured walk-through, step by step
- Step 0 - the master, before anything else
- Step 1 - creating the pool costs 36 MB
- Step 2 - the first clone, minutes after cloning
- Step 2b - the whole clone, reconciled to the byte
- Step 3 - preparation finishes: the baseline freezes
- Step 4 - life: what grows, what does not
- Three things about the numbers vCenter shows you
- Worked estimate: 100 clones of this master
- Adapting this to your own environment
- The VMware disk types involved, and why
- Good practices
The short version
- All clones share ONE read-only copy of the master's disk. They do not copy it.
- Each clone has exactly ONE attached virtual disk, the same size as the master's, stored as a stack of layer files. There is no separate identity disk and no separate write-cache disk.
- Everything needed to boot a pool VM lives inside VMware itself: each clone is a complete, native vSphere virtual machine, so there is no streaming server, no external delivery controller in the boot path, and nothing outside your hypervisor that can fail and leave desktops unable to start.
- A disk layer records everything ever WRITTEN, in multi-megabyte allocation units. Deleting files inside Windows never returns datastore space - not on a clone, and not on the master either.
- When TruGrid finishes preparing a clone, TruGrid snapshots it as
trugrid-baseline. Resetting is an instant revert to that snapshot: the running layer is discarded and its space comes back. Rebooting discards nothing. - Your storage estimate = the master's disk (once) + per clone: a birth cost of about 32 GB (measured, explained below) + growth between resets + about one RAM's worth of swap while powered on.
1. A measured walk-through, step by step
Everything below is one real sequence, captured screen by screen: a master was cleaned up and updated, shut down, a pool was created from it, and the first clone was examined minutes later. Sizes are exactly as the vSphere Client shows them; on this vSAN they include the RAID-1 mirror, so displayed is roughly twice the logical bytes.
Step 0 - the master, before anything else
GOLD-RDS-01: one 50 GB disk, 8 GB of memory, freshly serviced (large files deleted, .NET and Windows updates applied, rebooted twice, old snapshots removed), then POWERED OFF. Two views of the same machine:
View | What it shows |
|---|---|
Inside Windows (drive C: properties) | 35.8 GB used of 49.3 GB capacity |
On the datastore (the vCenter Files view) | one disk file of 100.03 GB - the full 50 GB, mirrored |
e master's folder in the vSphere Client Files view, before the pool exists (for illustration purposes only; sizes are the real measurements).*
What each file is:
Name | Size (as vCenter displays it) | What it is |
|---|---|---|
| 100.03 GB | The master's one disk: 50 GB, every block historically written, times two for the vSAN mirror. |
| ~3 MB | Ordinary VM housekeeping files. |
Step 1 - creating the pool costs 36 MB
A pool named TEST-RDS-01 was created with GOLD-RDS-01 as the source. Linked clones must attach to a SNAPSHOT, so TruGrid took one automatically (named trugrid-pool-base- plus the date and time). Because the master is powered off and nothing is writing, the snapshot is a bookmark, not a copy. The master's folder afterwards:
e same folder after the pool was created. The two highlighted rows are new - together they cost 36 MB.*
What each file is:
Name | Size (as vCenter displays it) | What it is |
|---|---|---|
| 100.03 GB | Unchanged. |
| 36 MB | NEW - the pool snapshot's layer. Stays this small for as long as the master stays powered off. |
| 95 KB | NEW - the snapshot's bookkeeping file. |
| ~3 MB | Unchanged. |
Step 2 - the first clone, minutes after cloning
TruGrid cloned POOL-VM-001 from that snapshot (a vSphere linked clone) and started preparing it: guest customization, the domain join, first boot. Captured while that preparation was still running:
e clone's folder, minutes after cloning. Note there is no full-size disk anywhere in it - the 50 GB of Windows lives once, in the master's folder.*
What each file is:
Name | Size (as vCenter displays it) | What it is |
|---|---|---|
| 31.8 GB | The clone's ONE disk layer so far: everything preparation has written, in allocation units. See the reconciliation below - only 1.3 GB of it is new data. |
| 82 MB | VMware overhead swap, present while powered on. |
| ~0.5 MB | Ordinary VM housekeeping files. |
Windows inside this brand-new clone reports 37.1 GB used - the master's 35.8 GB plus just 1.3 GB of genuinely new data (a 1.25 GB page file, logs, first-boot housekeeping). Yet the clone's layer already holds about 16 GB of allocation (31.8 displayed, halved for the mirror). That gap is ALLOCATION GRANULARITY: a copy-on-write layer allocates in multi-megabyte units, and first boot makes thousands of small scattered writes - registry, NTFS metadata, logs, caches - each claiming a whole unit. The datastore charges the allocated number, so ~32 GB displayed is this image's real per-clone birth cost. It was measured twice, on two different pools from this master: 31.8 GB and 31.1 GB.
Step 2b - the whole clone, reconciled to the byte
The clone's vCenter Summary page says STORAGE USAGE 139.93 GB. That number is the sum of everything the clone touches, including what it SHARES:
Component | Displayed |
|---|---|
The master's disk (shared with every clone in the pool) | 100.03 GB |
The pool snapshot on the master (shared) | 0.04 GB |
The clone's own layer | 31.8 GB |
Memory swap while powered on (about the VM's RAM size) | ~8.1 GB |
Total - matches the Summary page | 139.93 GB |
Step 3 - preparation finishes: the baseline freezes
When preparation completes, TruGrid shuts the clone down cleanly and snapshots it as trugrid-baseline (description: clean, powered-off, post-join state), then powers it back on. That snapshot FREEZES the ~32 GB birth layer - it will never grow or shrink again - and opens a fresh, empty RUNNING layer on top. From this moment the clone's one disk is a three-part stack:
e clone's Manage Snapshots view after preparation: exactly one snapshot, trugrid-baseline, holding the frozen birth layer. 'You are here' is the running layer.*
Layer | Scope | Content |
|---|---|---|
Master layers (bottom) | Shared by all clones, read-only | The 100 GB chain above. Stored once. Never grows while the master stays powered off. |
Baseline layer (middle) | One per clone, frozen at ~32 GB | The birth cost: preparation's writes, frozen by |
Running layer (top) | One per clone, starts empty, grows | Every write since the baseline. The only layer that changes day to day. |
Identity (computer name, domain account) lives in Active Directory and the Windows registry like on any ordinary machine - a few kilobytes, not a disk. Administrators coming from products that attach a small identity disk and a write-cache disk per VM should expect neither here: one disk per clone, nothing else to manage.
Step 4 - life: what grows, what does not
Event | Effect on the layers |
|---|---|
Reboot (restart inside Windows) | Nothing is discarded. The running layer keeps everything and keeps growing. A reboot is invisible to the disk layers. |
Deleting files inside the clone | Frees space for Windows only. The running layer keeps every block ever written - temp files, uninstalled software, all of it stays allocated on the datastore. |
Reset (TruGrid reverts to | The running layer's content is DISCARDED and its datastore space comes back. The clone boots exactly as it was when preparation finished: clean, domain-joined, empty running layer. |
Power off | For a non-persistent pool TruGrid recycles a powered-off clone automatically: reset, then power back on. Recycling on user sign-out and on a daily schedule are optional extras. The recycle cadence is your storage-growth control. |
Image update (recompose) | TruGrid deletes the clone and re-clones from the new image, keeping the computer identity. No layer stacking - and all accumulated per-clone space returns in the same move. |
How fast does the running layer grow? It tracks everything ever written, so it depends entirely on workload. A measured heavy case from an earlier pool on this same master: LAB-VM-017 ran disk benchmarks for twelve days with no resets and its running layer reached 56.6 GB displayed - while Windows inside showed only 35.8 GB used, because the benchmarks' deleted test files still occupied the layer. Treat that as what a pathological workload can do; measure one normal user week on your own pool for a realistic number.
2. Three things about the numbers vCenter shows you
- On vSAN, the Files view shows RAW consumption including data protection. Under the default policy (RAID-1, failures-to-tolerate 1) every byte is stored twice - a fully written 50 GB disk displays as 100 GB. A RAID-5 policy multiplies by about 1.33 instead. This guide uses displayed numbers throughout, directly comparable to your own Files view.
- Layer sizes are ALLOCATED space, not bytes the guest wrote. Copy-on-write layers allocate in multi-megabyte units, so scattered small writes consume more allocation than data (the measured extreme: 1.3 GB of new data occupying ~16 GB of allocation). Allocated space is what the datastore loses, so plan with it as-is.
- A VM's Summary 'Storage Usage' includes everything it shares. Reconcile it as in step 2b if you want to understand it, but never sum it across clones.
3. Worked estimate: 100 clones of this master
The formula, in vCenter-displayed numbers:
Total = Master disk chain (once) + N x ( Baseline ~32 GB + Running-layer growth + ~8 GB swap while powered on )
Scenario | Arithmetic (GB, displayed) | Total |
|---|---|---|
Day one, all 100 powered off | 100 + 100 x 32 | about 3.3 TB |
Day one, all 100 powered on | 100 x 8 swap | about 4.1 TB |
Steady state, tight recycling (sign-out or daily; running layers average ~8 GB) | 100 + 100 x (32 + 8 ) + 800 | about 4.9 TB |
Steady state, relaxed recycling (running layers average ~15 GB) | 100 + 100 x (32 + 15) + 800 | about 5.6 TB |
Two weeks, NO recycling, benchmark-heavy workload (the measured LAB-VM-017 case) | 100 + 100 x (32 + 57) + 800 | about 9.8 TB |
Absolute ceiling (every running layer completely full at 100 GB displayed) | 100 + 100 x (32 + 100) + 800 | about 14 TB |
The honest planning message: one hundred FULL copies of this master would cost about 7 TB before anybody logged on (100 x 72 GB of written data, mirrored), so the sharing is real - but linked clones are not free. The birth cost is fixed by your image (~32 GB here; measure one clone of YOUR master and substitute), and after that the recycle cadence decides where between roughly 5 TB and 14 TB the pool settles. Plan for your cadence, measure for a month, adjust.
Adapting this to your own environment
- Birth cost: provision ONE clone of your master and read its layer size in the Files view before sizing the pool. It is a property of your image, not a formula.
- Growth: give a pilot pool one normal user week without recycling and read a running layer's size. Do not size from benchmark VMs.
- Storage policy: these numbers assume RAID-1 mirroring (x2). For RAID-5, multiply logical estimates by ~1.33; on a non-vSAN datastore the Files view shows logical sizes directly.
4. The VMware disk types involved, and why
Type | Why |
|---|---|
Master and clone hard disks: DEPENDENT mode | The normal vSphere disk mode that participates in snapshots. TruGrid requires it because the design runs on snapshots: the pool snapshot on the master and the |
Clone layers: child / delta disks | The linked-clone child and the snapshot layers are the same vSphere mechanism: copy-on-write layers (vsanSparse objects on vSAN, SEsparse files on VMFS). vSphere chooses this; you do not. |
Provisioning: set by storage policy | On vSAN, thin versus thick is decided by the VM Storage Policy. Layers only ever consume what has been written (times the protection factor). |
Persistent pools (for contrast) | A PERSISTENT pool clones the master in full: every VM gets its own complete copy, nothing is shared, no baseline, no reset. Budget the master's written data per VM. This guide's math applies to non-persistent pools only. |
Good practices
- Service the master BEFORE creating a pool: apply updates, delete leftovers, remove old snapshots you no longer need, reboot, shut down. Everything in the master is stored once and shared; everything a clone does at first boot is paid per clone, times the pool size.
- Once a pool exists, leave every snapshot named
trugrid-*alone, on the master and on the clones. TruGrid manages them; clones depend on the master's pool snapshot, and reset depends on each clone's baseline. - Keep the master powered off. TruGrid only clones from a powered-off source, and a powered-off master's layers never grow.
- Pick a recycling cadence deliberately (power-off recycling is always on; sign-out and scheduled recycling are optional). It is the storage lever you own after the image is set.
- If your image still uses Windows' default RAM-sized page file, set a fixed smaller one in the master; the example image here already runs a fixed 1.25 GB file.
- Update images through TruGrid's image update (recompose): it refreshes the image AND returns all accumulated per-clone space in one move.
- Watch the datastore, not the per-VM Summary numbers, and re-measure after the first month: your users' real write rate beats any estimate, including this one.
Updated on: 22/08/2026
Thank you!