How far can you go when creating the perfect base image for your VDI deployment? I haven’t stopped searching for the Holy Grail, however I have recently figured out that a very critical step in the base image creation was missing, forgotten or had not been discussed yet or enough.
However, before I give you the cooking recipe let’s dig into the semantics of the problem.
During tests with the Linked Cloning technology on VMware View 4.6 (although the example below applies to any version) I noticed that the Replica disks and Linked Clones were using more storage space than they should, or had been provisioned with.
Observing the size of .vmdk’s I noticed that Replica disk sizes were much bigger than Windows NTFS used space was showing.
I won’t explain how Linked Cloning works in this article, but feel free to read my article VMware View 4.5 Linked Cloning explained for a better understanding. If you haven’t catch-up on my previous articles – the size of a replica disk is equal to the disk space consumed in the Parent SOE.
So, if the above is true why does the Replica size doesn’t match the NTFS used space?
Provisioned VM Size: 31.99GB (33,554,430)
Replica Size: 19.10GB (20,033,540)
NTFS Provisioned: 31.99GB
NTFS Used: 14.4GB
NTFS Available: 17.5GB
(Real life example above)
To find out the reason of this disparity I filled up the Windows NTFS partition with data until nothing else would fit, not even a 1KB file. At this point Windows file system had 0KB free space. When I looked at the Delta it was 17.52GB, and that matches with the NTFS free space from above example. Therefore:
Replica (19.10GB) + Delta (17.52GB) = 36.62GB
Discounting additional files like swap and logs, there was an additional 4.63GB if compared to the total provisioned for the VM that was 31.66GB. In Summary, the replica is 4.63GB bigger than the real data in the Windows NTFS partition.
In normal case, a full clone VM’s .vmdk file is always large than the actual NTFS usage. This is because that once a .vmdk file (in Thin format) grows up, it does not shrink back when NTFS released some space, unless the user shrinked the .vmdk files explicitly.
If a replica was created before such "shrinking" was performed, then the size of the copied disk of the replica will be larger than the actual NTFS used space. When a linked clone is created from such a replica attempt to write data into these NTFS free space, the update will be written into the delta disk. These writes could simply have been executed by Windows swap files or Logs.
This may not seem like a big issue at first, however in certain situations it could use storage space that was not initially provisioned, costing projects additional money that was not originally accounted for. I used my VDI Calculator to simulate a scenario with 2,000 VMs and a maximum of 2 concurrent snapshots per desktop pool (only 4 pools).
Replica Size: 8GB
Total Storage for Replicas: 2.20TB
Replica Size: 8GB + 4GB (overhead):12GB
Total Storage for Replicas: 3.30TB
Just making sure that Parent VMs have been properly shrunk you could be saving few gigabytes or even terabytes depending on the size and design of the VDI solution.
In a scenario with more desktop pools and more LUNs these numbers could be even bigger.
** The calculations above only reflect deployments NOT using Dedicated Replica Datastores. When using Dedicated Replica Datastore the difference was from 70MB to 100MB.
To avoid datastore space to be wasted on unshrinked free space copied by the Replicas disks, always shrink the Parent VM’s virtual disks before taking the snapshot to initiate the linked cloning process.
One of the methods to shrink a .vmdk disk is using vmware-vdiskmanager.exe utility. VMware Virtual Disk Manager is a utility in VMware Workstation that allows you to create, manage and modify virtual disk files from the command line or within scripts.
The easy way is to use VMware Tools installed in the parent VM. Shrinking a virtual disk reclaims unused space in the virtual disk. It means that, if there is empty space in the disk, this process reduces the amount of space the virtual disk occupies on the host drive.
To shrink a virtual disk:
3. Select the virtual disks you want to shrink, then click Prepare to Shrink.
Be aware that you cannot shrink a virtual disk if
- You preallocated disk space when you created the disk. Preallocating disk space is the default option for both typical and custom virtual machine creation paths.
- The virtual machine has any snapshots.
- The virtual machine contains physical disks.
- The virtual disk is not an independent disk in persistent mode.
- The virtual disk is stored on a CD-ROM.