Discrepancy between storage usage reported in vCenter and space used inside the Guest OS
search cancel

Discrepancy between storage usage reported in vCenter and space used inside the Guest OS

book

Article ID: 451594

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

In vCenter Server, the reported storage usage for a virtual machine with thin-provisioned virtual disks (VMDKs) appears significantly higher than the actual space utilized within the guest operating system (e.g., Windows file systems).

Even after deleting files inside the guest OS, the total storage consumption shown in vCenter does not decrease.

Environment

  • VMware vSphere ESXi: All versions

  • VMware vCenter Server: All versions

  • Datastore Type: VMFS or NFS (Applies to non-vSAN environments only)

  • Virtual Disk Format: Thin Provisioned

  • Guest Operating System: Windows / Linux

Cause

This storage usage discrepancy is driven by three main factors: virtual machine overhead files, the presence of snapshots, and the unidirectional growth characteristic of thin-provisioned disks.

1. Virtual achine overhead files

vCenter calculates total VM storage usage based on all files associated with the VM on the datastore, not just the VMDK data. The largest contributor is typically the swap file (.vswp), which is created when the VM powers on. The size of this file equals the configured VM memory minus any configured memory reservation. Auxiliary files, such as .nvram (BIOS/UEFI settings) and vmware.log files, also contribute marginally to this overhead.

2. Virtual machine snapshots

When a snapshot is created, the base VMDK becomes read-only, and all new writes are directed to a new delta disk (redo log) on the datastore. vCenter includes the size of the base VMDK plus all associated delta disks when calculating the total storage used by the VM. Over time, these delta disks can grow significantly, inflating the storage footprint reported by vCenter compared to what the guest OS reports.

3. Thin disk space allocation behavior

Thin-provisioned disks allocate blocks dynamically on the underlying datastore when data is written inside the guest OS. When files are deleted inside the guest OS (or cleared from the Recycle Bin), the guest file system marks those sectors as free space. However, ESXi and the underlying datastore do not automatically shrink the VMDK or release these blocks back to the storage array without explicit reclamation operations.

Resolution

To verify and address the storage discrepancy, follow these steps sequentially:

1. Verify memory reservation and swap overhead

Check the VM's memory settings in vCenter. If the memory reservation is set to 0, the allocated .vswp file on the datastore will match the full amount of assigned memory. Setting a memory reservation will reduce the size of the .vswp file accordingly.

2. Consolidate or delete snapshots

Open the snapshot manager in vCenter and verify if there are active snapshots. Delete or consolidate snapshots that are no longer needed to merge the delta disk data back into the base disk and free up datastore space.

3. Verify datastore space reclamation settings

In the vSphere Client, navigate to the Datastore where the VM resides. Under the Configure tab, select General and verify that Space Reclamation is set to Enabled. If it is disabled, the datastore will not process UNMAP requests from the guest OS.

4. Check VAAI space reclamation (UNMAP) Support

In vCenter, identify the backing storage device (NAA ID) for the VMFS datastore where the VM resides. Establish an SSH session to the ESXi host and run the command

esxcli storage core device vaai status get -d <naa_id>

to check the VAAI status. Review the "Delete Status" line in the output. If it says supported, the underlying storage device supports hardware-accelerated space reclamation.

5. Reclaim Unused Space

If the "Delete Status" shows as supported, execute guest OS-level or datastore-level UNMAP operations (e.g., running "Optimize-Volume" in Windows or using "esxcli storage vmfs unmap" on the ESXi host) to reclaim the freed storage space. 

For detailed instructions and commands, please refer to KB Storage array space not reclaimed after Guest OS cleanup on VMFS (323112).

Additional Information

  • Swap File Calculation:

    Configured VM Memory - Reserved VM Memory = .vswp File Size.

  • vSAN Considerations

    This article applies exclusively to traditional VMFS and NFS datastores. In vSAN environments, storage consumption is additionally governed by Storage Policy Based Management (SPBM), where Failures to Tolerate (FTT) settings act as multipliers for the actual physical capacity consumed.

Powered by Wolken Software