VMware ESXi and vSphere Cluster Management

Expand a Virtual Hard Disk in VMware Workstation Player

Learn how to expand a VMware Workstation Player virtual disk, then extend Windows or Linux partitions, volumes, and file systems safely.

Expanding a virtual hard disk has two separate parts. First, VMware increases the virtual disk's configured capacity. Then, the guest operating system must extend a partition, volume, and file system into the newly available space.

This guide covers VMware Workstation Player, Windows guests, Linux guests, standard partitions, and Linux LVM layouts. Back up important data before changing virtual disks or partition structures.

What virtual disk expansion does

A virtual hard disk is a VMware virtual disk file or device presented to the guest as a hard drive. Its virtual disk capacity is the maximum size configured for that disk in VMware.

When you increase that capacity, VMware adds capacity to the end of the virtual disk. The guest can then detect a larger disk containing new unallocated space. Unallocated space is capacity that has not yet been assigned to a partition or volume.

Increasing the VMware disk does not automatically enlarge the guest's partition or file system. A partition is a defined region of a disk. A Windows volume is a storage unit, commonly associated with a partition. A file system, such as NTFS, ext4, or XFS, organizes files within that storage region.

Storage layer — What changes — Example

Virtual disk — The maximum capacity presented by VMware — 60 GB becomes 100 GB

Partition or volume — The region assigned to an operating system storage structure — A 60 GB system partition grows to 100 GB

File system — The space the operating system can use for files — NTFS, ext4, or XFS reports the larger size

For example, a 60 GB VMware disk may become a 100 GB VMware disk while the guest still reports a 60 GB system volume. The remaining 40 GB is unallocated until the guest-side expansion is completed.

Requirements and limitations before expanding

Use the following checklist before opening the disk expansion control.

Condition — Why it matters — Recommended action

VM power state — Disk changes may be unavailable or unsafe while the guest is running — Shut down the guest normally and confirm that the VM is fully powered off

Snapshots — Snapshot chains can affect which disk is active and whether expansion is allowed — Review snapshots and consolidate or remove them when required by your VMware version and workflow

Mounted or mapped disks — A disk accessed by the host or another process may be locked — Disconnect host mappings and ensure the target disk is not mounted for host access

Linked clones — A linked clone depends on another virtual disk — Do not assume that the clone or its parent supports direct expansion; review the clone relationship first

Host free space — A thin-provisioned disk may consume more host storage as data is written — Ensure the host storage volume has sufficient free capacity for growth, snapshots, and normal operation

Backup availability — Disk and partition changes can make data inaccessible if interrupted or misapplied — Create a verified backup or independent clone before proceeding

Special disk configurations — Encrypted, shared, raw-device, and other special disks can have additional restrictions — Check the VMware version's requirements before changing the disk

Identify the correct virtual disk before changing anything. A VM with multiple disks may contain an operating-system disk, a data disk, and a backup or application disk. Match the disk by its size, device position, and guest layout rather than selecting the first disk in the list.

Record the original configuration and your intended new total size. Do not interrupt the host or guest during a disk operation, and use the guest's normal shutdown process instead of abruptly powering it off.

Expand the disk in VMware Workstation Player

  1. Shut down the virtual machine normally. Wait until VMware shows that it is powered off.

  2. Select the VM from the VMware Workstation Player library.

  3. Open the VM's settings or hardware configuration interface. Menu labels can differ between VMware Workstation Player versions.

  4. Select the intended Hard Disk device. Confirm that its current capacity and device details match the disk you identified earlier.

  5. Choose the disk expansion control, commonly labeled Expand or Expand disk capacity.

  6. Enter a new capacity that is greater than the current capacity.

  7. Confirm the operation and wait for VMware to finish.

This completes only the VMware-side operation. The guest must still detect the larger disk and extend its partition or volume and file system.

Verify the added capacity in the guest

  1. Boot the VM after VMware reports that the expansion has completed.

  2. Confirm that the operating system detects the larger disk.

  3. Locate the new unallocated region in the correct disk layout.

  4. Compare the disk number, size, partitions, and file-system type with your recorded configuration.

Extend storage in a Windows guest

Using Disk Management

Disk Management is the Windows graphical utility for inspecting disks and extending eligible volumes.

  1. Start the Windows guest and sign in with an account that has administrative rights.

  2. Open Disk Management. Inspect the disk number, existing partitions, volume labels, and unallocated space.

  3. Right-click the target volume, such as the system volume, and choose Extend Volume when the option is available.

  4. Use the wizard to select the adjacent unallocated capacity and complete the operation.

  5. Verify the larger volume in Disk Management and in File Explorer.

Windows normally extends a basic volume only when suitable unallocated space is directly adjacent to the volume in a supported layout. The following arrangement can block a simple extension:

System volume | Recovery partition | Unallocated space

Although free space exists on the disk, the recovery partition is between the system volume and that space. Disk Management cannot simply move that partition and extend the system volume.

In this situation, safer choices include using the unallocated area as a separate data volume or creating a carefully planned partition-management procedure with a tested backup. Moving or recreating a recovery or boot partition can affect startup and recovery tools.

Using DiskPart

DiskPart is the Windows command-line disk management utility. Use it only after matching disk and volume numbers to the intended layout.

diskpart
list disk
select disk <number>
list volume
select volume <number>
extend
exit

The selected volume must be eligible for extension into suitable adjacent unallocated capacity. The commands do not remove the need to inspect the complete layout. Selecting the wrong disk or volume can affect unrelated data.

For BitLocker-protected volumes, handle the change according to your organization's policy. Keep recovery information available, and suspend protection only when required and authorized. Verify BitLocker status after the resize.

Extend storage in a Linux guest

Linux storage can contain several layers. A simple layout may be a virtual disk, a partition, and a file system. An LVM layout can include a virtual disk, partition, physical volume, volume group, logical volume, and file system.

Inspect the layout first

Use inspection commands before modifying a device. Device names such as /dev/sda and partition numbers such as 1 are examples; use the identifiers shown by your guest.

lsblk
sudo fdisk -l
sudo parted -l
df -hT

These commands help identify disk sizes, partitions, mount points, file-system types, and whether LVM is present. Take particular care when the VM has more than one virtual disk.

Standard partition with ext4

For a simple ext4 partition that is the final partition on the disk, grow the partition and then grow the file system:

sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1

growpart enlarges a partition into available space. resize2fs enlarges an ext-family file system such as ext4. The partition must have suitable space after it, and the command must match the actual device and partition number.

Standard partition with XFS

XFS is expanded through its mounted file system. It uses the mount point rather than a block-device argument for the file-system growth step.

sudo growpart /dev/sda 1
sudo xfs_growfs /mount/point

Replace /mount/point with the actual mount point, such as / or /data. Confirm the file-system type with df -hT before choosing a growth command.

Linux with LVM

LVM, or Logical Volume Manager, adds storage layers. A common sequence is to enlarge the underlying partition, resize the physical volume, extend the logical volume, and then grow the file system.

sudo growpart /dev/sda 2
sudo pvresize /dev/sda2
sudo lvextend -r -l +100%FREE /dev/<volume-group>/<logical-volume>

pvresize makes the added partition space available to LVM. lvextend increases the logical volume. The -r option requests file-system growth when supported. If it is not used or does not complete the file-system step, grow the file system separately with the appropriate command, such as resize2fs for ext4 or xfs_growfs for XFS.

Do not apply the LVM sequence to a non-LVM partition. First identify the physical volume, volume group, logical volume, and mounted file system.

Verify Linux capacity

lsblk
df -hT

lsblk should show the expected disk, partition, and logical-volume sizes. df -hT should show the increased file-system capacity and type. A larger partition with an unchanged file system means the final growth step was not completed.

Partition-layout considerations

The desired partition normally needs unallocated capacity immediately after it. If another partition lies between the target and the free region, a simple extension usually cannot use that space.

Recovery and boot partitions deserve special care. Deleting or moving one can prevent normal booting or remove recovery tools. Back up the guest, document the layout, and verify a recovery plan before using partition-management software to relocate partitions.

MBR, or Master Boot Record, is an older partition-table format with practical size and partition-count limitations. Large virtual disks can encounter MBR limits, especially around the traditional 2 TiB boundary. GPT, or GUID Partition Table, is the modern format and is generally more suitable for larger disks and additional partitions. The guest's firmware mode and operating-system support also matter when changing boot-related layouts.

Guest-side expansion tools

Guest platform — Storage layout — Inspect — Expand partition or volume — Expand file system — Verify

Windows — NTFS basic volume — Disk Management or diskpart — Extend Volume or extend — Usually performed as part of the Windows volume extension — Disk Management and File Explorer

Linux — ext4 partition — lsblk, fdisk, parted, df -hT — Partitioning utility or growpart — resize2fs — lsblk and df -hT

Linux — XFS partition — lsblk and df -hT — Partitioning utility or growpart — xfs_growfs using the mount point — lsblk and df -hT

Linux — LVM with ext4 or XFS — lsblk, pvs, vgs, lvs, df -hT — Extend the partition, then use pvresize and lvextend — Grow with lvextend -r or use the file-system-specific tool — lsblk, LVM commands, and df -hT

Windows example: expanding a 60 GB system disk

Suppose a Windows VM has a 60 GB virtual disk and needs more space on its system drive.

  1. Back up the VM and shut it down normally.

  2. In VMware settings, select the correct hard disk and expand its total capacity to 100 GB.

  3. Boot Windows and open Disk Management.

  4. Confirm that the additional capacity appears as unallocated space on the intended disk.

  5. Extend the primary NTFS volume if the unallocated space directly follows it.

  6. Confirm the larger volume in Disk Management and File Explorer.

Linux examples

Simple ext4 layout

For a Linux VM with a standard final partition and ext4 file system, expand the VMware disk, grow the partition, and then grow ext4:

sudo growpart /dev/sda 1
sudo resize2fs /dev/sda1
lsblk
df -hT

LVM layout

For a VM with an LVM physical volume on /dev/sda2 and an ext4 or XFS logical volume, expose the new partition space to LVM before extending the logical volume:

sudo growpart /dev/sda 2
sudo pvresize /dev/sda2
sudo lvextend -r -l +100%FREE /dev/<volume-group>/<logical-volume>
lsblk
df -hT

Validation and post-change checks

  1. Verify the virtual disk capacity in VMware settings.

  2. Verify the partition or Windows volume size in the guest.

  3. Verify file-system capacity and free space using File Explorer, Disk Management, or df -hT.

  4. Restart the guest if a disk rescan or reboot is needed, and confirm normal boot behavior.

  5. Check that applications, scheduled jobs, and guest services can read and write the expanded volume.

  6. Monitor free space on the host as well as inside the guest, especially when the virtual disk is thin provisioned.

Common disk expansion problems

Symptom — Likely cause — Safe next step

Expand option unavailable — The VM is running, snapshots exist, the disk is part of a linked clone, or the disk is mounted, mapped, encrypted, shared, or otherwise special — Power off the VM, review snapshots and clone dependencies, disconnect mappings, and check the disk-type restrictions for the VMware version

Guest does not show extra disk capacity — The wrong disk was expanded, the guest has not refreshed its view, or the VM did not boot the changed configuration — Recheck VMware settings, restart or rescan the guest where supported, and compare sizes with Disk Management or lsblk

Extend Volume is unavailable — Unallocated space is not directly adjacent, or the volume and partition scheme has a limitation — Inspect the full layout; use a separate volume or a carefully planned, backed-up partition workflow

Linux file system does not report additional space — Only the partition grew, the wrong file-system tool was used, or an LVM layer was skipped — Identify the type with df -hT; use resize2fs for ext4, xfs_growfs for XFS, or complete the LVM sequence

Insufficient host storage — The host volume cannot support disk growth, snapshots, or guest writes; thin provisioning may delay host consumption until data is written — Free or add host storage and monitor actual host-space usage

Safety checklist

  • Back up important guest data before changing virtual disks, partitions, volumes, or file systems.

  • Record the original disk configuration and intended new total capacity.

  • Use the guest's normal shutdown process before VMware-side changes.

  • Confirm the target disk by size, device, and guest partition layout.

  • Do not interrupt VMware or the guest during disk operations.

  • Do not delete boot or recovery partitions without a tested recovery plan.

  • Remember that a VMware disk expansion is incomplete until the guest can use the new file-system capacity.

For related storage work, continue with virtual hard disk expansion guidance and apply the same separation between VMware disk capacity and guest storage structures.