BTRFS Inside Proxmox VMs: Smart Flexibility or CoW-on-CoW Trap?

You know that moment when you're about to pick a filesystem and you pause?

You know the features well enough. You pause because you're wondering what future-you is going to regret, and that's exactly the tension in this thread. The question is simple on the surface:

Is there any problem with using BTRFS inside Proxmox VMs? I’d like CoW, snapshots, subvolumes. But I don’t want to back myself into some unforeseen corner.

That last line tells you most of what you need. Nobody asks about BTRFS casually anymore. You ask because you want the power, and you also know the internet has war stories. Here's what actually came out of the discussion.

First: what's the host running?

The very first response didn't debate BTRFS features. It asked one thing:

What filesystem are you using on the host? If it’s ZFS, then you’ll have a bad time due to write amplification.

Boom. Now the question is no longer about BTRFS in isolation. It's about stacking copy-on-write on top of copy-on-write, and that's where things get spicy.

If your Proxmox host is running ZFS, and inside the VM you run BTRFS, you're effectively nesting CoW behavior. Every write in the guest becomes a CoW operation, and then the host treats that write as another CoW operation. That can multiply IO overhead fast. Someone said it bluntly:

Normally using a CoW within a CoW is a bad idea performancewise.

That's plain physics.

But wait, the host is ext4

The original poster clarified that the host filesystem is ext4, which changes the tone immediately. Nothing is stacked anymore. The setup is:

• ext4 on the host
• BTRFS inside the VM

That's much cleaner, and the response was:

Then I have no concerns.

That was the whole reply, with no drama and no apocalypse warnings, which shows how much context matters.

The case for BTRFS in VMs

There were some strong pro-BTRFS voices in the thread. One person laid it out clearly:

• It's fine for production use.
• OpenSUSE ships with it by default.
• Just avoid BTRFS RAID5/6.

That last part is important. The RAID5/6 implementation still lives in "experimental" land, but RAID1 (mirror) is solid, and a single disk is also fine.

Another user has been running BTRFS in Debian VMs for over a year:

Snapshots before updates have saved me a couple times.

For a lot of people, that's the killer feature. Inside a VM, BTRFS snapshots are ridiculously convenient. You take one before an upgrade, before you mess with configs, or before testing something risky, and you can roll back in seconds. There's no hypervisor-level restore and no full image revert, just filesystem-level time travel.

Then there's resizing. One commenter pointed out something that's genuinely underrated:

In a VM, I love that BTRFS can resize in both directions.

Growing filesystems is common, while shrinking them is usually where things get ugly. BTRFS can do both, and in a lab or home environment where storage needs shift constantly, that flexibility is huge.

The case against BTRFS

Then there's the emotional baggage. Multiple users chimed in with variations of the same story: "I had a bad experience," "Lost the entire array," "Couldn't boot after an update," "Turned me off forever."

These weren't mild inconveniences. They were multi-terabyte rebuild nightmares. One person lost a virtualized BTRFS system after an update and didn't even try to recover it; they just moved on. Another lost a multi-terabyte array and spent weeks rebuilding a Plex server. That kind of experience sticks.

There's a pattern, though. Most of these horror stories weren't about simple single-disk BTRFS inside a VM. They were about:

• RAID configurations
• Older implementations
• Edge-case setups

Still, fear doesn't care about nuance.

The "just use ext4" crowd

There's always a voice in these threads that says "Ext4 unless you need something else."

One commenter mentioned that their large employer defaults to ext4 for non-redundant filesystems, because it's proven, boring, and it works. Boring is underrated.

Another person chose LVM/ext4 primarily for backup consistency. BTRFS wasn't broken for them; simplicity just won. There's some wisdom in that. If you don't absolutely need CoW features inside the VM, and you're already doing hypervisor-level snapshots, BTRFS might be redundant.

The hidden angle: host-level features

One comment cut through the feature list entirely:

You wouldn’t receive any real benefit of the VM. Snapshots and thin provisioning are more on the host side.

That's a fair point. If your Proxmox host is running ZFS, you already have:

• Snapshots
• Checksums
• Thin provisioning
• Compression

Do you really need BTRFS inside the guest too? Maybe not. If your host is ext4, though, that calculus changes.

The dedup surprise

One of the more interesting comments came from someone using BTRFS as a backup target. They're storing over 600 backups on a 10TB drive and are only at 70% capacity, thanks to block-level deduplication.

For backup-heavy environments, especially where most data doesn't change much between versions, BTRFS can pack things in tightly. That's real-world density, and it's hard to ignore that kind of efficiency.

So… is it a trap?

If you zoom out, the thread doesn't scream "run away." It says "know your stack." Here's the distilled version.

Safe-ish scenarios

• Host is ext4 or non-CoW.
• Single-disk BTRFS inside VM.
• RAID1/10 only.
• You understand snapshots and subvolumes.
• You maintain backups outside the VM.

Riskier scenarios

• ZFS on host + BTRFS in guest.
• RAID5/6 in BTRFS.
• No backup plan.
• Performance-sensitive workloads on nested CoW.

When things go wrong, misaligned expectations usually deserve more blame than the filesystem.

The psychological part people skip

Choosing BTRFS is also about personality. Are you comfortable debugging weird edge cases, willing to read kernel logs, fine learning recovery tools, and running a homelab where experimentation is part of the fun? Or do you want zero drama, zero surprises, and maximum predictability?

Some people will never trust BTRFS again because of something it did to them years ago, whatever its current state. That's valid. Storage trauma is real.

The original poster's position

One detail matters a lot:

Been using BTRFS on my homeserver for over a decade. One kernel crash, maybe caused by BTRFS. Apart from that, no issues whatsoever.

This is someone who already knows the filesystem, not someone blindly jumping into new territory, and that changes everything. The danger comes from unfamiliarity with the filesystem.

The verdict

If your Proxmox host runs ext4 and you want BTRFS inside your Linux VMs for snapshots, subvolumes, flexible resizing, or lab experimentation, you're not walking into a disaster. Just:

• Avoid RAID5/6.
• Keep real backups.
• Don't stack CoW on CoW unless you understand the cost.

If you're already running ZFS on the host, think harder, because you may be duplicating features and multiplying overhead.

There's no simple yea or nay here; it depends on knowing your stack. And if you've been running BTRFS for ten years without issue, you're choosing a tool you already know how to wield.