The .vswp File Nobody Sized For: VM Swap Files and Datastore Capacity After the vSphere Exit

Power on a virtual machine with 64 GB of configured memory and no memory reservation, and vSphere creates a 64 GB file on the datastore before the guest operating system has finished booting.

Nobody requested it. It does not show up in the VM’s provisioned disk figure the way a virtual disk does, and it disappears again the moment the machine powers off. It is the .vswp file, there is one for every powered-on VM in the estate, and its size comes from a subtraction that most people have never had to do deliberately.

That file is the reason a VMware® estate running memory overcommit was paying for that overcommit in storage, not in memory. And it is the reason a datastore used figure, carried straight into an exit plan as the size of the workload, is wrong by an amount nobody has calculated.

What the .vswp file actually was

The arithmetic is simple and it is exact rather than approximate:

swap file size = configured guest memory − memory reservation

A VM configured with 64 GB and no reservation gets a 64 GB swap file. Reserve half of it and the file shrinks to 32 GB. Reserve all of it and no swap file is created at all. The file is created at power-on, in the VM’s working directory on the datastore by default, and it is removed at power-off.

Note the word created, not grown. This is not a file that starts small and expands under memory pressure. ESXi allocates it in full, up front, at power-on, whether or not a single page is ever written into it. That is the whole point of it: vSphere promised that every page of configured guest memory could always be backed by something, even if the host ran out of physical RAM, and the only way to keep that promise unconditionally was to reserve the space in advance.

The hypervisor did a great deal of work to avoid ever touching that file. Memory ballooning is the first line of defence, where a driver inside the guest requests memory from the guest OS so the hypervisor can hand those pages to a different VM, letting the guest make its own eviction decisions rather than having them made blindly from outside. Then page sharing, then compression. Host-level swapping to the .vswp file is the last resort, and on a healthy cluster it essentially never happens.

Which is exactly what makes it a storage problem rather than a memory problem. The file is a reservation, not a consumption. A well-run vSphere cluster wrote almost nothing into its swap files and still had to keep every byte of them on the datastore, permanently, for as long as the VMs were running.

Run the numbers on a modest estate. Four hundred powered-on VMs, 32 GB configured on average, reservations set on almost none of them because setting reservations defeats the overcommit the cluster was built for. That is 12.8 TB of datastore capacity, allocated, untouched, and counted in every capacity report the platform produced.

The number it hides in your capacity plan

Here is where it stops being a curiosity and starts costing money.

When a team sizes the destination platform for an exit, the figure that gets used is almost always datastore used capacity, because that is the number the platform reports, it is the number in the last capacity review, and it is the number that sounds most like “how much data we have.” It is not how much data you have. It includes a swap footprint that will not exist on the other side.

Substitute your own values into the model below. The illustrative figures are there to show the shape of the arithmetic, not to be borrowed.

Table 1: Extracting the swap footprint from a datastore used figure.

Twelve point eight terabytes on a 180 TB estate is roughly seven percent. That is not a rounding error, and it compounds with every other term in the forecast: protection ratio, operational reserve, growth allowance. Seven percent of phantom data, multiplied through a protection ratio and inflated again by a slack percentage, is real hardware sitting in a rack doing nothing.

The error runs in both directions, and the second direction is the one that actually hurts.

Size from datastore used, and you overbuy. You have carried a swap footprint into the plan that the destination will never create. The mistake looks prudent in a business case, which is precisely why it survives review.

Size from configured VM memory instead, and you may underbuy. A team that notices the first error sometimes corrects it by sizing purely from virtual disk capacity, which drops the swap footprint but also drops the question of what happens when the destination runs out of memory. The vSphere estate had an answer to that question, and it was a storage answer. If the destination platform needs an equivalent, it has to be provisioned somewhere, and it will not appear on its own.

This is the input that a broader capacity forecast quietly assumes and never names. That model re-derives the protection ratio, the operational reserve and the forecast unit. All three of them multiply whatever committed-data figure you feed in, so correcting the swap footprint first is what stops a good model from producing a confidently wrong answer.

The committed-data figure is the one term in an exit forecast that belongs to you rather than to a vendor, and it is usually the one nobody has audited. If you are sizing a destination platform and want the swap footprint, the protection ratio and the operational reserve separated out before you commit to hardware, that is a short conversation. Talk to a storage architect

What the destination does instead, and what it asks of storage

The artefact does not survive the migration, and that is worth stating plainly rather than looking for its replacement.

On KubeVirt and Red Hat® OpenShift® Virtualization, a VM’s guest memory is the memory allocation of the pod that runs it. There is no per-VM swap file on the storage layer, because there is no construct that would create one. The guest’s memory is accounted for as pod memory, and the Kubernetes scheduler places the workload against node memory rather than against a datastore. A balloon device still exists at the hypervisor level and behaves much as it did, but it produces no storage artefact, and following that thread any further turns a storage decision into a memory-tuning exercise.

Swap on Kubernetes is a different shape entirely. It is a node-level facility behind the NodeSwap feature gate: the node has a swap device, and the kubelet decides under policy whether workloads may use it. It is not a per-workload file, it is not sized from a workload’s configured memory, and it does not live on the shared storage pool. A team that wants an overcommit safety net has to enable and size it as a node property, deliberately, and it is off by default.

So the estate faces a genuine choice, and the honest framing is that all three answers are defensible.

Table 2: Three destination postures for the capacity that .vswp used to hold.

The third row is the one most estates should look at first, and it is the least popular. A significant share of the overcommit ratio in a long-lived vSphere cluster is not a deliberate density decision. It is configured memory that was set years ago from a vendor sizing sheet, never revisited because overcommit made it free to be generous. The exit is the moment that stops being free.

Where the storage layer genuinely helps

Two things are worth saying about what a modern storage layer does with this, and one thing is worth not saying.

Thin provisioning is the direct equivalent, and it behaves better than the thing it replaces. A .vswp file was a fully reserved, per-VM allocation, created at power-on and held whether or not the guest ever swapped a page. A thin-provisioned volume on a shared pool consumes what is actually written. The same overcommit posture is available, and the capacity backing it is drawn from a pool rather than stranded inside a per-VM file. Slack that was previously multiplied by VM count is now shared across the cluster.

Capacity that was a fixed per-VM tax becomes elastic. Under the old model, the swap footprint scaled with configured RAM across the whole estate, so growing memory density meant buying datastore headroom for capacity nobody intended to use. Separating the growth of the storage pool from the growth of the compute tier is exactly what independent scaling is for, and it is the structural reason simplyblock treats pool capacity and node count as two decisions rather than one. Thin provisioning only pays off if reclaim works, which is a related and separately worked problem covered in space reclamation after the exit.

What is worth not saying is that this makes the capacity free. It does not. It makes it pooled, elastic and measured against real consumption instead of against a worst case that never arrives, which is a better engineering position and a more honest one.

The practical consequence for sizing is a change of input. The right figure to size a destination against is not the datastore used number, and it is not the sum of configured guest memory either. It is the guests’ actual working set and write rate, which is a measurable thing on the source platform and one of the few pieces of evidence that transfers across the exit unchanged. Everything on the replacement datastore side is then derived from it, rather than from an artefact of how the old platform kept a promise it rarely had to honour.

Questions and Answers

Does KubeVirt create a swap file per VM the way vSphere did?

No. On KubeVirt and OpenShift Virtualization, guest memory is the memory allocation of the pod running the VM, and there is no per-VM swap artefact on the storage layer. Any swapping is a node-level Linux facility behind the NodeSwap feature gate, on the node’s own swap device rather than on the shared pool. Simplyblock’s recommendation is to treat this as a sizing correction rather than a feature gap: remove the swap footprint from the committed-data figure, then size the pool from the guests’ real working set and write rate. That is the input the destination actually consumes, and it is measurable before you migrate anything.

How do I calculate the .vswp footprint in my own estate?

Count powered-on VMs, sum their configured memory, subtract any memory reservations, and you have it. The reservation term is the one to check rather than assume, because estates that were built for density usually set almost none, which means the footprint is close to the full sum of configured RAM. Powered-off VMs contribute nothing, so use a powered-on inventory rather than a total VM count.

If the swap file was almost never written to, does removing it really change anything?

Yes, because it was reserved capacity rather than consumed capacity, and reserved capacity is what a datastore used figure reports and what a capacity plan is built from. The file being untouched is precisely the problem: you bought and held the space, it appeared in every capacity report, and it will be multiplied by the protection ratio and the operational reserve when that figure is carried into a destination forecast.

Should I replicate the old overcommit ratio on the new platform?

Not by default, and not without re-deriving it. The old ratio was a risk position taken against a specific safety net that no longer exists in the same form. Re-establish it explicitly as a node memory decision, a node-level swap decision, or a guest right-sizing exercise, and record who owns it. Inheriting a number from a platform that enforced it differently is how a cluster that looked comfortable on paper runs out of room.

Is Ceph a reasonable choice for this kind of pooled, thin-provisioned capacity?

Ceph is a good option when performance is not the main goal, and it does thin provisioning perfectly competently. The trade-offs to weigh are the raw-to-effective ratio it delivers at your chosen protection level and the host CPU its data path consumes, both of which push in the same direction as the sizing correction described above. Based on publicly available information as of September 2026, simplyblock’s erasure coding lands nearer 1.25:1 at FTT1 against roughly 3:1 for three-way replication in practice, which changes how much raw flash the corrected figure turns into. These are our own comparison figures rather than independently verified benchmarks, so treat them as a starting point for your own test.