Spare host RAM does not eliminate the VM's swap-backing requirement. ESXi reserves swap space for the difference between configured VM memory and its memory reservation. A power-on can therefore fail because the required swap file cannot be created on its selected datastore, even before the guest starts using memory.
This article covers the ESXi 8.x error family in KB 341571. The KB also lists ESXi 7.x, but this article intentionally uses the 8.0 resource guide and does not validate a 7.x procedure. No VM was powered on and no reservation or storage configuration was changed. All calculations below are hypothetical.
The allocation boundary
The vSphere 8.0 resource guide describes the requirement as configured memory minus reserved memory. The purpose is to let ESXi preserve VM memory if reclamation becomes necessary. Reserved backing space and bytes actually swapped during a workload are different quantities.
For example, a VM configured with 32 GiB of memory and an 8 GiB reservation has 24 GiB of unreserved memory. That is the memory quantity for which this regular per-VM swap backing is required. It does not mean that 24 GiB is currently being swapped, nor that 24 GiB is the total storage required by every VM file and concurrent operation.
Guest paging is another layer. Expanding a Windows page file or a Linux swap partition does not repair ESXi's inability to create a host-side VM swap file before power-on. Conversely, a healthy datastore does not prove the guest has an adequate memory budget once running.
Read the complete failure, including the storage path
Prerequisites are the existing failed task detail, the VM's configured memory and reservation, its selected swap destination and approved read access to storage health. Record ESXi build, host, VM identity and timestamp. Do not infer the swap destination solely from the location of a data VMDK; the task's actual path is stronger evidence.
The KB groups several messages beneath “Failed to extend swap file”. Read the inner reason:
| Inner error | Diagnostic boundary |
|---|---|
| No space left on device | Space allocation on the selected backing location. |
| Invalid metadata | Storage metadata/access problem; free bytes alone are insufficient. |
| Storage initiator error | Host communication with the backing storage. |
Preserve the named datastore or volume identifier and requested size. Compare the size with configured memory and reservation using the same units. A KB example expressed in KB must not be compared directly with a dashboard number labelled GiB without conversion.
Inspect existing datastore availability and free-space evidence for that host and interval. A different datastore's free capacity, or a cluster-wide aggregate, does not answer whether this path can allocate the file. For an initiator error, the KB directs attention to matching host storage evidence in vmkernel.log; retain the device identifier and full sense/status information rather than reducing every storage error to “disk full”.
For the initiator branch, KB 341571 specifically asks for Sense code H:0x7 D:0x0 P:0x0 for the LUN backing the failed datastore. Match device and time; this is a source example, not a universal interpretation of every H:0x7 entry.
Worked diagnosis
Suppose the fictional 32-GiB VM above has an 8-GiB reservation. Its failed task names a swap destination with 10 GiB available and reports “No space left on device”. The 24-GiB unreserved-memory requirement explains why apparently comfortable host RAM does not make this allocation possible.
If the same task instead reports “Invalid metadata”, the arithmetic is still useful for documenting requirements, but the 10-GiB observation is not the whole diagnosis. Multiple faults can coexist. If 100 GiB is free but the task reports “Storage initiator error”, increasing datastore capacity would not address the demonstrated communication boundary.
A successful retry from another placement might avoid a symptom without explaining the original host's storage fault. KB 341571 explicitly says its workarounds still require investigation into the underlying issue. Do not use migrations as unsupervised diagnostic experiments.
Evaluate remedies without hiding the fault
The KB discusses changing the swap destination, increasing a memory reservation and expanding storage in particular cases. Each changes a different resource commitment. A full reservation can remove this unreserved-memory requirement, but also commits physical memory and affects admission capacity. It is not free storage relief.
A destination change must meet the supported storage and operational requirements for the VM and cluster. Expansion changes persistent storage and does not fix invalid metadata or a failed path. Select a remedy only after the exact error, destination and resource calculation agree; obtain the qualified capacity or storage review for that change.
The KB’s options differ by inner error: for Invalid metadata, another datastore or a full memory reservation; for No space, those options plus datastore expansion; for the matching Storage initiator case, migration to another host is its documented workaround. These are separately reviewed operational choices, not commands to run during diagnosis. The KB still requires investigation of the underlying storage fault. Guest paging remains a separate requirement; the guide also describes guest swap relative to configured minus reserved memory, which does not make it a repair for a failed ESXi swap allocation.
Acceptance and reversal
Diagnostic acceptance is an identified VM, its calculated unreserved memory, the actual failed destination and the specific inner error. Later functional acceptance requires a separately authorised power-on with the intended configuration, no repeated swap-allocation error and healthy storage evidence. No such acceptance test was performed here.
Read-only inspection requires no rollback. Reverting a reservation or destination requires restoring the recorded setting under a reviewed plan; it can recreate the original requirement. Expanded storage should not be assumed safely shrinkable. Do not delete swap-looking files or change reservations across a cluster to make a single VM start.
Learning notes
- Swap backing can be required before memory pressure occurs.
- Host RAM and datastore allocation are separate admission boundaries.
- The inner storage error determines which remedy is relevant.
References
- A08-D2: Swap Space and Memory Overcommitment
- A08-S1: Error: "Failed to extend swap file from 0 KB to #### KB" when attempting to power on a virtual machine