▤ Homelab

Virtual machine storage: LVM-thin, ZFS, qcow2 and raw explained

How to choose storage for virtual disks: LVM-thin, ZFS, directories with qcow2 or raw, thin provisioning, snapshots, cache, discard and real performance.

Every virtual machine needs one or more disks, and the way the hypervisor stores them affects performance, space used, snapshots and backups. In Proxmox VE, though the concepts apply to other KVM-based systems too, the main choices are three families of storage and two disk formats.

Two ways to store a virtual disk

As a file

The VM's disk is a file on an ordinary file system, ext4, XFS or a network share. Two formats are possible:

  • raw: a plain byte-for-byte image with no headers; the format with the least processing;
  • qcow2: QEMU's native format, which supports internal snapshots, dynamic allocation and shared base images.

As a block device

The disk is a logical volume: an LVM volume, a ZFS zvol or a Ceph image. The hypervisor presents it to the VM with no intermediate file system on the host, and snapshots are handled by the storage itself.

The main options in a homelab

Storage Type Snapshots Thin provisioning Notes
LVM-thin block yes yes default in many installations
Classic LVM block no, except in special setups no simple, space preallocated
ZFS block (zvol) yes yes checksums, compression, replication
Directory file with qcow2 with qcow2 or sparse files flexible, performance depends on the file system
NFS or SMB file with qcow2 yes shared between nodes, depends on the network

LVM-thin

This is the storage the Proxmox VE installer creates when you choose ext4 or XFS for the system disk. It offers snapshots and thin provisioning with good performance and low memory requirements. It does not verify data integrity and does not compress.

ZFS

It adds checksums, compression and replication to another node, at the cost of more RAM and some care with configuration. VMs use zvols, whose block size, volblocksize, is fixed at creation: the default is fine in most cases.

Directory and qcow2

Useful for external disks, network shares or when you want to handle disks as files to copy. The qcow2 format brings snapshots and dynamic allocation even where the storage does not provide them. One drawback: long qcow2 snapshot chains slow down reads and make merge operations more delicate.

Thin provisioning: convenient, but watch it

With thin provisioning, a 100 GB virtual disk occupies only the space actually written. You can therefore assign VMs more gigabytes than physically exist: this is called overprovisioning.

The risk is obvious: if the VMs all grow at once, the storage fills up. With LVM-thin, a full pool can pause machines or, in the worst cases, corrupt volume data. Two measures:

  1. monitor the usage percentage of thin pools, including metadata, with alerts well before the limit;
  2. enable discard, so space freed inside the VM is returned to the storage.

Discard requires enabling the option on the virtual disk and, inside the VM, running fstrim periodically, which many distributions already do with a weekly timer. Without this step, files deleted inside the VM keep occupying space on the host.

Disk settings that matter

  • Controller: VirtIO SCSI with the right driver offers the best performance and supports discard; the emulated IDE device is only for very old systems.
  • IO thread: dedicates an I/O thread to the disk, useful with several disks or heavy loads.
  • Cache: the default none is safe and suits most cases; writeback modes increase performance but, without power-loss protection, expose you to data loss in a power cut.
  • SSD emulation: tells the guest system the disk is an SSD, so it stops applying optimisations meant for spinning disks.

Converting between formats

The qemu-img tool converts disks between formats, for example from a VMware VMDK image to qcow2 or raw. Proxmox VE can also move a disk from one storage to another while the VM is running, converting its format during the copy. It is the easiest way to migrate from an old pool to a new one without stopping services.

A rule of thumb

In my work, for a single-host homelab, I choose like this: mirrored ZFS if the machine has enough RAM and two SSDs, LVM-thin if resources are limited, a directory or NFS for less important disks and installation files. Network-shared storage makes sense when there is more than one node and the network is fast.

In short

  • Virtual disks can be files (raw, qcow2) or block volumes (LVM, zvol).
  • LVM-thin is light and fast; ZFS adds integrity, compression and replication.
  • Thin provisioning saves space but requires monitoring usage.
  • Discard and fstrim return space freed inside VMs to the storage.
  • VirtIO SCSI, IO thread and «none» cache are sensible defaults.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. A computer science graduate, he combines rigorous technical analysis with attention to the people who use technology.

Read also