Troubleshooting vSAN Disk Claiming and Capacity Issues
Disk claiming problems in vSAN are often mistaken for a simple lack of free capacity, yet they require different investigations. A disk claim attaches an eligible local device to a vSAN disk group; it does not merely make a drive visible in vSphere. You may encounter an unclaimed disk, a claim failure, a disk assigned to the wrong group, or a healthy group with little usable space.
Establish what changed, preserve the evidence, and avoid unnecessary changes to production storage. This matters in Australia, where some workloads carry residency or contractual restrictions and moving compute between Sydney, Melbourne, and Perth is not a practical escape valve. Check vSAN health, host warnings, and object-space usage before touching a claimed device.
Recognise the real symptom
A disk claiming issue usually points to device eligibility, ownership, or metadata: the drive is already claimed, its identity has changed, or another filesystem prevents vSAN from claiming it. A capacity issue usually points to the object datastore, provisioned VM disks, rebuild activity, or exhausted free capacity within the disk group. The same alert can accompany several of these conditions.
Start with the vSAN Storage view in vCenter, then correlate it with vmkernel.log and the disk-group display on each ESXi host. Record device identifiers, claim errors, timestamps, and rebuild status. When an Australian engineer calls a problem “fair dinkum”, that usually means the evidence points to a genuine blocker rather than routine housekeeping. The VMware Series library provides useful background for the wider platform and troubleshooting workflow.
Check the vSAN storage view
Separate physical capacity from usable capacity. A local datastore can have free blocks while the vSAN object datastore has little room, particularly when thin-provisioned VMs and datastore overcommitment are involved. Space reservation settings also affect what appears available, so compare displayed capacity with the space vSAN can actually use while maintaining redundancy and rebuild headroom.
On the affected host, esxcli vsan storage list helps confirm device state and disk-group membership. Read-only diagnostic listings, such as esxcli vsan debug object list, can add detail where access policy allows. Search /var/log/vmkernel.log for claim failures, device-identity mismatches, and transport errors. Capture timestamped output and normalise timestamps to UTC before correlating evidence across hosts.
Trace the disk claiming failure
Foreign VMFS partitions, unsupported device configurations, and stale vSAN metadata can each prevent a claim. Firmware updates and controller replacements can also change the identifier seen by ESXi, leaving vSAN unable to match its metadata. Compare the NAA identifier, vSAN device ID, and ownership state before attempting a reclaim; a physically healthy drive may still be ineligible for safe ownership.
Do not treat “unclaim” as a reset button. In vSAN Disk Management, use unclaim and reclaim only within a tested maintenance procedure, after checking data ownership, redundancy, and rebuild requirements. If metadata is stale or the identity is mismatched, follow the supported recovery path instead of forcing the disk into service. Replacement storage has an Australian wrinkle: a spare SSD may spend several days crossing state lines while the failed drive still occupies a cluster slot.
Compare common capacity symptoms
Use this comparison alongside the vSAN dashboard and recent activity to identify the likely source before opening a change request.
| Observed symptom | Likely cause | Safe checks |
|---|---|---|
| Datastore reports free space while vSAN is full | Thin provisioning and datastore overcommitment | Review storage policy reservations and actual VM consumption |
| A device is visible but unclaimed | Stale metadata, foreign filesystem, or changed device identity | Compare identifiers, disk state, and vmkernel.log messages |
| All disks are claimed, but usable capacity fell sharply | Rebuild, resynchronisation, or snapshot overhead | Check reconstruction progress and object-space consumption |
| Capacity differs between hosts in one disk group | Mixed device capacities, failed members, or differing usable sizes | Inspect disk-group membership and per-device capacity |
| vSAN health alerts during capacity changes | Rebuild without sufficient headroom | Review failover capacity and remaining free capacity |
Read the comparison carefully rather than treating every low-space alert as disk exhaustion. A vSAN object datastore normally reserves space for object data, so that reservation setting is not proof of wasted capacity. During rebuilds or resynchronisation, temporary overhead and reduced failover capacity matter more than the headline figure for raw free space.
Restore a healthy disk group
Before reclaiming a device, verify its health, failed-object status, and the location of every required replica. Check that the cluster has enough healthy capacity to satisfy its configured redundancy and rebuild rules. A disk group can look empty in the device list while vSAN still depends on its metadata and capacity for safe replacement.
Use the vCenter workflow to unclaim and reclaim disks only after capturing configuration backups and confirming the affected data is invalid or migrated. Match the replacement device to the expected capacity and configuration, and avoid changing the disk group, provisioning policy, or replication rules in the same maintenance window. Rescan storage adapters after the hardware state is stable, then verify that vSAN has accepted the device into the intended group.
Protect capacity during rebuilds
Rebuilds, resynchronisation, and VM migration can consume headroom and temporarily reduce usable capacity. Give the cluster enough free space to restore redundancy without blocking ordinary writes, and reserve room for the failure scenarios your policy requires. Thin-provisioned guests can grow beyond their initial allocation, while snapshots and consolidation add pressure, so monitor provisioned commitments as well as measured consumption.
Storage policy is part of capacity management, not merely a replication setting. Review the configured data copies, any erasure coding, and failover capacity against actual disk-group limits before changing a policy on a live cluster. Australian distance and latency between major cities also affect stretched-cluster designs: a link that looks adequate for application traffic may not suit synchronous vSAN replication.
Capacity decisions should include the local cost of keeping drives powered and cooled in Sydney and Melbourne, where electricity and data-centre space are expensive. That supports measuring utilisation carefully, but it does not justify filling a disk group without rebuild headroom. Purchase capacity for effective redundancy and recovery needs, not for an encouraging free-space number in a datastore summary.
Make the response repeatable
Create a short runbook for each path: claim failure, unclaimed device, exhausted disk group, and full object datastore. It should identify the required dashboard views, host log entries, device identifiers, rebuild checks, and approval gates. Assign ownership across storage, hypervisor, and hardware teams, and record who can authorise an unclaim during Australian business hours. In regulated environments, align evidence retention with the organisation’s ASD-aligned control requirements.
Use the storage optimisation guide to standardise the supporting checks, then save baseline readings and recovery criteria with the change record. Start with one affected disk, document its identity and current vSAN health, and rehearse the approved maintenance path before touching production storage.