VMware: Cannot Extend Disk in vSphere When the Option Is Greyed Out

If the Edit Settings option to increase a VMware virtual disk is greyed out, there is usually a reason. It is not necessarily a problem with the datastore or the virtual disk itself.

I ran into this on a VM where other virtual machines could have their disks extended without any problem. The difference turned out to be a snapshot left behind by a backup job. The backup had been running for several days, had become stuck, and the snapshot had not been noticed.

Once the backup issue was resolved and the snapshot was removed, the virtual hard disks could be extended normally while the VM was running.

That experience is worth keeping in mind because snapshots can be much less obvious in the newer vSphere interface than they were in the old vSphere Client.

If a VMDK cannot be extended, check the VM’s snapshots and consolidation state before assuming the disk itself is the problem.

Check for snapshots first

The first thing I would check is whether the VM has a snapshot.

In the vSphere Client, select the VM and look under:

Actions → Snapshots → Manage Snapshots

Look for any existing snapshots, particularly ones that are unexpectedly old.

A snapshot is not a second copy of the entire virtual disk. VMware creates delta files that record changes made after the snapshot was taken. This becomes particularly important when a backup product creates a snapshot and then leaves it in place.

An old snapshot can also explain why one VM behaves differently from others in the same environment.

Check for consolidation

Even when a snapshot is not immediately obvious, vSphere may report that the VM needs consolidation.

Look at the VM’s Summary tab for:

Virtual machine consolidation needed status
Virtual machine disks consolidation is needed.

Or on the Snapshots tab:

Consolidation is required

Broadcom’s documentation on this message explains the cause: an inconsistency between what the snapshot manager believes exists and the actual state of the snapshot files on the datastore.

That’s exactly the situation a failed backup produces. The backup product removed the snapshot from the manager’s view but the delta files are still on disk.

PowerCLI can identify VMs with the consolidation flag set:

powershell

Get-VM | Where-Object { $_.ExtensionData.Runtime.ConsolidationNeeded }

This is useful when the problem isn’t limited to one VM and you want to check an entire environment.

You can also list snapshots across the estate:

powershell

Get-VM | Get-Snapshot |
    Select-Object VM, Name, Created, SizeGB |
    Sort-Object Created

That quickly exposes snapshots that have been sitting around for days or weeks.

Check the backup or replication software

If you find a snapshot, don’t assume it was manually created.

Backup and replication products commonly use VMware snapshots as part of their processing. If a backup job fails, hangs or loses communication with vSphere, the snapshot can remain behind.

Broadcom lists a third-party backup application locking the snapshot file, and failing to remove it afterwards as one of the documented causes of consolidation failure. Veeam and Commvault are both named in their guidance as products that create and remove snapshots automatically, and where a failed removal leaves consolidation flagged.

Check the backup product for:

• A job that is still running
• A failed or stalled backup
• A previous backup that never completed
• Replication activity involving the VM
• Snapshot removal or consolidation errors

Establish why the snapshot exists before deleting it.

If a backup job still believes it owns the snapshot, manually removing it can create another problem.

Be careful with snapshot removal

An old snapshot shouldn’t be deleted without considering its size, age and the current workload.

Deleting a snapshot causes VMware to merge the changes recorded in the delta files back into the parent virtual disk. A large snapshot that has existed for days can contain a substantial amount of changed data, and the merge is an I/O-heavy read-and-write operation.

Three things are worth knowing before you start.

Don’t cancel a running consolidation. Broadcom’s snapshot best practices state plainly that cancelling a running deletion or consolidation task can lead to data corruption. If it’s taking longer than you expected, let it finish.

Consolidation needs free space. Broadcom documents consolidation failing when the datastore has less than 1 GB available. Check capacity before you start, not after it fails.

A powered-off VM consolidates faster. With the VM powered off, no additional free space is required and the process completes more quickly, because there are no writes to track and no helper snapshot to create. If you can take an outage, it’s the safer option for a large snapshot.

Broadcom also notes that a VM undergoing consolidation of a large snapshot may appear unresponsive or frozen while the operation runs. That’s expected behaviour, not a failure.

On a busy production VM, treat snapshot removal as a change rather than simply clicking Delete and moving on.

Check datastore capacity properly

Before extending a virtual disk, check how much free space is available on the datastore.

Don’t only calculate:

Current free space – disk increase = remaining free space

That calculation is misleading when snapshots are involved.

With a thin-provisioned virtual disk, extending the VMDK increases its maximum capacity, but actual datastore consumption grows as data is written. If snapshots are present, their delta files can also continue growing, potentially consuming significantly more datastore space than the VMDK extension alone suggests.

With a thick-provisioned disk, the additional capacity is generally committed on the datastore when the disk is extended. With eager-zeroed thick provisioning, the space for the increase is allocated immediately.

So if you have 100 GB free and want to add 50 GB, don’t assume you’ll simply have 50 GB remaining. Check the provisioning type, existing snapshots and expected snapshot growth first.

Also check what else is consuming space on the same datastore. A datastore that looks healthy at first glance can become critically low during a large consolidation.

Other reasons the disk extension can be greyed out

Snapshots are one of the first things I’d check, but they aren’t the only possible cause.

Shared or multi-writer disks

Some virtual disks have sharing configurations that prevent normal disk operations.

If the disk is used by multiple VMs or configured for multi-writer access, check the VM and disk configuration before attempting to extend it. This is common in certain clustered application configurations.

Linked clones or dependent disks

A disk with a dependency on another virtual disk may have restrictions on how it can be modified.

If the VM is part of a linked-clone or similar configuration, check the disk chain before attempting changes.

Physical RDMs

A physical compatibility mode Raw Device Mapping isn’t a normal VMDK.

If the disk is an RDM or another special storage configuration, the usual virtual disk expansion process may not apply. Check the storage configuration rather than treating it like an ordinary VMDK.

Permissions

If you can view a VM but can’t perform certain configuration changes, check your vSphere permissions.

Compare your access against a VM where disk expansion works. This is particularly worth checking in larger environments where access is delegated through vCenter roles.

VM state and configuration

Normally, VMware allows supported virtual disks to be extended while the VM is powered on. Special configurations can introduce restrictions.

Check whether the affected VM differs from the working VMs in areas such as:

• Hardware version
• Disk controller
• Disk type
• Storage location
• Snapshot state
• Sharing configuration
• Replication configuration
• Backup configuration

The fact that other VMs can be extended is useful evidence. Compare the affected VM against one that works rather than troubleshooting it in isolation.

Extending the VMDK is only half the job

Getting additional capacity onto the virtual disk doesn’t automatically make that space available to the operating system.

There are two separate operations:

1. Increase the virtual disk in vSphere.
2. Extend the partition or filesystem inside the guest operating system.

If you increase a Windows disk from 100 GB to 150 GB, Windows will initially see additional unallocated space. The partition still needs to be extended.

In Windows, this can normally be done through Disk Management.

You can also use DiskPart:

diskpart
rescan
list volume
select volume 2
extend

Make sure you select the correct volume before running extend. The volume number in that example is illustrative, not universal.

Linux

On Linux, the exact commands depend on how the disk and filesystem are configured.

First inspect the layout:

bash

lsblk

For a simple partitioned disk, growpart can extend the partition:

bash

growpart /dev/sda 2

For an ext4 filesystem:

bash

resize2fs /dev/sda2

For XFS:

bash

xfs_growfs /

If the system uses LVM, the process also involves the physical volume, volume group and logical volume. Don’t assume that extending the VMDK automatically extends the LVM filesystem.

Snapshot limits worth knowing

Two figures from Broadcom’s best practice guidance are worth having in mind.

A maximum of 32 snapshots is supported in a chain. Consolidation can fail when you exceed the recommended number.

Snapshots are not backups. The snapshot file is a change log against the original virtual disk. If the base disks are deleted, the snapshot files alone cannot restore a virtual machine. That’s worth repeating to anyone who has been treating a snapshot as a safety net before a change.

A practical troubleshooting sequence

When a virtual disk can’t be extended because the option is greyed out, work through it in this order:

1. Check the VM’s snapshots.
2. Check whether the VM reports “Needs Consolidation”.
3. Check backup and replication jobs involving the VM.
4. Determine whether a backup or replication product created the snapshot.
5. Check the snapshot age and size.
6. Check datastore free space and provisioning type.
7. Check for shared, multi-writer, linked-clone or RDM configurations.
8. Check your vSphere permissions.
9. Compare the affected VM’s configuration with a VM where disk expansion works.
10. After extending the VMDK, extend the guest partition and filesystem.

This order starts with the conditions most likely to explain why one otherwise normal VM can’t be extended, while avoiding unnecessary changes to the VM.

The point worth remembering

Snapshots are one of the first things I’d check when Edit Settings is unavailable for one VM but works normally for others.

The lesson isn’t “delete the snapshot”. It’s to find out why it exists, confirm the backup or replication operation isn’t still using it, check datastore capacity, and then deal with it safely.

Once that’s resolved, the disk extension itself is usually the easy part.

Broadcom references

How to calculate current snapshot size and estimate consolidation time – the factors affecting how long consolidation takes

Best practices for using VMware snapshots in the vSphere environment – the 32-snapshot limit, why snapshots aren’t backups, and the warning against cancelling a consolidation

The message “Virtual Machine Consolidation Needed” appears for a specific virtual machine – causes of the consolidation flag, including third-party backup locks

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.