Where Proxmox Snapshot Support Really Comes From

Proxmox VE’s storage tables can seem contradictory: directory storage lists snapshots and clones only for qcow2 images, while LVM-thin uses raw volumes and supports both.

The key is that snapshot capability does not come from the image-format label alone. It depends on the combination of:

1. The storage backend, such as dir or lvmthin.
2. The disk representation, such as a qcow2 file, raw file, or raw block volume.

With directory storage, Proxmox relies on features inside qcow2. With LVM-thin, snapshots and clones are provided by the block-storage backend.

File-level and block-level storage

Proxmox broadly distinguishes between file-level and block-level storage.

File-level storage exposes a POSIX filesystem and can generally hold varied content, including VM images, ISO images, and backup files. Block-level storage provides raw storage volumes and generally cannot hold ordinary files such as ISOs or backups directly (Proxmox VE Storage).

These are general characteristics, not universal snapshot rules. They do not mean that:

• every file-based image supports snapshots;
• raw disks can never be snapshotted;
• every block backend supports the same features; or
• a filesystem’s native snapshot capability is automatically available through Proxmox’s directory plugin.

To determine snapshot support, you must read the feature declaration for the specific backend and, where applicable, the selected image format.

Directory storage: features depend on the file format

The Proxmox dir backend uses a local directory or a locally mounted share. It is file-level storage and can hold VM images, container root directories, container templates, ISO images, backups, and snippets (Directory Storage).

By default, VM images are stored under:

images/<VMID>/

Their filenames follow this pattern:

vm-<VMID>-<NAME>.<FORMAT>

The VM ID identifies the owner, while the extension identifies the image format. The optional content-dirs setting can change the default directory layout (Directory Storage).

The directory backend lists raw, qcow2, vmdk, and subvol as supported image representations. However, its feature table lists qcow2—not a general “yes”—under both snapshots and clones. It does not declare those features for every supported representation (Directory Storage).

Why qcow2 matters here

The directory plugin assumes that its underlying directory is POSIX-compatible, but it assumes nothing more. Proxmox therefore does not expose storage-level snapshots merely because a disk image resides in that directory (Directory Storage).

Instead, the plugin uses capabilities built into qcow2:

• Snapshots use qcow2’s internal snapshot capability.
• Clones use qcow2’s base-image feature.

That produces two distinct cases within the same backend:

• A raw file on directory storage contains disk data, but the directory feature table does not declare snapshot or clone support for it.
• A qcow2 file on directory storage includes format-level mechanisms that the backend can use for snapshots and clones.

The filesystem beneath a directory might have snapshot features of its own. The cited documentation does not establish that the generic Proxmox dir backend automatically exposes them.

LVM-thin: snapshots belong to the backend

LVM-thin uses block volumes rather than disk-image files stored in a directory. Proxmox documents normal VM-image volume names in this form:

vm-<VMID>-<NAME>

Unlike directory-backed files, these names have no .raw or .qcow2 extension. The documented representation is an LVM-thin volume rather than a file with a format extension (LVM Thin Storage).

The LVM-thin feature table declares:

• content types: images and rootdir;
• image format: raw;
• snapshots: yes;
• clones: yes; and
• shared: no.

Here, raw describes the volume representation. Snapshot and clone support comes from LVM-thin itself, so qcow2’s internal mechanisms are not required (LVM Thin Storage).

LVM-thin is also thin-provisioned: it allocates blocks when they are written instead of allocating a volume’s full advertised size when it is created. Provisioned volumes can therefore be larger than the currently available physical space. This describes the storage model, not a capacity recommendation (LVM Thin Storage).

Proxmox marks LVM-thin as non-shared because its thin pools cannot be shared across multiple nodes and are therefore used as local storage (LVM Thin Storage).

Directory and LVM-thin compared

These values come from the documented feature rows and naming conventions for directory storage and LVM-thin. They do not describe other Proxmox storage backends.

How to read the feature rows

A format label alone does not tell you whether a VM disk supports snapshots. Read the backend and representation together:

• Directory plus raw: the directory feature table does not declare snapshots or clones.
• Directory plus qcow2: qcow2 supplies the documented snapshot and clone mechanisms.
• LVM-thin plus raw: LVM-thin supplies snapshots and clones at the backend level.

That is why “raw does not support snapshots” is too broad. A raw file on directory storage and a raw LVM-thin volume have different documented capabilities because the snapshot mechanism resides at a different layer.

Likewise, a directory backend’s ability to hold several content types and image formats does not give all of them identical features. Content eligibility, image representation, and backend capabilities are separate parts of the storage model.

This is a documentation-based explanation; no hands-on testing was performed. It makes no comparison of performance, backup consistency, migration behavior, capacity planning, or snapshot lifecycle. For the documented dir and lvmthin examples, the distinction is straightforward: directory-backed snapshots depend on qcow2, while LVM-thin provides snapshots for raw block volumes.

Sources and further reading

• https://pve.proxmox.com/wiki/Storage
• https://pve.proxmox.com/wiki/Storage:_Directory
• https://pve.proxmox.com/wiki/Storage:_LVM_Thin