In this article
A thin-provisioned virtual disk in Proxmox VE does not reveal which layer is conserving space. In one documented arrangement, the qcow2 image format provides thin provisioning on file-level directory storage. In another, an LVM thin pool allocates blocks when they are written while Proxmox exposes the disk as a raw volume.
Both arrangements defer physical allocation, but the feature originates in different places. This distinction explains why thin provisioning on directory storage depends on the selected image format, while LVM-thin can use raw volumes and still allocate space on demand.
This is a documentation-based comparison; no allocation, capacity, or performance testing was performed.
Thin provisioning can originate at two layers
Proxmox VE distinguishes file-level storage from block-level storage. File-level storage provides access to a filesystem and can accommodate multiple content types. Block-level storage is oriented toward raw disk images and usually cannot store files such as ISOs or backups (Proxmox VE Storage).
That distinction alone does not determine whether a virtual disk is thin-provisioned. Proxmox states that both some storage implementations and the QEMU qcow2 image format support thin provisioning. When thin provisioning is active, only blocks used by the guest are written to storage (Proxmox VE Storage).
The relevant question is therefore not only whether a disk is thin-provisioned, but where that behavior comes from:
- The virtual-disk format can provide thin provisioning on file-level storage.
- The storage backend can allocate physical blocks as they are written.
Directory storage with qcow2 and LVM-thin provide one documented example of each.
The two arrangements at a glance
| Property | Directory storage with qcow2 |
LVM-thin |
|---|---|---|
| Proxmox pool type | dir |
lvmthin |
| Storage level | File-level | Block-level |
| VM image representation | qcow2 file |
Raw volume |
| Source of thin provisioning | QEMU qcow2 image format |
LVM thin pool |
| Supported content examples | VM images, container data, templates, ISOs, backups, snippets | VM images and container root directories |
| Snapshot declaration | Internal qcow2 capability |
Supported by LVM-thin |
| Shared status | No | No; local-only |
| VM naming form | vm-<VMID>-<NAME>.<FORMAT> |
vm-<VMID>-<NAME> |
These entries come from the feature and naming sections for directory storage and LVM-thin, together with the general storage documentation. They are documented capability declarations, not comparative measurements.
Directory storage: qcow2 supplies the capability
The Proxmox directory backend uses pool type dir. It is file-level storage and can hold VM images, container data, container templates, ISO images, backups, and snippets. Its documented VM image formats include raw, qcow2, and vmdk (Directory Storage).
The general storage page specifically identifies qcow2 as an image format that supports thin provisioning (Proxmox VE Storage). In the arrangement compared here, thin allocation therefore comes from the qcow2 format rather than from a thin-provisioned directory backend.
The directory documentation makes a similar layer distinction for snapshots. It says the backend assumes a POSIX-compatible directory and cannot create snapshots at the storage level. VM images can instead use snapshots implemented internally by qcow2 (Directory Storage).
This evidence does not establish equivalent thin-provisioning behavior for every image format accepted by directory storage. The page lists raw and vmdk as supported formats, but the cited general documentation identifies qcow2 as the format supplying thin provisioning in this comparison.
Directory-backed VM image filenames follow this documented form:

vm-<VMID>-<NAME>.<FORMAT>
The directory page also shows an allocation command that produces this volume identifier:
local:100/vm-100-disk10.raw
Here, local is the storage ID, and the remainder follows the directory backend’s layout and naming scheme. Proxmox separately resolves that identifier to /var/lib/vz/images/100/vm-100-disk10.raw (Directory Storage).
Because this example is a raw image, it does not demonstrate thin provisioning supplied by qcow2. Its purpose here is only to show the documented identifier and naming form.
LVM-thin: the backend supplies the capability
LVM-thin moves thin allocation beneath the image representation. Proxmox says conventional LVM allocates blocks when a volume is created, whereas an LVM thin pool allocates blocks when they are written. The documentation explicitly identifies this behavior as thin provisioning (LVM Thin Storage).
The LVM-thin backend is block storage and uses raw volumes. Its documented content types are VM images and container root directories, and its feature table declares support for snapshots and clones (LVM Thin Storage).
The page provides this configuration example:
lvmthin: local-lvm
thinpool data
vgname pve
content rootdir,images
In this example, local-lvm is the Proxmox storage definition, data is the thin pool, and pve is the volume group. These are illustrative names, not requirements for every installation (LVM Thin Storage).
LVM-thin VM volumes use this naming form:
vm-<VMID>-<NAME>
The important point is that the raw representation does not imply that the volume’s full virtual size was allocated when it was created. For LVM-thin, the backend supplies allocation-on-write behavior while exposing raw volumes (LVM Thin Storage).
Proxmox also states that LVM thin pools cannot be shared across multiple nodes and can therefore be used only as local storage through this backend (LVM Thin Storage). Directory storage is likewise marked non-shared in its feature table (Directory Storage).
The common full-storage warning
Thin provisioning permits virtual capacity to exceed currently consumed physical space, but it does not create additional underlying capacity.
Proxmox warns that if a storage becomes full, every guest using volumes on it receives I/O errors. The documentation says this can cause filesystem inconsistencies and may corrupt data (Proxmox VE Storage).
The cited pages do not provide a safe overcommit ratio, sizing formula, recovery procedure, or performance comparison. They establish a narrower conclusion: directory-backed qcow2 and LVM-thin both offer thin provisioning, but at different layers. With directory storage, qcow2 supplies it. With LVM-thin, the block-storage backend supplies it while using raw volumes.
No comments yet