Proxmox VE Disk Image Formats Explained: Raw vs qcow2 vs VMDK

Every time you add a new virtual disk in Proxmox VE, there's a dropdown you probably click past without thinking: Format. Most of the time it's already set to raw or qcow2 depending on which storage you picked, and it's tempting to leave it alone and move on. But that one setting quietly decides whether your VM can take live snapshots, how much overhead every disk read and write carries, whether the disk file grows lazily or claims its full size up front, and how painful it will be later if you ever need to move that VM to different storage.

This guide breaks down the three image formats Proxmox VE actually works with — raw, qcow2, and vmdk — what each one is doing under the hood, which storage backends will even let you choose them, and how to pick correctly the first time instead of discovering the tradeoffs during an outage.

What You Will Learn

• What raw, qcow2, and vmdk actually are at the file level, and why the difference matters for performance and safety
• Which Proxmox VE storage types (ZFS, LVM-thin, Ceph RBD, directory, NFS/CIFS, Btrfs) support which formats
• How Proxmox VE decides which format to offer you, and how to override it from the GUI and the CLI
• How qcow2 snapshots behave differently from ZFS, LVM-thin, and Ceph RBD snapshots — and why that catches people out
• How to convert a disk from one format to another, including cleaning up vmdk disks left over from a VMware import
• A quick decision guide for which format to use on which storage, for which workload

The Three Formats at a Glance

Before going deep on any one of them, here's the short version. If you only read one section, read this one.

The short version of the short version: if your storage is ZFS, LVM-thin, or Ceph, use raw and let the storage layer handle snapshots and thin provisioning. If your storage is a plain directory, NFS share, or CIFS share, use qcow2, because those storage types have no snapshot ability of their own. Everything past this point is the reasoning behind that rule, plus the exceptions.

Raw: The Format With No Format

A raw disk image is, quite literally, a raw byte-for-byte representation of a block device. There's no header, no metadata layer, no indirection between "byte 4,000,000 in the virtual disk" and "byte 4,000,000 in the underlying file or volume." When QEMU (the hypervisor Proxmox VE builds on) reads or writes to a raw disk, the request goes almost straight through to the storage layer underneath.

That simplicity is exactly why raw is fast: there's no format-specific bookkeeping for QEMU to do on every I/O operation. It's also why raw images can't do much on their own — there's nowhere to store a snapshot's metadata, a backing-file reference, or compression, because there's no structure left over after the actual disk data.

On Proxmox VE, raw shows up in two different disguises depending on the storage backend:

• As a flat file, when the storage is a directory, NFS share, or CIFS share. Here a "50 GB raw disk" is a 50 GB file that Proxmox preallocates in full (or nearly in full) up front, whether or not the guest has written to all of it. This is thick provisioning: the space is reserved immediately.
• As a block volume, when the storage is ZFS (a zvol), LVM-thin, Ceph RBD, or ZFS over iSCSI. In this case the "raw" disk is not a file at all, it's a block device carved out of the pool, and thin provisioning — if any — comes from the storage layer, not from the raw format itself. A ZFS zvol, for instance, only consumes real pool space as blocks are actually written, even though the image format is raw.

This second point trips a lot of people up: they assume "raw = thick provisioned, always" because that's true for directory storage, then get confused when a 100 GB VM on a ZFS pool with only 10 GB written doesn't show 100 GB of ZFS space consumed. The format doesn't decide that on block storage — the storage backend does.

Because raw has no built-in snapshot mechanism, all snapshot and thin-provisioning behavior for a raw disk comes entirely from whatever is underneath it: ZFS snapshots, LVM-thin's own copy-on-write metadata, or Ceph RBD's native snapshot layer. That's a feature, not a limitation — those storage-layer snapshot systems are generally faster and safer under load than a format-level snapshot would be.

qcow2: A Disk Image With a Filesystem of Its Own

QCOW2 ("QEMU Copy-On-Write, version 2") is a self-contained disk image format with its own internal structure: a header, a table of clusters, and metadata describing which clusters have actually been written. It behaves less like a raw slab of bytes and more like a small filesystem whose only job is to store one virtual disk.

That internal structure is what gives qcow2 abilities raw doesn't have on its own:

• Native thin provisioning. A freshly created 100 GB qcow2 image starts out just a few hundred KB on disk, and only grows as the guest actually writes data, no matter what storage backend it sits on.
• Internal snapshots. qcow2 can store one or more point-in-time snapshots inside the same file, using copy-on-write so unchanged clusters aren't duplicated.
• Backing files. A qcow2 image can be defined as a set of differences against a read-only "backing" image, which is part of how Proxmox VE's linked clones work.
• Optional compression, applied per cluster, mostly useful for archival copies rather than live VM disks.

None of this comes for free. Every read or write has to go through an extra translation step — QEMU has to consult the cluster table to figure out where the requested data actually lives in the file — and that adds latency and CPU overhead compared to raw. It's usually a small overhead on modern hardware with the virtio-scsi or virtio-blk controller and an iothread enabled, but it is not zero, and it compounds under heavy random I/O.

There's also a specific gotcha with qcow2's internal snapshots worth calling out explicitly, because it surprises people who assume "snapshot" always means "instant and non-disruptive": creating or deleting an internal qcow2 snapshot briefly blocks I/O to that disk while QEMU rewrites cluster metadata. On a busy VM this shows up as a short stall, not a crash, but it's enough to notice on a production database. Proxmox VE 9 introduced snapshot volume chains for some storage types specifically to avoid this internal-snapshot penalty, but for plain qcow2 on directory or NFS storage, the classic internal-snapshot mechanism, with its brief block, is still what you get.

Because of all this, qcow2 exists on Proxmox VE mainly to give snapshot and thin-provisioning abilities to storage types that don't have their own: directory storage, NFS shares, and CIFS shares. If your storage already provides snapshots and thin provisioning at the block layer — ZFS, LVM-thin, Ceph — qcow2 is redundant overhead on top of a redundant overhead.

VMDK: A Visitor, Not a Resident

VMDK is VMware's disk image format, and Proxmox VE understands it well enough to read it — not because you're meant to run VMs on vmdk long-term, but because it's the format your disks arrive in when you migrate a VM off ESXi or vCenter. The Import Wizard in Proxmox VE (used for pulling VMs from an ESXi host or vCenter datastore) and manual imports with qm importdisk both routinely encounter vmdk files as their starting point.

VMDK itself isn't one format but a family of sub-types — monolithic flat, monolithic sparse, split into 2 GB extents (a legacy limit from older VMware versions and FAT32 hosts), and stream-optimized (the compressed variant used inside OVA/OVF exports). Proxmox VE's QEMU-based tooling can read most of these directly, but the split-extent and stream-optimized variants sometimes need to be flattened or decompressed with vmware-vdiskmanager or qemu-img before they import cleanly.

Once a vmdk-based VM is running on Proxmox VE, there is very little reason to leave it in that format. It isn't the storage engine that anything in the Proxmox VE stack was built around, none of the storage backends other than directory/NFS/CIFS will even display it as an option, and you lose the tight integration ZFS, LVM-thin, or Ceph give you with raw. The standard move, covered in detail below, is to convert the disk to raw or qcow2 as one of the very first things you do after a successful import, before the VM goes anywhere near production traffic.

Which Storage Backends Actually Support Which Formats

Proxmox VE doesn't let you pick just any format on any storage — the Format dropdown when adding a hard disk only lists what the selected storage backend is capable of holding. This is the matrix that decides what you'll actually see:

The pattern is consistent once you see it laid out: every block-level storage backend (LVM, LVM-thin, ZFS, Ceph RBD) only offers raw, because those systems already implement snapshots and thin provisioning themselves, one layer down from QEMU. Every file-level storage backend (Directory, NFS, CIFS, Btrfs, CephFS) offers all three, because a plain file on a filesystem has none of those abilities unless the image format itself provides them.

How Proxmox VE Picks a Format, and How to Override It

When you add a new disk in the GUI (VM → Hardware → Add → Hard Disk), the Format field only appears at all for storage types that support more than one option. Pick a ZFS pool or an LVM-thin pool and the field disappears entirely, because raw is the only possibility. Pick a directory or NFS storage and you'll see a dropdown defaulting to qcow2, which is the right default for that storage type in the overwhelming majority of cases.

To set or check the format from the command line, pvesm and qm are the tools:

# Allocate a new raw disk directly on a storage
pvesm alloc local-zfs 100 vm-100-disk-1 32G

# Allocate a qcow2 disk on directory-backed storage
pvesm alloc local 100 vm-100-disk-1.qcow2 32G --format qcow2

# Inspect an existing disk's format and metadata
qemu-img info /var/lib/vz/images/100/vm-100-disk-0.qcow2

In practice you'll rarely call pvesm alloc directly — the GUI and qm set handle disk creation for you when you attach a new disk to a VM config — but qemu-img info is genuinely useful any time you want to confirm what format an existing disk actually is, especially after an import where the answer isn't obvious from the GUI alone.

Converting Between Formats

The most common conversion on Proxmox VE is cleaning up a vmdk disk right after a VMware import, but the same tools work for moving between raw and qcow2 in either direction, for example when relocating a VM from an NFS share onto a ZFS pool.

The cleanest way to convert a disk that belongs to a VM is Move disk, from the VM's Hardware tab in the GUI, which lets you pick both a destination storage and a destination format in one step, live, without stopping the VM in most cases. From the command line, the equivalent is:

# Move VM 100's scsi0 disk to a ZFS-backed storage, converting to raw automatically
qm move-disk 100 scsi0 local-zfs

# Move the same disk to directory storage, explicitly as qcow2
qm move-disk 100 scsi0 local --format qcow2

If you're working with a disk that isn't attached to a VM yet — for example a vmdk file you copied over manually rather than importing through the wizard — qemu-img convert does the same job outside of Proxmox's VM management:

# Convert a VMware disk to raw
qemu-img convert -f vmdk -O raw source-disk.vmdk vm-100-disk-0.raw

# Convert a VMware disk to qcow2 instead, with compression
qemu-img convert -f vmdk -O qcow2 -c source-disk.vmdk vm-100-disk-0.qcow2

Either way, the resulting file still needs to be registered with the VM's configuration (or imported through qm importdisk, then attached with qm set) — a converted file sitting in storage isn't automatically wired up as a VM's disk.

One thing worth checking after any conversion onto thin-provisioned block storage: run fstrim (Linux guests) or enable the discard option in Windows, and make sure the VM's disk has Discard enabled in Proxmox VE's hardware settings. Otherwise blocks the old disk had "written" but the new guest filesystem considers free will still show as used space on the underlying ZFS pool or Ceph cluster, even though nothing meaningful lives there.

Snapshots Behave Differently Depending on the Format

This is the part that causes the most confusion in practice, because "take a snapshot" looks identical in the Proxmox VE GUI regardless of what's actually happening underneath:

• On ZFS, LVM-thin, or Ceph RBD (raw disks), a snapshot is nearly instant and handled entirely by the storage layer. Proxmox VE just asks ZFS, LVM-thin, or RBD to create one, and the underlying copy-on-write mechanism takes it from there. There's no meaningful I/O pause.
• On directory, NFS, or CIFS storage (qcow2 disks), a snapshot means QEMU pausing briefly to update the qcow2 file's internal metadata — either turning the current file into a new delta layer, or writing new snapshot markers into the existing file, depending on whether volume chains are in use. It's usually fast, but it is a real operation against the running disk, not a free storage-layer trick.

The practical implication: if you're choosing storage specifically because you plan to take frequent automated snapshots — hourly backups, pre-change safety snapshots, replication-style workflows — block storage with native snapshot support (ZFS, Ceph) will handle that load far more gracefully than qcow2 on a directory share will. qcow2 snapshots are perfectly fine occasionally; they're the wrong tool if you're taking dozens a day against a busy VM.

Performance and Provisioning: What Actually Changes

It's easy to overstate the performance gap between raw and qcow2 — on modern NVMe-backed storage with virtio-scsi-single and an iothread assigned per disk, the difference for typical workloads (a web app, a database with reasonable I/O patterns, general homelab services) is usually small enough that you won't notice it in daily use. Where it does show up:

• Sustained random write-heavy workloads (large databases under load, some CI build workers) feel qcow2's cluster-lookup overhead more than sequential or read-heavy workloads do.
• Thin-provisioned qcow2 images grow their backing file over time, and depending on the underlying filesystem, that growth can lead to fragmentation that shows up as slowly degrading I/O over months of uptime. Periodically converting a long-lived qcow2 disk (Move disk to the same storage, same format) can defragment it.
• Preallocation matters more than format for pure throughput. A raw disk with preallocation=full and a qcow2 disk with preallocation=metadata perform much closer to each other than "raw vs qcow2" alone would suggest — the biggest jump is between "no preallocation at all" and "some preallocation," not strictly between formats.

None of this is a reason to fight your storage backend's defaults. If you're on ZFS or Ceph, you're using raw regardless, and the storage layer's own tuning (ARC size, recordsize, RBD object size, and so on) will matter far more than anything about the image format. The format conversation mostly matters when you're the one choosing between directory/NFS storage and a block-based alternative in the first place.

Common Mistakes

• Assuming raw always means thick-provisioned. True on directory/NFS storage, not true on ZFS or Ceph, where raw disks (zvols and RBD images) are thin-provisioned by the storage layer itself.
• Leaving an imported VMware disk as vmdk in production. It works, but it's an unnecessary translation layer and it's the one format that isn't a first-class citizen anywhere in the Proxmox VE storage stack outside of directory/NFS/CephFS. Convert it during the same maintenance window as the import, not "later."
• Expecting the Format dropdown to appear on ZFS or LVM-thin storage. It won't — those backends only support raw, so Proxmox VE hides the choice instead of showing a dropdown with one disabled option.
• Taking frequent qcow2 snapshots on a busy production VM sitting on NFS and being surprised by brief I/O stalls during snapshot creation or deletion. That's expected qcow2 behavior, not a bug.
• Forgetting Discard/fstrim after converting a thick vmdk or raw disk onto thin-provisioned storage, then wondering why the "smaller" converted disk still consumes its full original size on the new pool.

Quick Decision Guide

• Storage is ZFS, LVM-thin, or Ceph RBD: use raw. It's the only option, and it's the right one — the storage layer already gives you snapshots and thin provisioning.
• Storage is a Directory, NFS share, or CIFS share, and you want snapshots or thin provisioning: use qcow2, Proxmox VE's own default for these backends.
• Storage is a Directory/NFS/CIFS share and you specifically don't need snapshots or thin provisioning (e.g. a large, mostly read-only media archive disk): raw is a legitimate choice here too, and avoids qcow2's small per-I/O overhead.
• You just imported a VM from VMware ESXi or vCenter: treat vmdk as a transit format. Convert to raw (if the destination is ZFS/LVM-thin/Ceph) or qcow2 (if it's staying on directory/NFS storage) before putting the VM into service.
• You're not sure what a disk currently is: run qemu-img info against its path, don't guess from the file extension alone.

Frequently Asked Questions

Can I change a VM's disk format without recreating the VM?

Yes. Use Move disk from the VM's Hardware tab (or qm move-disk from the shell), which converts the format as part of relocating the disk, live in most cases, without touching the VM's configuration otherwise.

Why doesn't Proxmox VE let me pick qcow2 on my ZFS storage?

Because ZFS disks are zvols, not files, and zvols have no room for a qcow2 header or cluster table. ZFS's own snapshot and clone system already does everything qcow2 would have provided, so Proxmox VE doesn't offer the option at all.

Is raw faster than qcow2?

Generally yes, though the gap is small on modern hardware with virtio drivers and an iothread configured. The difference is most noticeable under sustained random-write load, and least noticeable for typical general-purpose VMs.

Do I need to convert a vmdk disk immediately after importing from ESXi?

You don't strictly have to — Proxmox VE can run a VM directly off an imported vmdk on directory, NFS, or CephFS storage. But there's little upside to leaving it that way, and if your target storage is ZFS, LVM-thin, or Ceph RBD, vmdk isn't even an option there, so conversion is mandatory rather than optional.

What happens if I take a qcow2 snapshot on a heavily loaded VM?

The VM briefly pauses I/O to that disk while QEMU updates the qcow2 file's internal metadata. It's usually sub-second, but on a busy database it can be noticeable. This is different from ZFS, LVM-thin, or Ceph RBD snapshots, which don't pause the VM at all.

Does the image format affect backups taken with Proxmox Backup Server?

Not meaningfully. PBS backups work at the block level regardless of whether the source disk is raw or qcow2, and restores can target any storage type that supports the disk, converting format as needed during restore.

Wrapping Up

The image format dropdown looks like a minor detail, but it's really Proxmox VE surfacing a decision your storage backend already made for you in most cases — raw where the storage layer handles snapshots and thin provisioning itself, qcow2 where it doesn't. The only time this actually becomes a decision you need to think about is on file-based storage (directory, NFS, CIFS), and the one format you should never leave in place long-term is vmdk, which exists on Proxmox VE purely as a landing pad for VMware imports. Get the format right at creation time, or fix it with a single qm move-disk command, and it's one less thing to debug six months from now when you're trying to figure out why snapshots are slow or a disk is bigger than it should be.