Sparse Volume Overcommit Host ENOSPC

Sparse VM or container volumes can each pass a free-space check and still promise more bytes than the host owns. When tenants later fill those promises, the failure is host-wide ENOSPC, not one isolated noisy volume.

Runbook: Sparse Is A Placement Promise

1. Do not rely on a point-in-time free-space check. It proves the host can create the file today, not that the host can satisfy all promised bytes later.
2. Track provisioned bytes per host as a first-class placement metric: every volume size, resize, snapshot reserve, overlay reserve, image cache reserve, and emergency free-space band.
3. Reject create and resize requests that would push provisioned bytes beyond capacity multiplied by the configured overcommit ratio.
4. Default strict before launch. An overcommit ratio of 1.0 is easier to relax later than a silent host-wide corruption mode is to repair.
5. Keep actual free-space checks separate from admission. Admission protects promises; runtime guards protect the emergency reserve when real usage spikes.
6. Expose metrics for provisioned bytes, actual used bytes, reserve bytes, overcommit ratio, and largest promised tenants.
7. Offer thick allocation or stricter storage classes for database volumes, write-heavy queues, and other guests where ENOSPC can corrupt state.

I would treat this as an admission-control bug rather than only a disk-free check.

The failure mode is that point-in-time host free space is true at create time, but the sum of sparse promises is false over time. Acceptance checks I would add:

- Track provisioned bytes per host: sum(volume.size_mb) plus overlay/snapshot reserve.
- Refuse create/resize when provisioned bytes would exceed capacity * overcommit_ratio minus reserve.
- Keep a separate free-space guard for actual host bytes so existing volumes cannot consume the emergency band.
- Emit metrics for provisioned bytes, actual used bytes, reserve bytes, and largest tenants by promised size.
- Add a regression test with two sparse volumes that each fit individually but exceed host capacity together.
- Offer thick/fallocate mode or stricter class policy for database volumes where correlated ENOSPC is least tolerable.

Do Not Treat As One Noisy Tenant

• Volumes, overlays, snapshots, image caches, and logs that share the same host filesystem.
• Database guests where guest-level ENOSPC can corrupt WAL, page files, or transaction state.
• Platforms without a reserve band for host agent logs, cleanup jobs, and emergency repair commands.
• Any create/resize path that checks actual free bytes but ignores total promised bytes.