Free VMware datastore space does not make a full Windows volume larger. Measure the volume, partition, virtual disk and backing storage separately, then identify the writer consuming the space. Expand only after the correct layer, supported partition layout and operational headroom are established.
This article uses a Windows Server 2022 guest with a basic NTFS or ReFS data volume as its reference. It is source-researched and untested. No virtual disk, partition or filesystem was changed. Dynamic/spanned layouts, clustered disks and specialised storage require their own supported design.
Begin with the failing path
Record the application operation and exact volume or mount point it writes to. An application may store its main data on one drive while temporary files, exports or logs fill another. A full system drive can interrupt work even when the database drive has capacity.
Capture the error, time and current filesystem free space. Confirm whether the application reports a filesystem-full condition, a quota, a database-file maximum or another allocation restriction. Similar user-facing messages can arise from different controls.
Do not start with a recursive deletion of temporary folders. Identify the owner and purpose of large files before treating them as disposable. Application logs may be incident evidence, database logs may be active recovery data, and installer caches may have servicing dependencies.
If the symptom is an SQL transaction log that cannot grow, use the companion log-growth article to determine whether reuse is blocked. Adding guest space can provide relief while leaving the underlying SQL fault unresolved.
Build a capacity map
Use a private worksheet connecting application path, Windows volume, Windows disk, partition layout, virtual disk and backing storage. Record identifiers and configuration evidence rather than relying only on labels such as “Disk 1” or “Hard disk 2”.
For each layer, record its total capacity, used or allocated capacity as applicable, available capacity and time of observation. These measurements use different meanings. A provisioned virtual-disk capacity is not the same field as physical storage consumed.
Keep units explicit. A dashboard and a guest may use different display conventions. Reconcile bytes or documented units before concluding that a discrepancy is a fault. Do not subtract unrelated allocated and provisioned totals and call the result immediately usable space.
Include snapshots or other storage relationships in the inventory without changing them. The purpose is to explain the active backing path and capacity demand, not to start a snapshot cleanup operation.
If the platform operator cannot conclusively match the Windows disk to the intended virtual disk, stop before modification. A larger capacity value on the wrong device does not solve the incident and can create an unexpected configuration change elsewhere.
Inspect Windows without changing it
Open Disk Management through the approved administrative session. Identify the affected volume and inspect its filesystem, disk number, partition arrangement and any unallocated space. Microsoft’s volume-extension guidance explains this view and the conditions its supported workflow requires.
For the basic-volume path in this article, unallocated space must be on the same disk and immediately after the volume to be extended. Free space inside another volume is not equivalent to unallocated space after this one.
If the virtual disk was already enlarged, inspect whether Windows can see the intended new disk capacity through the supported discovery process. Then compare the disk size with the partition size. Do not assume that an increase visible in VM settings has already reached the filesystem.
If another partition lies between the volume and the unallocated space, record it. It may have a recovery, system or application purpose. Microsoft’s article describes several possible approaches, but deleting or moving that intervening partition is a separate disruptive storage operation. This guide supplies no such procedure.
If the filesystem or disk layout does not match the reference path, obtain its supported expansion method. Do not format a populated volume merely to make the extension option available.
Measure the guest and identify bounded consumers
Untested Windows Server 2022 Storage-module checks, from an authorised administrative PowerShell session. Replace D with the affected drive; these inspect objects rather than resize them R1, R2, R3, R4:
Get-Volume -DriveLetter D
Get-Partition -DriveLetter D
Get-Partition -DriveLetter D | Get-Disk
Get-PartitionSupportedSize -DriveLetter D
Record volume Size/SizeRemaining, partition size and disk number, the corresponding disk's capacity, and SizeMax. If SizeMax equals the current partition size, this check reports no growth headroom for that partition; free datastore bytes do not change that result. An error is not a zero and needs investigation.
When Extend Volume is greyed out, check administrator access, NTFS/ReFS, unallocated space on the same disk immediately after the volume, and GPT requirements when exceeding 2 TB S1. Do not delete an intervening partition to create a convenient layout.
For one known application folder, this untested Windows PowerShell 5.1 example lists its largest visible files without recursion R5:
Get-ChildItem -LiteralPath 'D:\AppLogs' -File -Force -ErrorAction Stop |
Sort-Object Length -Descending | Select-Object -First 20 FullName,Length,LastWriteTime
Substitute an approved, bounded folder and use existing read permission. A large directory can still take time. The result excludes subfolders, inaccessible locations and filesystem overhead; it is not a whole-volume accounting report or deletion list. Compare observations from ordinary scheduled reporting to identify the writer and growth rate.
Shadow-copy storage may sit outside visible application files. An authorised elevated Command Prompt can inspect associations physically stored on D: with vssadmin list shadowstorage /on=D: R6. Record used, allocated and maximum values; do not delete shadows. Component-store and page-file accounting are outside this guide: assign unexplained system-managed consumption to the Windows owner before choosing cleanup or expansion.
Inspect backing headroom separately
Have the platform owner record the exact virtual disk’s configured capacity, backing location and allocation mode. Confirm the storage view is current and refers to the same object as the Windows map.
Assess headroom for the intended workload, other consumers and ongoing storage work. Capacity visible as free at one moment can be consumed by concurrent workloads or maintenance. A guest expansion should fit the platform’s accepted capacity and protection policy.
Guest deletion and physical storage reclamation are also different operations. Their relationship depends on the guest, virtual-disk format, snapshots, datastore and supported reclamation path. Do not promise that removing Windows files will immediately return the same number of bytes to the datastore.
Broadcom’s thin-disk article illustrates a specific historical SEsparse consolidation and unmap interaction. Its listed environments include older ESXi releases and it describes an improvement in vSphere 7.0 Update 1. That case is evidence that allocation behaviour is version-dependent, not a current repair recipe for every vSphere release.
This article does not prescribe TRIM, UNMAP, defragmentation, snapshot consolidation or datastore-file removal. Those actions need their own exact support and impact assessment. The existing snapshot articles cover the diagnostic boundaries for disk-chain faults.
Select the correct change
If the Windows volume is full but suitable unallocated space already follows it, a reviewed guest-volume extension may be the relevant change. The platform owner still needs to confirm that the workload’s future allocation fits available backing capacity.
If the Windows disk has no suitable unallocated space, a virtual-disk expansion may need to precede guest partition/filesystem work. The platform specialist must check the exact disk type, VM state, snapshots, storage design and supported operation for the installed build. This article intentionally does not provide a universal hot-expansion recipe.
If an intervening partition blocks the simple path, compare a separately designed data migration or new volume with a specialist partition change. The application must support the destination path and its permissions. Do not move live application files by dragging them to another drive.
If backing capacity is the limiting resource, increasing guest provisioned capacity does not create physical storage. Resolve the platform constraint before relying on further guest writes.
If an application quota or database-file maximum is the real restriction, direct the change to that owner. Expanding the disk below an intentional limit will not necessarily change what the application is allowed to allocate.
Review risk and reversibility before expansion
Record the intended disk and volume identifiers, current sizes, proposed sizes and expected result. Establish a recoverable backup and an application-specific acceptance test. An expansion that appears routine still changes persistent storage configuration.
Do not assume expansion can be reversed by typing the old number into VM settings. Once new space has been used, shrinking or relocating the data can require a different supported procedure and additional capacity. A backup is a recovery option, not proof of a quick reversal.
For the simple Windows path, Microsoft documents the Extend Volume wizard and the amount of unallocated space selected S1. Have the qualified operator review that exact selection before applying it. The maximum available choice is not automatically the organisation’s desired allocation.
This guide provides inspection and decision steps rather than executable resize commands. The actual procedure must match the approved target and installed tools, and should be rehearsed on a disposable equivalent before production work.
Verify from storage to application
After the approved change, inspect the disk and volume again. Confirm that the intended filesystem shows the expected capacity and that unrelated volumes retain their previous layout. Record the new backing-storage headroom separately.
Run the application operation that originally failed using an approved synthetic input. Confirm it writes to the intended path and can read back the correct result. A larger number in Disk Management is not the same as application acceptance.
Check relevant application and system logs for new errors. If the volume immediately fills again, identify the writer and growth pattern rather than repeatedly expanding without diagnosis. Capacity planning should address the workload’s rate and retention behaviour.
Verify that backup protection still includes the intended data and that its capacity assumptions have been reviewed. Additional protected data can change backup duration and storage requirements even when the application appears healthy.
Keep the mapping useful after the incident
Retain the capacity map and approved change in the operating record. Configure ordinary monitoring for the actual application volumes and relevant backing headroom. Give alerts an owner and a growth context so that a known busy period is not confused with an unexplained leak.
Do not use a single “disk free” percentage to represent every layer. Report the boundary that needs attention and the consequence if it fills. That gives the SQL, Windows and platform teams a shared problem statement.
Limitations
The reference guest is Windows Server 2022 with basic NTFS/ReFS volumes; Windows Server 2025 behaviour has not been validated here. VMware mapping and datastore capacity measurement are left to the platform team using its release-specific tools. Folder sizes cannot account for all physical storage.
Acceptance checklist
- Affected path mapped to the correct volume, partition and virtual disk.
- Volume free bytes, partition SizeMax and backing reserve measured.
- Visible growth owner and unexplained system consumption recorded.
- Approved change verified through an application write on the authorised test path.
Learning notes
- Datastore free space and guest filesystem free space answer different questions.
- The simple Windows extension path depends on partition placement, not just total free bytes.
- Expanding capacity does not remove the need to identify unexpected growth.
Related reading: SQL Transaction Log Keeps Growing: Find the Real Cause; Size Backup Retention Using Measured Storage Growth.
Sources and review status
Sources accessed 30 October 2026. Exact displayed dates, scope and claim mapping are in the accompanying evidence file. Revised after independent review; independent recheck pending. All examples remain untested and no lab validation is claimed.
- Extend a basic or dynamic volume in Windows and Windows Server | Microsoft Learn
- Thinly provisioned Virtual Disks inflates to a larger size during snapshot removal process
Additional revision sources:
- Get-Volume (Storage) | Microsoft Learn
- Get-Partition (Storage) | Microsoft Learn
- Get-Disk (Storage) | Microsoft Learn
- Get-PartitionSupportedSize (Storage) | Microsoft Learn
- Get-ChildItem (Microsoft.PowerShell.Management) - PowerShell | Microsoft Learn
- vssadmin list shadowstorage - in Windows and Windows Server | Microsoft Learn