Proxmox VE / Basic: platform and guest foundations / Lesson 4

Storage, volumes and content types

Distinguish a Proxmox storage definition from physical durability and choose volume capabilities from the backend contract.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Separate storage IDs, volume IDs and physical data locations.
Compare file, block and thin-provisioned storage concepts.
Assess snapshot, clone and capacity assumptions explicitly.

Read the storage definition

A storage ID is a platform configuration name describing how storage is accessed and what content it can hold. It is not automatically a physical disk, a redundancy guarantee or a backup. A volume ID relates that storage to a particular image or other content. Two nodes can show the same local storage ID while referring to different physical disks. Record backend type, node availability, content types and actual data location separately. The distinction is essential during migration: matching configuration labels do not establish that the target host can access the source bytes.

Compare content and capabilities

Storage backends support different content and volume features. A directory can hold files such as ISO images and backup archives when configured for those content types. Block-oriented storage presents volumes rather than ordinary files, and thin pools add allocation semantics. Snapshot and clone support depends on the backend and image format combination, not just a checkbox. The first record is a teaching capability inventory, not valid storage.cfg syntax. A real review must use the selected release’s backend table and distinguish supported capability from a feature actually enabled and tested in that environment.

text Storage capability review record

storage identity: lab-images
backend concept: file-backed directory
intended content: guest disk images and synthetic ISO references
review separately: image format, snapshot support, physical redundancy, backup

The record contains no mount path or command and makes no claim that a backend has been provisioned.

Reason about thin allocation

A thin-provisioned guest disk can expose more logical capacity than the physical blocks currently allocated. This improves flexibility but does not manufacture free space when guests eventually write. Logical capacity, allocated blocks, pool data usage and metadata usage are different measurements. The second example sums promised logical sizes and present synthetic allocation; the gap is an exposure to future demand, not free usable capacity. Snapshots can retain old blocks after a guest deletes data, and reclamation depends on discard support and the complete storage path. Do not infer pool health from a guest filesystem’s free-space number.

python Synthetic thin-provisioning exposure

logical_gib = [100, 100, 80]
allocated_gib = [30, 25, 20]
print(sum(logical_gib))
print(sum(allocated_gib))
print(sum(logical_gib) - sum(allocated_gib))

Expected output

280
75
205

280 is promised logical space, 75 current modeled allocation and 205 the potential additional demand in this simplified model.

Separate durability and recovery

Mirroring or distributed storage can tolerate selected hardware failures while still reproducing an accidental deletion or application corruption. A snapshot can preserve a point in one storage system while sharing its failure domain. A backup needs its own recoverable copy and tested restoration contract. Identify which guest disks and external mounts are included before claiming protection. For a synthetic catalog, the operating-system disk might be disposable while the data disk carries the recovery objective. Storage choices should follow those data roles rather than the assumption that every disk requires identical treatment.

Build a capacity and capability ledger

A useful ledger names each storage ID, backend, physical failure domain, supported content, snapshot behavior, available capacity and backup destination. Keep units consistent and distinguish measured observations from planned maxima. Include transition demand from migration, restore, cloning and snapshot retention. A backend that fits steady-state allocation can still fail during a recovery operation that needs temporary space. This course reads no disk or pool and changes no storage configuration. Its calculation checks only arithmetic; backend compatibility, data integrity and restoration remain separate environment-specific claims requiring authorized evidence.

Common errors and fixes

The same storage ID is assumed to mean shared bytes

Why it happens: Configuration identity was confused with physical reachability.
How to fix it: Identify the actual backend and data location on each relevant node.
Prevent it next time: Record local/shared semantics in the inventory.

Thin logical size is treated as available physical capacity

Why it happens: Future writes and metadata demand were ignored.
How to fix it: Review pool data, metadata and growth under the workload contract.
Prevent it next time: Monitor allocation separately from promises and guest free space.

A snapshot is described as an independent backup

Why it happens: Shared failure-domain dependence was omitted.
How to fix it: Define an independently recoverable copy and restoration test.
Prevent it next time: State recovery claims per data source and copy location.

Check your understanding

1. Two nodes show lab-images. What must be established before assuming migration can reuse the disks?

Show worked solution

Establish whether both definitions refer to genuinely shared storage and whether the target can access the exact volumes with compatible permissions and features. A common label on local directories is insufficient. Also review guest configuration and migration support; storage visibility alone does not establish CPU, device or application compatibility.

2. Why can deleting files inside a guest fail to reduce pool allocation immediately?